I’m sitting here on a Friday night doing what all geeks do. Reviewing blogs and of course catching up on Dzone.com! I was checking out the top links section when I came across Jared Richardson’s recent post ‘You’re a Bad Manager, Embrace It’. I have to admit I’m a little shocked at his article as a sort of bitter commentary on the state of IT management. I’m the first one to tell you that the future of IT management concerns me as well but as someone who does manage development teams I would like to provide some insight.
First some things I truly believe as a manager:
Developers are professionals, treat them as such. They didn’t get to where they are because they are incompetent. If you hired right, they are better than you ever were as a developer.
The team is everything. You fail as a team and you succeed as a team.
Promote your teams, always. Your job as a development manager is to maximize your teams opportunities. This is distinctly not a team sport. If you fail at this the blame is solely yours.
Protect the team. Distractions like office politics, budget fights and general obstacles keep the team from doing what they do best: be development professionals. Your job is to clear the field so the team can perform to the best of their abilities.
The funny thing in reading Richardson’s post is that I can see where some of these frustrations come from. However, I’ve worked with very few inept development managers. Perhaps I’m just lucky but I think as someone who has spent some time in management I can see both sides of the coin. Let’s start by examining some of his thoughts:
“When your team gives you an estimate for how long they think work will take, you always reduce it. By dropping 25 to 50 percent of the time, you like to think you're pushing your team to do their best. We all work better under a deadline, right?”
Estimates are just what they are. Estimates. We all play this game everyday. Whether buying a car, getting work done on the house or even doing a personal financial budget. Management wants something. We, as in the team, want the appropriate amount of time and money to do something the way we want it done. Your job as a development manager is to translate for both sides. Simply slashing time or taking an estimate at face value is wrong in either case. If you have no negotiation skills than perhaps management is not for you.
Perhaps the most annoying, and perhaps dangerous, argument is the one that Richardson makes next (I’ve heard it at least a dozen times):
A typical developer, after you factor in benefits and the overall cost of employment, costs you from 150,000 to 200,000 dollars a year. If you have a ten person team, you can buy them extremely high end workstations for around $3,000 each. That's $30,000 a year to save two man years. Does that sound like a good investment?
I agree with this but there is a hard reality that every developer (and management hopeful) should know. I would like to set a scene for everyone reading this. You as a development manager go to the CIO or CFO and explain this great opportunity to increase productivity. The CIO or CFO have read the latest article in CXX magazine about the benefits of offshoring. They won’t even get to the saving of two man years. They will just see the $150,000 to $200,000 cost. Personal experience tells me that you don’t want to spend the 100+ hours of power point presentations justifying the value of your locally based team. Trust me on this. There are better ways to get the equipment you need. You just need the ability to translate the need without exposing the team to risk.
Now something about rewarding the team:
Speaking of rewards, like most bad managers you reward your developers individually. You provide bonuses and raises to the top performers, and less for the middle, and none for the "low performers". Then you stand back and wonder why they don't perform as a team. Why they refuse to help each other and compete with each other.
This gets back to the culture. The team is everything. Perhaps I should have made this # 1 on my list. Great development teams self organize. Developers know who are top performers and who are not. This does not mean that you only reward the most experienced. You reward the top performers at every level, entry level, mid’s and sr’s. I have yet to manage a team where the top performers allow the ‘low performers’ to bring the team down. They always pick up the ‘slack’. Your job as a manger is to know who the top folks are and get their input. No top performer wants to work with someone not pulling the team forward. It’s a team effort. Drop the weight of low performers and increase team moral by demonstrating that your more than willing to cater to the self organizing and self managing team’s wishes. They are after all, the best suited professionals to make that determination.
I’m by no means saying that Jared Richardson’s article has no merit. I’ve heard plenty of management horror stories. Bad managers are out there. I respect his attempt to shine some light on what it takes to build great teams and look forward to more of his posts!.