Having worked in many companies over the years there are a few things I know better than my managers, and the longer I’m in this business the more frustrated I get when things are simply not working the way they should due to bad management. If I as a senior programmer have to step in to do actual project management because my technical project manager fails to do it, something is wrong. Unfortunately this is more common than it should be. A big issue is that managers that are put in charge of development teams are often under-educated when it comes to development and the development process. In fact, they may know nothing about programming at all, and they’re thrown into a world of developers who can build them anything they request – assuming upper management has a good plan on what needs to be built.

Why and how these managers end up in a technical management positions is always the question, but any programmer who’s been around for a while can usually sniff out the bad ones in mere seconds. A good manager is a mediator, someone who knows they may not always know better, but listens to their team, suggests solutions based on what the team has told them and mediates between the dev team and the rest of the company (and upper management). A good manager could be compared to a good army commander. The troops know they can trust them, and will follow them into battle knowing that all decisions are calculated and weighed and probably the best ones. A bad manager however is one who undoubtedly will cause massive team issues and communication breakdown. In the troop scenario the team would undoubtedly get into serious trouble, and if it were a pirate ship, mutiny would soon ensue.

Down the road bad management leads to anger and frustration, and ultimately to the dark side. I’ve been in many meetings where the programming team starts talking tech issues and the manager sits silently like a question mark watching a tennis match because they have no idea what people are talking about. This is very bad, and a sign of probable project failure down the road (or lots of code re-writes due to miscommunicated features). It’s OK to not understand everything, but if you manage programmers (especially experienced programmers) you need to be someone who understands the field, and understands it well. A developer who knows that their manager does not understand what they tell them will start communicating less and less, and in the end will probably stop altogether as it does not help them in any way. This leads to a team that is disconnected from management, and undoubtedly a manager who has no clue about the status of the project.

Another issue, seemingly common, is that the product manager (who is literally in charge of the product and the outcome thereof) does not even know what the product is. This usually leads to constant feature changes, and a very angry team. A lot of this can be solved with a good specification early on, but with deadlines looming and budgets shrinking, tech specs are a dying breed.

There was a great thread on Slashdot a few weeks back called “Managing Seasoned Developers” which is the basis for this post, and despite the random seasoning jokes, there is some really great information in there. As I don’t expect you to go through that thread to dig out the good stuff, I decided to take the best parts and make a list of “What a good development team manager should and should not do”. I also added a few other worthy entries from other places and adjusted some to reflect my own experiences.

How to deal with experienced developers as a manager (in random order):

It’s also worth mentioning that managers need to be told some of these things (their weak spots), so don’t be afraid to put your foot down, it just might make them better!