In many ways, managing a developer is just like managing any other employee. Developers want managers who’ll help them solve business and technical problems, who’ll protect them from unnecessary office politics and who will help them meet their personal career goals.
But programmers are…different. Like musicians, these creative folks can alternate between big-picture thinking and persnickety detail in a heartbeat.
They can be sidetracked by silly toys, and convinced to work overtime by the promise of pizza and a T-shirt. Trying to understand and motivate these people can drive managers-particularly nontechnical managers-to distraction.
This is not, of course, a new challenge. Managers have been trying to inspire programmers since mainframe days, and several classic books still have relevance today.
For example, Tom DeMarco’s Peopleware was probably the first to recommend that developers be given telephones with ringers that could be turned off to minimize distractions from the warm, creative fog in which a creative person innovates.
Stan Rifkin, an advisory services provider with Master Systems, referred to a Harvard Business Review essay called “Who are your motivated workers?” by M. Scott Myers, written in 1964 (vol. 42, issue 1, pp. 73-88, if you want to look it up).
“‘How to motivate engineers’ is an old, well-known subject; note the date of the article cited,” says Rifkin. The article, in turn, relies on Herzberg’s pioneering work, published in HBR a year or two earlier. He added, “So many of our questions have been answered by research and evidence. We just have to learn how to find those answers.”
Based on plenty of conversations with developers, however, most managers still haven’t learned the proper skills.
So, in the expectation that developers know how their managers can motivate them and can manage them most effectively, I asked in several online communities and social networks, “What one thing, one thing, should the CIO understand about managing and motivating developers?” Developers did give me quite a bit of input, though not at the volume I saw from earlier articles in the Getting Clueful series (which highlighted IT workers’ opinions of the key things bosses should understand about telecommuting, software requirements, Agile development, fighting spam and computer consulting).
I’ve summarized the responses below; as you’ll see, the introspective nature of the question gave some surprising answers.
Trust Developers to Do Their Jobs
Some managers act as though developers, left to themselves would never write a line of code, and instead would spend all day playing computer games. That just isn’t true. The primary wish among developers who responded to my question was that managers recognize their own and their team’s abilities, and trust them to get the work done.
“All motivation comes from within,” says SQL consultant Rudy Limeback, who was a developer for 30 years. “Developers need to be allowed to develop because that’s what they love to do,” he says.
Managers can appeal to the pride a developer feels in his work. “Find out what the developers like to do, and find a way to let them do it so that it benefits the company,” suggests Ilja Preuß software developer at disy Informationssysteme GmbH. “The most motivated people are those who do what they like doing.”
“I want my IT manager to understand that I care about the quality of my work,” says Bruce Lindman, senior database consultant for Quick Solutions in Columbus, Ohio. “I comment my code with my name, and thus ‘sign’ every script or procedure I write. Nothing frustrates me more than having to do a shoddy job or compromise quality.”
You can’t appeal to developers’ creativity unless you give them the time and space to think and create. “Techies need time to think as well as doing the code,” says Lotus Notes guru Ben Poole.
“Developers, as a general group, are highly competent individuals,” wrote Paul Danielson, IT director for a newspaper publishing company. “They need to be given room to develop solutions on their own (although perhaps subject to peer reviews to some extent) without being hand-fed work and methodology by management-especially at the CIO level. Nothing quashes the spirit of a good developer quicker than being given a task and then told how he/she must accomplish it.”
Nor should managers expect software to be cranked out by factory methods. Software development is not a Six Sigma activity. “You’re discovering, not producing widgets,” wrote James, a senior developer.
Instead, give developers the big picture. “The more work I am assigned in advance, the better,” wrote one via Twitter. “I can see the endgame on my own instead of having it fed to me by someone else.”
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.
“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.”
T
he Difficult One: Pay Developers a Lot of Money
When I asked developers what motivated them, I expected most of the answers you read above. Most people want to be appreciated for the skills they bring to the table, to be trusted to deliver their best work, and to be given honest and useful feedback. But I didn’t expect that several responses would be utterly mercenary.
For example, one developer’s response to the base question “If you could get your CIO (or IT manager) to understand one thing about managing and motivating developers, what would it be?” was a single word: Money. And to the automatic follow-up question, “Why did you pick that?”-“Chicks dig it.”
I did laugh aloud at that response, but other developers (who remain anonymous for obvious reasons) repeated the sentiment. “As far as motivation goes, if I am not getting paid, I am not getting out of bed,” wrote one. “That simply saying I’m the exceptional one who can do this amazing thing doesn’t motivate if I’m not being paid exceptionally,” said another. “Money is the main motivator for any job; get it right and you will have a happy employee,” added a database administrator, who recommended that CIOs keep an eye on what the job market is doing for his role, and make reasonable adjustments to ensure the staff is within the comfort zone for their pay scale.
Certainly, one way to give feedback to developers, especially the ones you value most, is by showing your appreciation on the paycheck.
But surely that isn’t the whole story. Every one of us could describe a job about which we’d say, “There’s no amount of money you could pay me to do that,” and most of us can cite jobs that paid relatively poorly in income terms, but from which we gained a great degree of personal satisfaction.
Perhaps I’m wrong in this conclusion (as a confirmed hippie who believes that all work should come from personal passion, and the money will follow), but I don’t think so.
Given a choice between a high-paying dead-end job and a rewarding one (for slightly less money) that generates personal pride and a sense of accomplishment-well, I have a hard time believing that most developers would choose the former.
My interpretation of the mercenary answer is that most developers don’t really know what motivates them… which means that their managers have to make individual judgments about the people who report to them. “Money” is an easy response-too easy-because we all like to be paid a lot.
Developers, however, are not necessarily introspective. Unless they personally have a tropism toward team (if not upper-level) management, they may not give much thought to the things that bosses can do to motivate them to do their best work. That task, then, remains firmly in your lap.
A Purr-fectly Reasonable Analogy
It may be helpful to think of good IT people like cats, wrote Pat Phelan, a database administrator who specializes in PeopleSoft technologies. “If you treat them well, offer the occasional special treat, and discipline them fairly, it can be done and done well. If you miss a point or two now and then, they’ll adjust,” he says. “If you miss any of these points consistently for too long, the really good ones will start to wander off in search of better opportunities.”
And managing them is a lot like herding cats. The corollaries apply, too, says Phelan. For example, micromanaging a cat is pointless; the results are frustration for both you and the cat. “Make sure that the cat understands what you want. If you’ve done a halfway good job of handling the cat, it will consistently surprise you by doing a better job than you can imagine, and often in ways that you would never have thought of and couldn’t explain if you had thought of them!” he says. Plus, trying to understand a cat is highly educational, but rarely profitable because, after all, cats do what cats do. It is a bad idea to either over- or underfeed a cat, Phelan advises. “Overfed, they get lazy. Underfed, they’ll do things you don’t want them doing. Find the appropriate level for each cat. Always leave room for the occasional treat (some earned, and now and then one ‘just because’).”
Do not abuse the cats, he adds. They’ll do things to get even that you’ll never think of. Remember, too, that cats learn a lot by playing. Always try to leave them time to play. The exercise is good, the team building is good, and you often end up with better-behaved cats.
Comment: [email protected]
