Many people who end up working as Software Development Managers, Tech Leads, Chief Architects and other high-ranking software positions, have ended up there through time, hard work, and expert knowledge. They have demonstrated their skills, talents and knowledge on hundreds of occasions to many dozens of people throughout their careers. Eventually their extensive knowledge and superb skill have allowed them to take a leadership position in their organization.
Now we all know that some people end up in these positions almost by accident. It is clear to anyone who has worked with a person like this that they have the wrong job. People like this are an anomaly and I don’t want to discuss them. I’m sure there’s a fascinating, if somewhat twisted, set of instructions you could follow to get a promotion you don’t deserve, but for the purposes of this book I’m going to pretend that never happens.
Somewhere along their career path the skills of technical management have become more important to every software manager than their skills at writing code. You have probably seen this same thing happen in your career.
While each new opportunity moves you further and further from the direct act of writing code, your technical knowledge and skills never stop being important. It is impossible to manage or lead a group of technical contributors, be they engineers or software developers, without maintaining knowledge of the work your team is doing.
However, the day will come when you finally accept that you cannot keep up with the pace of technical growth maintained by the people you manage.
Sure you can keep up to date on all the technology being used by your team, and you can certainly keep a working knowledge of how everything fits together. You may even continue as the most appropriate person for large-scale system-architecture decisions. However, the facts are that everyone has the same 24-hours in a day, and that you need to spend much of yours doing non-coding tasks. This will eventually guarantee that someone on your team becomes more technically proficient than you.
The first time you recognize this is very scary.
Here you are, a successful software manager. You know that you’ve arrived at this position because you were consistently one of the top performers on your team. You wrote beautiful code, and you had superb technical insights. This is why you ended up where you are. And now your technical superiority is regularly challenged by one of the people on your own team. Should you feel threatened?
In a word: no. But accepting this involves a distinct shift in attitude.
Whether we admit it or not, technical people are very competitive with one another. We are always arguing and debating because we know this leads to the best solutions. It also leads to an unconscious competition that causes everyone on a team to rank their team members from “most gifted” to “simply adequate”. As a software manager, and one-time daily coder, you may still feel a part of this hidden ranking system. However, as the team manager, you need to recognize that you are no longer part of this contest. At least, not in the normal sense.
The developers on your team will still look at you for guidance and experience, but they probably aren’t looking for you to name the best design-pattern for a particular problem. Instead, they are looking for help in balancing priorities between tasks, in understanding the relative business merits of alternative product solutions, and in helping them understand the best processes to make the business successful. They may have a good idea about each of these things, but they will be looking to you for the last word. That is your job after all.
The real break-through moment for a new software manager comes when you realize that your value has changed. You are no longer the MVP (most-valuable-programmer). Instead, you have become the MVD (most-valuable-director). People are now looking to you for a different kind of expertise.
This “ah-ha” moment is a remarkable time for a new manager. Suddenly you are free to run your team in a completely different way. Instead of feeling threatened by that hyper-smart coder who can run rings around you with the latest dependancy-injection framework, you can encourage him to become even smarter. Instead of worrying that your coding skills aren’t as deep as they once were, you can work to make them as broad as possible. Instead of struggling to find time to attend every design meeting and code-review, you can step back and trust the brilliant people on your team to do their job.
This is a profound moment of personal self-discovery for many people. This is the time when you learn it’s OK to not be the smartest person on the team, in fact it’s probably best of you aren’t. This is the time when you can truly become a superb software manager.