Managing and Motivating Developers: Tips for Management Cluefulness

Don't Ask Developers to Deal With Nondevelopment Stuff

Most developers want to focus on creating good code. And just about everything else is irrelevant to them.

To many, the manager's most important role is to protect developers from office shenanigans. Developers want and expect their management (including the layers between themselves and the CIO), Limeback says, "to take care of all the corporate crap, useless meetings, paperwork and other time sinks."

Leading that list is the marketing department, or whoever decides on arbitrary ship dates. Says Jim Pensyl, a senior performance engineer, "The more you cave to marketing time lines and avoid realistic estimates, the more you set yourself up for a project that will extend beyond marketing's promised date."

Other developers complain about managers who remind them about pending and late deadlines several times a day. They resent managers who tell them to serialize their tasks. "Give me a priority queue of tasks and let me get stuff done," wrote one developer via Twitter. "Get out of my way. I know what I'm doing." Many developers say they work best with people who give them problems to solve and do not interfere with how the individual solves them.

Listen. Respond. Praise.

Developers don't necessarily expect that the boss will understand what they're doing. They do, however, want the boss to listen and respond to her staff before making decisions. "Chat with the people who do the work once in a while. See what motivates them, and perhaps even get an idea of what it takes at their level to complete a project," IT professional Michael Furmaniuk recommends. "Motivation can start at the top and bottom, but if they never directly communicate, there is no real understanding."

"Listen actively, speak openly" is an important goal for Jason Trebilcock, a self-described BrickHead from Minneapolis. "Thankfully, our CIO does just that." But, Trebilcock adds, "It doesn't just apply to CIOs. It should apply to everyone across an organization... Without open and honest communication, you set yourself up for a lot of heartache." Be specific; subtlety is often lost on developers who are very cause-and-effect oriented. "Non-directive" suggestions aren't helpful, since a developer may not have any idea what you're hinting at.

Communication doesn't mean only the accurate exchange of information. It also means giving feedback and praise to developers-especially if you want to motivate them. "Verbal praise works for me," wrote one anonymous developer via Twitter. "Even if I'm not the best, I still need some positive talk to move me."

But feedback isn't always about telling developers how good they are. It's about setting expectations and being both consistent and fair. Here are four verbatim responses from Twitter (for which I must acknowledge the help of Michael Lopp, who was kind enough to ask his followers for 140-character-or-less input):

• I'd take harsh but consistent and fair over nice but wishy-washy any day.
• Passive-aggressive put-downs even though clear goals and expectations were not set. Snide personal remarks about your qualifications.
• Give me criticism and my perfectionism will make me work harder. Within reason; I'm not a workaholic.
• Acknowledging and leveraging my skills and talents to make good use of me.

QA specialist Joe Strazzere emphasizes the CIO's need to communicate. "While there may be an 'I' in the middle of your title," he writes, "At the root, all problems are people problems. Consider the people first, and the technology second."