Most software development organizations have a fairly clear path for their individual contributors. Whether they call the job “Member of the Technical Staff,” “Software Developer,” or “Programmer,” a young developer starts at a level 1 and moves up, usually to about level 4 or 5. At this point, successful individuals are usually faced with a choice: whether to continue up the technical path, or move into management.
This is not a discussion of the relative merits of either path (both are good, both are needed in the organization, but the technical side is not what we’re talking about). This is about what happens when a superb, highly-skilled technical contributor moves from a programmer position into a management job.
In some cases, there may be a relatively smooth transition: as a developer gets more and more senior, she takes on further responsibilities as a technical leader, as a team lead, and finally as a front-line manager. It’s an interesting situation, because what the organization is doing (whether it admits it or not) is saying,
Because she is a skilled technical contributor, we want her to stop doing what she’s good at and start doing other stuff.
In some cases, it’s done merely to help the individual proceed into a career path with more authority and money. However, that path is dangerous: I mean, you’re telling someone who is at the “top of her game” to stop doing what she’s valued for, and start doing something almost, but not quite, exactly different.
Smart organizations will say something almost, but not quite, exactly similar:
Because she is a skilled technical contributor, we want her to leverage her skills among a larger group of people.
See what I did there?
In the first case, the transition is done for the individual; in the second, it’s done to benefit the team. It almost goes without saying that the first transition is often problematic for the organization, while the second can be much more beneficial.
In both cases, the individual is shifting roles; in the first case, however, there’s not a clear expectation as to what the organization hopes to achieve in the transition. In the second, however, it’s very clearly stated that the hope is to move the new manager’s skills to a larger team.
It’s vitally important that organizations understand this transition, and that they support new managers in their role. Being a manager is not simply being a programmer but suddenly having more authority; it actually represents a shift from doing to enabling. This is usually much more easily understood: most good technical contributors have already spent some time with the younger, less-skilled members of the team, helping them to learn quickly what she has had to learn by experience.
The biggest change for the new manager is that managing does not involve writing code. Sadly, some organizations want their top contributors to keep doing what they’ve been doing, but also take on management responsibilities. This, in my humble opinion, is a huge mistake. You’ve set the new manager up for failure by doing this; very few individuals can actually continue to maintain a high level of output while learning the new skills required in a management role. It’s much better to make a clean transition; once a person steps into a management role, the expectation of deliveries shifts from the individual to the team.
The new manager now has to delegate, train, and support her team members instead of delivering. There’s a huge temptation to jump in and “do things right,” as she has been used to doing for so long. (And, honestly, if the situation is critical, it might still need to happen.) However, the organization will be better off in the long run if she can help her team take on the tasks that she was used to performing.
In this case, the move to management becomes a “force multiplier,” to use a military term. Instead of one great developer, you now have five or ten developers who are all moving to that level. The team is correspondingly more productive, and the transition is happier for all concerned.