I’ve had many managers throughout my career. I’ve seen some thrive, and some get fired. Some were loved by their teams, and some were despised. Some only cared about what time people arrived in the office and at what time they left (it had better be eight hours! Or Else!!!!), instead of the results and value they provided to the team and company. I’ve also been given the chance to manage some teams of my own and made my own mistakes along the way.
My goal of this article is to help new managers (or existing managers) become like the managers that have thrived instead of the ones that have been despised. To help them become LEADERS instead of just managers.
I believe that it boils down to three main rules. As always, there will be other factors that play into people liking you or respecting you (read Dale Carnegie’s “How to Win Friends and Influence People” for more on that), but what I’ve found is that if you concentrate on these main areas, you will be a successful leader and software developers will want to work for you and WITH you.
Rule Number 1: 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 is that managers recognize their own (and their team’s) abilities, and trust them to get the work done. (“Try and challenge me. I’m so much more than what you use me for,” wrote one anonymous developer via Twitter.)
“All motivation comes from within,” says SQL consultant Jamie Morison, 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 an anonymous software developer at Assurex Health, Inc. “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 Craig Rinehart, senior application engineer for a consultant firm in Cincinnati, 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.
Developers, as a general group, are highly competent individuals. 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. 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.
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.”
Rule 2: Don’t Give Them Mundane Tasks
Most developers want to focus on creating good code. And just about everything else is irrelevant to them.
To many developers, the manager’s most important role is to protect them from office shenanigans. Developers want and expect their management (including the layers between themselves and the CIO) to take care of all the corporate crap, useless meetings, paperwork and other time sinks.
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.
Rule 3: 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. Motivation can start at the top and bottom, but if you never directly communicate, there is no real understanding.
Listen actively, speak openly is an important goal to have as well. 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.”
Following these three rules will gain you much respect from your developers. The will love you for trusting them, giving them meaningful work that takes advantage of their skills, and listening and responding to the input that they provide you.
Let me know in the comments if you are a manager and what your reaction to these “rules” are. Do you follow them already? What have your results been?
If you enjoyed this article, then I ask, please share it or like it. It’s important to get the word out there to managers who just don’t seem to have a clue how to manage and utilize some of the most useful and productive people they will ever meet!
Thanks, and follow me at my blog (jasonroell.com) for updates on the wild and fun career that is being a professional software developer! Cheers!