While I could applaud many of the excellent VP and CTOs in technology, I would like us all to take a moment to give thanks to some unsung heros…. The Frontline Software Development Managers. These brave souls either volunteered, or in many cases were “voluntold”, to go from being responsible for their own excellence to being also accountable for bringing out the excellence of their direct reports. A dramatic shift for someone who has spent much of their career to date focusing on their technical expertise.
These brave souls often have no idea what they are getting themselves into. Generally because the person promoting them into that position knows how to handle any of the situations that the new manager will run into, but doesn’t know how to transfer that knowledge. There isn’t a set formula that can be used in any situation, each has different nuances that have to be factored in to have the right response. The middle manager at minimum will hopefully get the new manager the HR training they need to avoid a lawsuit and go over some basics on how to handle their job responsibilities; they then will meet regularly with the new manager to advise them on situations without solving the situation for them.
Most new managers will be promoted within the company they are currently working as a developer, and unfortunately their first direct reports are their former peer developers (and maybe even peers who wanted the management position for themselves). The new manager may have been given authority from above, but they must learn that they can’t use that authority as their primary tool to get things done or else the team will rebel. They have to earn their direct reports respect as a leader, then use influence more than authority to lead them. They also learn that they can’t be seen just as a peer anymore, they have to establish a little distance from their former peers -- still close enough to know their direct reports needs, but separate enough that despite any sense of friendship the manager will do what’s best for the company.
One of the tough psychological changes new managers run into is realizing their sense of worth now has to come from how their direct reports perform versus their own contribution. Managers who don’t adjust to this change often feel like they aren’t getting much done since their own coding contribution is much lower, or they try to kill themselves by working long hours and weekends to regain that feeling of accomplishment (which they ultimately can’t sustain). Sometimes it's hard for the new manager to deal with the fact that they are ultimately accountable for any poor performance by any direct report -- despite what excellent guidance they may have given to that person. It’s now their job to either help that direct report achieve or to find their way into a different job, and until that happens their poor performance will reflect badly on the manager.
Managers also have to learn to delegate, even if that means the task won’t be done exactly as they wanted it or take longer than if they did it themselves. Managers are given a team and are expected to use that team effectively. Managers need to learn to delegate not only so that they won’t burn out, as well as giving others a chance to lead. Managers need to learn that we don’t expect them to be the smartest person in the room, we expect them to work with their team to come up with the best ideas, and we expect that some of their people will have technical expertise that exceeds their own.
We expect Front Line Development Managers to maintain their technical skills enough to judge the quality of work of their direct reports and help each developer work on their technical mastery. At the same time, we have reduced the amount of time the manager themselves gets to code and work on their own mastery. We may start a new manager with an idea of 50% management and 50% coding, but over time as issues and priorities continue to mount, the manager finds themselves spending less and less time coding. The more time spent in management, the harder it is to go back to a purely technical role, since their former colleagues have now gotten years of full time coding experience.
Ironically many folks go into management furthering their career, and if they want to be a VP or CTO some day, it’s a necessary step. However, if a developer just wants to get into technical leadership or is looking for pay increases, they often would be better off going the architect route. Being a manager means they start getting exposed to some of the unfortunate truths -- the budget for salary increases is limited and tradeoffs have to be made, there are often political consequences to the “right actions”, leaders are not always on the same page, etc. Quite frankly one of the reasons many managers get out of management or don’t advance in the careers is that the can’t stand the politics that occur when large bodies of people work together even with the best of intentions (to see an example join a church governing meeting sometime).
Even with all of this, there are many people who care so much about their fellow developers and ensuring that we have good development processes, they choose to put up with all the heartache (and headache) the position entails. They ensure that we never forget that it’s about helping each developer achieve their full potential for a good cause, not just improving metrics in a spreadsheet. Thank you all who serve this vital role.