I was a developer for sixteen or seventeen years before I stepped into the role of Engineering Manager. I was coming to an age in this industry where I thought people start to expect it of you. I had been a senior developer, a senior developer II, a freelance contractor, a team lead, and had tried out most of the titles and roles a software developer can have. I thought this was the best way I could contribute my hard-earned skills and experience to the company.
And boy did I make some mistakes! I wasn’t given any formal training in how to be a manager or do management things. I didn’t seek out that training. I had been a team lead, I had run my own business for several years, I knew how to lead a team of developers. The company I was working for at the time desperately needed that. And I made some fumbles.
This letter shares with you one of those things you should do: stay out of the software development process. I have made some of the mistakes in this letter myself. I’ve seen others make some of these mistakes. I hope you can learn from them.
You Control Salaries and Promotions
If promotions were quantifiable then it would be easy to get a
promotion. People would have to ship X features to production.
Attend Y interviews. See Z new hires through the mentorship
program. Once you have the right numbers you get a promotion.
An Engineering Manager has the careers of their direct reports in their hands. The company might have some form of career ladder. That ladder might spell out the qualifications and qualities expected of the person filling each role. But when it comes time to promote your direct reports: it’s ultimately a qualitative decision.
And you have biases. Opinions. Preferences. You will inevitably find ways to convince yourself that the developer which is most like you has demonstrated all of the qualifications and qualities necessary for a promotion. You will prefer some people over others.
This is normal management stuff.
HR and the wider organization, if they know what they’re doing, will try its best to correct for those biases. But even they will have biases. It’s human nature.
When you are also contributing code you are going to prefer code from others that is similar to your own preferences and style. You will probably have opinions about your direct reports’ code. You will have opinions about how they communicate and what they value. This is another bias you will have to deal with. But it’s one you can avoid.
When you refrain from contributing code as an Engineering Manager you have the opportunity to be impartial. Your duty is to the people on your team and making sure they’re doing their best work. It’s not reviewing their code and judging it. It’s not shaping them to write code the way you think it should be written. It’s not even helping them to ship code faster. Your best work is not contributing code or designing systems: it’s making your people happy and supporting them. The rest will follow when they do their best work.
Don’t let your preferences for code and architecture prevent people on your team from getting the promotions and job satisfaction they deserve.
They deserve a manager that tries to be impartial, fair, and supportive.
You Have A Chilling Effect
As the Manager on the team your direct reports are acutely aware of the power dynamic. They know that their promotion and future prospects rest on your perception of them. This is why you should avoid contributing code, reviewing code, and generally having an opinion on anything related to the code.
As a Manager you are invested with the power of the shareholders to ensure that the workers reporting to you are providing value to them. You are an agent of exploitation in the system of capitalism. Whether you like it or not this is how people will view you.
When you review their code people are concerned about their future job prospects.
When you enter a meeting people are concerned about their future job prospects.
When you have a bad day or don’t like what your reports are doing they are concerned about their future job prospects.
Everything you do matters to these people. So act accordingly and don’t get in the way. Stop trying to be a developer. Engineering Management isn’t being a developer with benefits. When you try to be involved in the development process you are preventing people from doing their best work and are implicitly pushing them to work on things that will get them promotions or help them keep their jobs.
You Will Get In The Way
As an Engineering Manager who contributes code you are occupying space that could be filled by one of your developers. You are taking away opportunities for them to learn, gain experience, and advance their career. You are getting in the way.
You might think you are helping. After all, if you are able to contribute code, it probably means you were a developer before and you can use that experience and those skills to guide your team. After all your wisdom and experience led you to this career. You can show them how you want the system designed. You can let them fill in the implementation. You can guide them to being better developers… like you!
It’s in the title! Engineering. Manager. You are supposed to do the heavy work of designing the systems, setting the standards, reviewing the code, guiding your developers, leading the way!
Only, it’s not that at all.
That is work for your developers to do. They are the ones with the skills, experience, and responsibility to design and develop software to solve problems. It’s their job to do those things.
As an Engineering Manager your job is to get out of the way and let them do those things. To support them. To make sure the organization knows how much ass they are kicking. You are a Manager first and foremost. The Engineering part of the title is because you understand acronyms and percentiles.
You Are A Manager
You need to stop thinking of yourself as a developer. Maybe you were once. That’s over now.
If you want to contribute code you need to hop the fence and be a developer again. That’s a fine thing to do. I think every developer should try management at least once in their career for a while. Get a taste for the problems managers face. It helps you build empathy and gives you the chance to flex your negotiation, communication, social, and time management skills.
When you try to be both at once, developer and manager, you’re not going to be great at either. You’re going to promote people whose work reflects your biases and values. You’re going to stymie otherwise great developers. You’re going to get in the way of people doing the work they enjoy doing. And you might burn yourself out.
If the idea of sitting in on meetings, negotiating with people, dealing with performance reviews, making the crushing decision of who to promote, having difficult conversations with people about their performance, and working with HR is not appealing to you: maybe you’re not a manager after all.
Epilogue
I spent a number of years as an Engineering Manager. I am writing this letter to you now in the hopes that you will not repeat what was done herein. I went back to being a software developer full-time because that is what I learned in those years that I enjoy the most. I was getting in the way because I liked it so much and it was harming the people that reported to me.
Go back to the code. It’s alright.