I've been thinking about what makes a good software development manager for quite some time. A friend recently asked for my thoughts on this so I thought I'd jot them down. Let me know what you think.
People management is top priority. Developing people is what it's all about. The job is to empower, delegate, motivate, reward and recognize. And it is to be done frequently. And that is all. It's okay to be a customer advocate given spare time, but that should not be the manager's job. It's good to use the application his group is building. And it's good to understand the competition. But QA and competitive analysis is not the manager's job. It's okay for the manager to be a proxy for the customer for a short while, but that's the product manager's job. And the manager can be the benevolent dictator (final arbiter) if there is no one else to do it.
A manager should encourage, reward, even expect continuous learning. This means more than just paying for appropriate books and sending a few employees to training each year. It also means encouraging employees to keep learning and sharing what they learn. Recognize employees that are involved in study groups and user groups. Encourage the use of software development best practices.
A good manager will take time to meet regularly with employees, in small groups and one-on-one. You'll likely find a good manager eating lunch with his employees or chatting in the break room. You may even find him playing video games, ping-pong or foosball. High levels of communication is very important. It's the best way to understand the organization's health, to discover employees' career goals and aspirations, and to find out what type of work they enjoy. Without this understanding, how can a manager mentor and develop his people?
Regularly is also the most appropriate time to give feedback. Managers should comment on good and bad work right away. Don't wait for the end of the project. And certainly don't wait for the annual review.
Perhaps the most difficult aspect of good management for most of us techies, oddly enough, is fostering creativity. We are all pretty creative. But we get in ruts and lose our edge. A good manager spends his time thinking of how to keep our brains creative.
I don't think a manager necessarily has to have been a programmer, though it can help. It helps to be technical enough to be credible, to have something in common with the engineers. And it helps to know when someone is trying to pull the wool over your eyes. It's useful to know how to do all the stuff I say don't do (below), but develop those skills in others rather than do the task yourself.
One of my favorite quotes is from Andy Hunt.
Management's responsibility: remove the obstacle. Team's responsibility: identify the obstacle.
It's the idea of management serving the employees, not the other way around. The employees get the real work done. Managers make sure the right folks are trained and aware of what needs to get done. Managers make sure employees have the information they need to do the job well.
A manager should not spend his time "doing" stuff. Richard Lowe expresses this best: "This means ALL tasks must be delegated, except for those tasks directly related to getting other people to do their jobs." The mistake is "doing actual work instead of managing." If a manager's job is to observe, motivate, reward, develop people, improve morale, and all that other stuff, then, if done well, there will be no time for anything else.
Managers should never make design or coding decisions. Nor should they make architectural decisions except to enforce whatever constraints come from product-family concerns or testability, reliability, redundancy, serviceability, availability, and other requirements of that ilk. But managers often can't resist. Where does this come from?
Often we take good developers and promote them into management. Not because they possess the attributes of a good manager, but for all the wrong reasons. "Fred did a great job on the hoohoppy project. He handled all the technical details. He's our most senior developer and we have this open management position..." This makes about as much since as, well, as me trying to make a weak analogy right now.
Of course it isn't always quite so black and white. Sometimes a manager may find himself in a situation in which no one knows how to do some necessary and urgent task and either the manager has a real junior team or has some seriously tight deadline. In this situation, I don't mind if a manager pitches in to learn how to get this thing done. But it shouldn't become the manager's job. Rather, he should teach someone else to do it and delegate that responsibility.
What about project management? Isn't that a manager's job? I don't think so, though that's where it usually ends up. Good managers should train up their team-leads to handle that responsibility. Managers should ensure that it gets done and should teach others how to do it if necessary. It's the same with risk management. Ensure it gets done, but don't do it yourself. "We need to have more trust in one another," Lou Gerstner Jr in his tenure as CEO of IBM wrote to employees -- "confidence that our colleagues can lead and do the right thing, so we don't have to attend every meeting and check every detail."
There is more, of course. But it all involves thinking about what needs doing, rather than the doing itself.
It should go without saying: Treat employees with a great deal of respect. Treat them like the intelligent human beings they are. Sadly, I've seen a few managers that just don't understand this. Or they never spend time in self-reflection, examining their behavior. So I'll leave you with this thought. Managers, reflect on your organization's effectiveness. And reflect on your effectiveness.
P.S. Before anyone points out that I don't walk the walk, let me add that all of this is very hard. To do it well requires either a tremendous amount of courage or like-minded upper management who will hold us accountable.
No comments:
Post a Comment