Management - The Graveyard for Software Developers

posted Dec 19, 2011, 4:51 AM by Bill Heitzeg   [ updated Dec 19, 2011, 6:25 AM ]

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.

Here’s some key points that I try to follow:

Don’t be a hack

How many of us have had bad experiences with Hack developers?  You know, the developer who will learn just enough to get the final result out, but then leaves a mess for someone else?

How about developers who won’t reuse off-the-shelf code, best practices or patterns?   When you discover something in source control, called: “BobsHttpClient”, how do you react?

I have the same problems with Hack managers.  Management is a full time job with lots of homework.  It’s fun to get right, but it takes time and effort.  Just as with software development, you can’t just take a class.  You’re going to have to bear down and become a manager on purpose.  Also like software development, management is a quickly evolving field.  Every day people are studying and writing about ways to improve the management of people, projects and processes.  Keeping up is hard work.  

Build a strong team

Your team is actually the most important thing.  You won’t always realize this.  You’ll find yourself spending time on lots of other things, especially with your management and peers.  At the end of the day though, how your team performs defines your success.  Everything you do should be done with an eye as to how it effects your team.  Projects are ephemeral, but your team is not.  You need to help your programmers grow into the best possible team.  Find regular, effective ways to build their skills and their ability to work together.  Don’t depend on a hero or two, your whole team is the point.  If you are always improving the engine of production (your team), then no matter what the business throws at you, you’ll be able to accurately predict when your team will be able to finish it.

Make small incremental changes

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.

Good Process favors people

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.

Measure everything you can

Benchmarking is a highly effective way of showing and improving results.  Find consistent ways to measure team performance and the effectiveness of your processes.  Bake the measurement and the reporting of the data into your process.  Not only will this help you to improve and to know what to improve, it will impress the heck out of your boss.

Solicit Feedback

You need a consistent, repeatable way of soliciting feedback.   Management is leadership and as a leader, you need to be effective.  If people think you’re a jerk or a wimp, your effectiveness will suffer.  Feedback like this is not as objective as benchmarking, but it allows you to insure that your behavior isn’t completely off the rails.  Attempt to solicit feedback, in the form of a 360 degree feedback, from you team, your peers, and your management at least every 6 months or more if you are really struggling in some ways.

Forgive yourself

You’re going to screw up and fail miserably.  If others don’t forgive you, that’s something you can live with, but if you don’t forgive yourself, that’s something you can’t live with.  Don’t let mistakes define you.  Learn from them and laugh about them.  When others make mistakes, recall your own and share them.  Learning from your mistakes is the right approach.  Try not to bury your mistakes, but expose them to the light of day.  Talk about them with your boss or mentor.  Most importantly, move on from them.