posted Jan 21, 2013, 9:55 AM by Bill Heitzeg
In the field of software engineering, leadership is still far behind the capabilities of those that design, create, test, deploy and support software offerings. This won’t come as a surprise to those who have been in the field for more than a few years. The reasons for this are varied, but in my opinion, the number one reason is the Peter Principle: “Employees tend to rise to their level of incompetence”.
The Peter Principle first appeared in the 1969 book by the same name. The idea behind the Peter Principle is that people will be promoted based on merit and then find themselves in a job they aren’t capable of doing. This seems somewhat obvious, but it’s not always easy to recognize. When we see someone move from a technical position to a management position, it’s very easy for them to end up out of their depth.
When I say a management position, I’m speaking of something very specific. This is someone who has direct technical reports and/or is responsible for delivering a complete software offering.
A software developer who becomes a manager has been put in a whole different world than they have been used to. Their comfort zone is almost completely stripped away. We see many reactions to this, but the most common is that the manager stays in the software and focuses their time on micromanaging the codebase. This can have disastrous effects on the team and the software being delivered.
There are two key practices that I have found very helpful when making the leap into management. First, replace yourself. Second, spend as much time learning to become a manager as you spent learning to become a software developer.
Replace yourself
If, like many other managers, you were promoted to head up a team you were already a part of, then you need to replace yourself. In most cases, this is going to be incredibly hard to do. You were most likely already a lead developer and were the “goto” person for many of the harder issues your team was facing. In fact, your boss might have said something to you like “Hey, I want to promote you to manage the team, but I still want you to write code”. If you fall for this, it’s going to be the first step to a very unhappy management experience. Remember you’re a manager if you have direct reports and/or are responsible for delivering a complete software offering. You need to step out of your comfort zone and focus on your primary responsibility, which is management. You can’t do this if you’re the “goto” person on your team. Even more so, if you want your team to grow and become better, you need to build more goto people onto the team. This is a great exercise for a first time manager. It allows you to start making your team stronger, while at the same time freeing yourself up for your new job.
Learning
Spend as much time learning to become a manager as you spent learning to become a software developer. Managing well is incredibly hard to do. Think of those managers you’ve worked for that you: “Love”, “Hated”, “Felt Sorry for”, “Disliked”, “Enjoyed”, “trusted”, “distrusted”, etc. Each one of them were doing things that caused you to form opinions about them. Articles, books, podcasts, training courses, seminars are at least as prevalent in the field of management as they are in the field of software. As with software education, you have to look for the right ways to learn and practice your new craft. The important point though is that you didn’t become a great software developer in a vacuum, you won’t become a great manager without the same kind of continuing education.
Three books to help out a new manager Growing Great Employees - Erika Anderson
An excellent, easy to read book on how to grow your current team and how to hire new team members.
Crucial Confrontations - Kerry Patterson
A must have book for learning how to work with your employees, your peers and your boss.
Financial Intelligence - John Case
If you, like me, don’t have any formal financial training, this is a great book to help get you up to speed. |
|