From Developer to Technical Manager

http://www.aaronlerch.com/blog/2008/04/20/from-developer-to-technical-manager/

A long time ago my grandfather worked as a machinist in a factory. He was a damn fine machinist, a true craftsman, and he took great pride and joy in his work. Most of my memories of my grandpa were from after he retired, and I would have loved to have seen him "back in the day". I’ve done some woodworking in my relatively short life, and I understand the euphoric sense of pride and joy that come when you finish a project that you built from scratch.

Grandpa’s skills grew over time and, as it’s a natural thing, he began informally mentoring junior machinists. It wasn’t long at all before management at the factory noticed both his skill and his mentorship and did what any good manager would do. They promoted him to a supervisor.

My dad tells me that my grandfather was never the same.

Being a supervisor sucked the life out of my grandpa. Everything he loved about his job was gone. He no longer worked with peers, he oversaw employees. Reviewing their work, approving their vacation, dealing with "poor performers", and spending less of his time creating.

Grandpa’s managers made an all-too-common mistake. They assumed that because grandpa was good at his job, he’d be good at managing other people doing the same job. Sound familiar? Thought so. By no means is it limited to any one industry, either. I’m pretty sure that eons ago there existed a caveman who was good at killing mammoths, and as a result was promoted to "branch manager", and probably ended up killing his coworkers ’cause that’s all he knew how to do.

A lot has been written about this problem. And it’s definitely a problem.

But it’s not so simple. Managers need a good measure of domain knowledge. There are two ways to get a manager with domain knowledge: hire a "manager" and teach them the domain, or promote a domain expert and teach them to be a manager. Because domain knowledge tends to be more specific and more detailed, and because managing is incorrectly viewed to be "easy", the default is usually to promote a domain expert. Add more mundane logistics like the fact that domain experts tend to already be employees and it makes the decision that much "easier".

In the software world the problem is amplified by the nature of "domain experts". The majority of us can hardly interact with any other human being, not to mention "manage" developers.

Unfortunately, because of wrong assumptions, most organizational structures are set up in a way that assumes a career path from developer to manager. In Code Craft, Pete Goodliffe calls these people "Reluctant Team Leaders".

"This is the organizational classic; a developer who’s been promoted to team leader when there was no further technical route for him to advance. You can plainly see that he is uncomfortable in this role. He doesn’t have the correct skill set, and he struggles to keep up. He is a programmer, and he wants to program. This guy is not a natural organizer or manager of people, and he is a bad communicator."

Organizations with an outdated organizational structure have got to wake up and change before it’s too late. They will either lose or ruin their people. Either way, the company loses because people are the company.

I do think, though, that it is possible for a developer to successfully become a technical manager. There are some developers that have the skills, nay, more like the potential, to be good technical managers. We’re seeing more and more developers with "people skills". Partly because the barriers to entry have lowered. For example, you don’t need to have a secret love affair with bit twiddling 1′s and 0′s in order to write software. Higher level frameworks like Java, .NET, and Ruby/Rails enable more people to create something great than has previously been possible.

So what are the characteristics of a good technical manager?

1.Communication. Communication is where developers struggle the most. The world with two personalities (1 and 0) is vastly different than the world of billions of personalities. Each personality type communicates in a different way. And as a technical manager, one of the most challenging tasks is to help a group of individuals communicate and work as a team. A developer has a ONE-TO-ONE communication path: developer to their manager. A technical manager has a ONE-TO-MANY communication path: from the manager to every person on the team. Often a technical manager will find themselves proxying the communication between two developers.

2.Technical savvy. A technical manager has to maintain the respect of their team, and software developers tend to be an elitist group – if you can’t keep up, good luck. You don’t have to be technically "smarter" than your team, not by a long shot (otherwise you should stay a developer), but you should keep up to speed with current trends, best practices, new technologies, etc. In my experience, technical managers can "cherry pick" smaller features, but should never be in the critical path for a project. I’ve been there, it’s not fun. Open source projects are a great way to keep up with both deeper and broader design and implementation techniques.

3.Organization skills. A normal developer keeps track of many things: bugs, features, ongoing email threads, and of course current designs, implementations, etc. A technical manager must track all of this, but at a higher level and for several people across the team.

4.Priorities. Your primary job responsibility is no longer writing code. A technical manager has to come to terms with that before accepting the job. But a technical manager’s job also isn’t to dictate or control the team either. A technical manager needs to understand the business, and needs to set a vision for the team, but the primary role of a technical manager should be to clear the path of developers to make them the most productive they can be. Read about the ScrumMaster role in the Scrum project management process. It’s a great description of a technical manager’s priorities.

5.Humility. Developers have egos. As much as I’ve tried to pretend that’s not true, it is. It’s crucial to understand that for a technical manager to successfully bring a team together, the "I’m the boss of you" attitude can never show it’s face. A manager who assumes they are superior to the people on their team both promotes the wrong assumption that managers are "above" developers (how do you think the wrong organizational structures came to exist in the first place?), and provides a horrible place to work.

In addition to the character traits of technical managers, it’s critical for a developer to have a clear grasp of what the job role will include, in terms of day-to-day activities. Andrew Tokeley has a good write-up of what you can expect. I think most developers considering a move to a managerial role force themselves to believe delusions like "I can still write a lot of code" in order to make the move more palatable. I’d argue that, depending on your company culture, you’ll probably write less code than even Andrew indicates in his charts.

Over a year ago I took the plunge from developer to team lead. It’s been an interesting ride. Frustrating, rewarding, educational, and enlightening. For the right type of person, it’s a good move, if you’re ready for it. For the wrong type of person, you’ll never be ready for it, so avoid it like the plague. If your company forces you to become a manager to "move up", either be satisfied staying put, or find a new company that has a clear technical career path. But overall, do what you enjoy, and do it well.