I committed the original sin for someone who loves to code. I became an engineering manager.
Do I just love meetings? Am I a glutton for punishment? Or is there a way you, too, can be a full-time manager while still exercising your love for writing code? I’m here to tell you that it is indeed possible. But it only works if you are thoughtful and strategic about it.
The absolute worst case scenario is that you, as an engineering manager, are responsible for critical code paths and end up being a roadblock for the rest of the team. Let’s make sure you don’t do that, but instead get set up for success as a manager while also exercising your creative muscle for writing code. Dare I say that if you execute this playbook correctly, it might even make you a better manager for your team.
But first, are you sure you want to be a manager?
When I started my career at Mux, I was solidly filling the role of an individual contributor (IC). Jack of (almost) all trades, I was willing to jump into any project, learn quickly, and ship. This worked really well for me because I was challenged and also felt like I was providing value to the company in a tangible way.
At times, I was jumping into programming languages I had very little familiarity with. I definitely was learning and stretching and growing in new ways.I’m fairly certain I could have stayed exactly on that path and been successful. When I got the opportunity to move into management, my first instinct was to resist it, and that’s what I did. But as Mux grew and the opportunities for management continued to present themselves, my curiosity got the best of me. Would I be able to have a bigger impact as a manager? Would me being in a management role be overall better for the team?
I decided it could be an area of personal growth worth exploring even while I was doing well in my role as an individual contributor. I was being challenged by stretching my technical skills in some ways, but in another sense I was sitting steady in my comfort zone. I decided it was time to challenge myself and contribute to the team in new ways.
Finding the real challenge
I can honestly say that when I first decided to step into a manager position, I didn’t know if I’d be any good at it. Would I like it? Would my team like it? The only thing I knew for sure was that my day-to-day work would start to look a lot different. This was more than mildly scary, because I really do love to code. Pure bliss to me looks like an empty calendar, headphones on, vim and Chrome devtools/terminal open so I can get straight into my flow state.
I feared that I was giving that up. Would I ever look at my calendar for the day and see a blank slate, waiting for me to put on my headphones and enter my flow? I feared that I wouldn’t stay up to date on the latest developments in programming. What if I tried management and hated it? Sure, I could go back to being an IC, but by then would it be too late? I’ve heard a lot of stories about people moving from IC work to manager and giving themselves a job they hate. I did not want to be in one of those stories.
Growth mindset
Lucky for me, Mux takes management extremely seriously. Some companies have a natural or implied progression from IC to manager that feels something like: “Well, you’re doing great at writing code, now in order to get promoted you will have to manage other people who write code.”
Thankfully, Mux does not work like that AT ALL. We have pay scales on both the IC track and the manager track that grow to the same levels of compensation. Of course, it’s natural for some engineers to make the transition to engineering manager, but that is not at all the norm. Management is viewed as an independent skill that needs to be cultivated, practiced, and learned on its own.
All folks transitioning from IC to manager at Mux have a meeting with Jon, our CEO, where he reiterates the importance of good management, Mux’s philosophy around it, and what resources are available to help you grow as a manager. The message out of this meeting was clear and direct:
You are no longer measured by your individual output. You are now measured by the output of your team.
This hit me like a slap in the face. I secretly thought in the back of my head that if my team wasn’t meeting deadlines or wasn’t pulling their weight, I could just white knuckle it, pull a few late nights, and get it across the finish line by writing the code myself. But it was very clear to me after that first meeting with Jon that this is not what good managers do. Good managers lead teams that produce great work.
You can still code, if you are strategic about it
If you are a manager who loves to code, there’s still hope. And I’ll give you a framework that has worked for me.
Don’t be an obstacle
Rule number 1 about coding as a manager: don’t ever block the critical path. The manager’s schedule tends to be full of context switching and meetings. It’s the worst possible recipe for being a productive software developer. As a result, any coding you end up doing is going to take longer than expected, likely exceeding even your most conservative estimates.
So, if you’re going to write some code, make sure your team isn’t blocked by your work. It’s already a mildly uncomfortable situation when team members have to hold each other accountable; it gets doubly uncomfortable when the person you are holding accountable is your boss. Don’t be an obstacle for your team. If you are, they might secretly resent you for it.
Choose your projects carefully
That doesn’t mean you can’t work on anything important. You can! But you shouldn’t have your hands in the most important or urgent things that your team is working on. The kinds of projects you have your hands on should be more peripheral. For example: fixing an edge case bug, adding a standalone feature that doesn’t impact other parts of the code, updating a dependency, or refactoring some outdated code. It really depends on your specific project, but make sure you pick something that you are confident you can complete. You don’t want to have your work sitting half done on a branch forever because you haven’t gotten around to finishing it.
This is a chance to build empathy with your team
Think of this as an opportunity to build empathy with your team. By jumping in and writing some code, you’ll have more understanding of their day-to-day development work. You’ll be familiar with the development environment they work in. You’ll have a deeper understanding of the project’s architecture, which will help when you’re doing planning cycles with your team.
This is way easier at a dev tools company
It does not escape me that part of the reason it’s easy for me to code as a manager is that Mux is a developer tool. The team I’m on builds Mux Player and Media Chrome; our product is an API for developers, for Pete’s sake. The vast majority of the coding I do is as a user of our SDKs and APIs, which makes things a lot easier. Instead of contributing directly to those projects, I can code as a user. It’s a win/win in which I’m able to more deeply understand both my team’s day-to-day work and our customers’ experience.
Stay curious on nights and weekends
Depending on the engineering teams you work with, the company, and the product, you simply might not be in a position to code anything directly work related. But that’s okay, and perhaps even better. Remember when you first started learning to code? It was all about the fun of building stuff. Try to recapture that childlike curiosity. Coding for the pure fun of it can be energizing.
We work in an industry that moves extremely fast, with new tools coming out every day. At times, that can feel overwhelming and create the impression that you’ve fallen behind. But don’t let that stop you. Dive in again the way you did when you were a beginner. Step outside your job and hack on something completely random. If nothing else, it’ll make you feel young, and it’s a great way to exercise the coding part of your brain that you don’t get to use at work anymore.
Things I learned as a manager that I wish I knew sooner
I’ve learned a lot of lessons as a manager that I wish I knew sooner. When I was an IC, small issues often became big issues. Things that I could have resolved in a day took a week. This is one of those things you have to experience for yourself to actually learn, so take it for what it is. I know I probably read these lessons before I became a manager, but I didn’t really internalize them until I went through it.
Your problems are probably not unique
As a manager, you’re dealing with people. Most of the problems you encounter tend to be people problems. They tend to deal with people’s feelings. Either your feelings, your boss’s feelings, or the feelings of someone on your team. If this is your first time as a manager, it’s very natural to think your situation is somehow unique, but I promise you, it isn’t. The only reason it feels unique is because it’s unique to you.
More likely than not, any problem you’re dealing with as a manager has been dealt with thousands of times by other people. Start by asking for help. Talk to your own manager, or find other more experienced managers to get advice from.
The great thing about having problems that are not unique is that your problems are solvable. Often, the best thing you can do with these people-problems is to find the friction point and lean into it. I find that most times, “the obstacle is the way” to deal with the problems I encounter as a manager. Identify the areas that are breaking down or the things that are not working, and focus on fixing those.
Address all issues directly and immediately
Issues as a manager are like issues in personal relationships. The longer you stay quiet or don’t take action, the worse the problem gets. The things you deal with as a manager don’t really have a tendency to work themselves out. Because people’s emotions are involved, an issue that is minor today might be major in a few weeks. It’s MUCH easier to deal with issues when they are minor. Take action as soon as you feel confident, even if it’s uncomfortable.
If at all possible, work with an outside coach
The leadership at Mux has been incredibly helpful in developing me as a manager. But often, the most helpful voice can be a trusted third party from outside the company. I got the opportunity to work one on one with a leadership coach, and I highly recommend doing that with someone good if you can. It doesn’t have to be a lot, but even a few sessions can go a long way toward getting you out of your own head.
Sometimes I would come with a problem, and as I explained the situation to my coach, the solution would become painfully obvious. Other times, I would be really stuck, and my coach would offer an outside perspective that I hadn’t even considered. And to my earlier point of “your problems are probably not unique”: every single issue, big or small, that I brought up was something my coach had seen before and had tactical, practical, and actionable advice to help me get through.
You don’t need to be a manager forever
It’s okay to have a fluid career, transitioning from IC to manager and back again to IC. And if you go down that path, it doesn’t necessarily mean you didn’t like being a manager or you weren’t good at it. It might just mean you took on the manager challenge, learned, leveled up your own skill set, and later were ready to move on and go back to being a full-time IC. That’s not necessarily a bad thing or an indication that you never should have been a manager in the first place.
My best advice is to learn as much as you can in every situation you find yourself in, take those learnings, and apply them to the next situation. Everything you learn as an IC will help you in some way as a manager, and everything you learn as a manager will help you be a more effective IC.
