So your skills have degraded, you can’t type as fast as those younger guys, they can work all night, but unfortunately coffee just makes you have to pee a lot.  Not to mention your spouse is sick of you working all the time anyway.  Then they offer you a job as a manager and you jump at the chance.  I mean, at least you won’t have to look silly, some old person trying to keep up.  You’ll be more like a parent and they’ll be your kids.  I mean you can still keep your skills up by writing some code on the team, just not as much.  You still have a few things to teach those kids and now they’ll have to listen to you.

Sound familiar?  Although it’s an exaggeration, it’s not that far off from the experience of many software developers turned manager.  Unfortunately, I believe this scenario is exactly the reason that so many software teams are under-performing.  How often have you caught a manager talking about software development topics?  “Here’s how I would solve it”, “Have you considered...”, or the dreaded “I was looking through the code last night and ...”

I first encountered this phenomena a long time ago.  I was fresh out of GMI, working for General Motors when one day I had the opportunity to talk one-on-one with an executive.  This was a man who headed up the engineering side of our entire division.  Like myself, he was an electrical engineer.  In our 30 minute meeting, he spent about half of it proving he still had the stuff to be a great engineer.  He even went so far as to say something like “I could walk out of here today and go right back to designing great hardware”.  Maybe he was right, I don’t know, but what has bothered me ever since is how he didn’t seem to be at all proud of his role as a leader.  This man had hundreds of people who depended on him every day.  His leadership would go on to make the difference between our division succeeding or being spun off and eventually closed.  Yet, for him, it was all about the being an engineer and not about being a manager.

Here’s something that many of us don’t understand:  Management is actually a profession.  Management is no less easy to master than software architecture or software development.  In fact, because it can sometimes be much less objective, it can be much more difficult to truly master. People who can’t learn their discipline, apply it, acquire feedback, and repeat, will fail in any profession.  Management is a full time job, it’s not a hobby and it’s not a retirement package.

As with software you can’t just read the book and start doing something brand new.  You need to know if this is a good idea for your domain, if it’s just a fad, and if the idea is something you could implement.  If quickly making large changes in software is a bad idea, then making large changes in organizations is a really bad idea.  You’ll be making cultural shifts that have an effect on everyone around you.  Your direct reports, peers and management will all need time to adjust.  As with software, figure out where you want to go and then introduce step-by -step changes.  Stop along the way to reevaluate and course correct.  You’ll discover it’s surprisingly easy to make changes this way.

One of your primary responsibilities will be to define and enforce process.  Good process favors people because it eliminates the mundane and allows smart people to focus on the real work at hand.  Good process bring predictability to those tasks that don’t require on-the-spot creativity.  Developers should never have to figure out what to do with a new customer request, how design should be communicated or how software makes it into production.  You don’t want developers to have to continually bring their creativity to tasks that should be more or less repeatable.  Reworking how to accomplish basic tasks wastes time and more importantly, it reduces predictability.  Make it your concern to reduce the number of tasks that don’t have a cookbook approach.  You’ll find that you both improve moral and increase productivity.