Why Engineering Managers Still Want To Write Code
3 reasons for wanting to keep your technical skills active when your main role is leading teams of engineers
It’s a common topic. Should an engineering manager keep writing code and stay hands-on technically once they take on a leadership role? There are countless articles out there on the subject.
But what is it that makes an engineer manager ask this question in the first place? Why is it even a thing? When your main goal is to lead a team and enable other engineers to be great, why focus on work that doesn’t have the biggest impact or add the most value to your team?
From my personal experience of going down this route and asking myself the same questions, I feel there are three main reasons that motivate someone to think this way.
Coding Gives You Energy
The vast majority of engineering managers will have found their way into that role through a successful career as some kind of software engineer or in another hands-on technical role.
If you’ve been an engineer for long enough to be considered for a management role, then you’ve clearly been around for a few years writing code and building things. This means you must have a certain passion for coding and technical work.
For someone who enjoys the technical work and finds it gives them a great deal of satisfaction, often the work of leading and managing a team won’t necessarily give that same kind of joy. When you’re motivated by building, creating, problem-solving, and seeing that tangible output from your work, it can be a big shift to try to achieve the same pleasure from watching other people do that instead.
If you’re anything like me, you get real energy from writing code and producing outputs that you can see. You start to really miss that when you don’t code so much anymore.
Perhaps you’ve experienced that feeling of getting to the end of the day or the week and thinking, “What have I actually done? What have I got to show for all that time I’ve spent working?” When the answer is along the lines of “You enabled a team of engineers to build great things and to be awesome,” you can often be left feeling slightly unfulfilled.
As an engineering manager, your success is measured by things like your team shipping a valuable new feature on time or one of your engineers getting a promotion thanks to your mentorship and coaching.
That’s still great and hopefully does still give you some level of satisfaction, but it’s not the same as being able to point to something like a feature in an application and say, “I did that.”
Then there’s the more difficult and challenging side of management, like dealing with people problems. Perhaps someone on your team is having a tough time in their personal life and needs some emotional support. Perhaps one of your team members is underperforming and needs extra help and a formal approach to helping them improve. Great managers can find joy and energy in those situations too, but if you ultimately prefer working with technical problems rather than people problems, then you may in fact find this quite draining of your energy.
Slower Feedback Loops
Being a software engineer usually involves a constant series of short feedback loops — relatively short periods of time between doing something and seeing the results of that thing.
If you’re using test-driven development (TDD), you write a test, see it fail, write some code, see the test pass, done. On to the next one. All within minutes or even seconds. That constant stream of little dopamine hits, giving you the pleasure of seeing your work come to life over and over again.
If your team uses continuous integration and continuous delivery/deployment (CI/CD), you see your code out there in the production environment being used by your customers within hours or even minutes. Again, a fairly short time between doing something and seeing the impact of that thing adding value to people. Very satisfying.
But as an engineering manager, those feedback loops are longer — often much longer.
Perhaps you’re putting in place a new career development framework for your team to help them progress through the organisation. Not only will it take a long time to create and release that framework, but the outcome of seeing one of your awesome team members get a promotion can be weeks, months, or even years away.
Maybe you’re refining some engineering practices and helping your team switch to trunk-based development. Again, that’s not something that’s going to happen overnight. It will be quite some time before you start to see the impact of those changes come to fruition.
Instead, each hour and each day is often about lots of little nudges. Moving those initiatives along bit by bit, never really getting to that ultimate payoff until a later point in time.
Future Career Prospects
For those new to management or who have been there for a period of time and are not sure longer-term if it’s the right direction for their career, another driver for the question of whether to write more code may actually relate to future roles and what your career options are.
It’s increasingly common to hear of people switching from manager to individual contributor on what Charity Majors calls the “Manager/Engineer Pendulum.”
But if you’re not currently getting stuck in with coding as much as you used to, then it’s possible you’ll suddenly stop one day, look around, and think, “I haven’t written any code for six months and I no longer have the skills to go back to a hands-on role.”
You start thinking about applying for engineer roles and dreading the prospect of a technical test during the interview because you feel like you’ve forgotten everything you ever knew about how to code.
Of course, that’s not the case. Sure, you’ll be a bit rusty if you aren’t hands-on every day, but you will not have forgotten everything you knew. It can just feel that way.
Understand and Acknowledge the Feelings
If you’re wondering whether you need to write more code, it’s important to understand your own reasons.
If your passion truly lies in being an engineer rather than managing a team, then start looking at how to make that happen. You owe it to yourself to do what ultimately makes you happy. But perhaps even more importantly, you also owe it to your team.
As an engineering manager, you are responsible for supporting your team and helping them be their best. That should be your main focus. Their careers and their development are in your hands. If you no longer truly care enough about that to be fully focussed on doing all you can to make it happen, then you need to be honest with yourself and let someone else take that role.
There are plenty of people out there who are awesome managers and who really do genuinely love it. They derive true joy and energy from enabling a team to thrive. It’s perfectly fine if that’s not for you, but it’s crucial to recognise it and do what’s right for everybody.
Thanks for stopping by and reading.
