Most developers at one point or another in their careers have thought about switching to management. Maybe your boss left suddenly and you were the most senior engineer on the team. Maybe you’ve spent a number of years in your current role and are wanting a new challenge. Or, if you’re lucky, your mentor brought up some traits they thought would make you a really good manager. Whatever the reason, you’re here now, trying to figure out whether this is the right move for you.
Transitioning to any role is incredibly difficult. You have new responsibilities, new expectations, different ways of getting results and so on. Moving from an individual contributor (IC) role to that of a manager is even more difficult because you’re actually changing careers.
Technical vs Management Track
One of the first shifts you’ll notice is the change from technical to management track. You’ll still be called on to use the knowledge and experience you’ve gained over the years as a developer but now you’ll use it to estimate deadlines, help plan projects, and mentor engineers on how to architect and build software instead of doing it all yourself.
Another change is the move from a Maker Schedule to a Manager Schedule. As a developer, you need large, uninterrupted chunks of time to focus on technical tasks. Meetings and distractions can derail your focus. The management track is often much more shallow than the technical track. You need to have knowledge of a greater number of things at any given time and be able to context switch more often during the day. Large, uninterrupted chunks of time may feel like a thing of the past as meetings (1:1s, product, sprint, performance reviews, etc…) start to fill up your calendar. In a later post, I’ll outline a number of ways to take back your calendar and free up your time for focused work.
Providing Value as an Engineering Manager
Another big shift between IC and Management is around how you build value for the company. As a developer, you take requirements, write code, (hopefully) test it, ship it and then iterate on it. This cycle can take hours or weeks but the feedback loop is fairly quick. You’re constantly shipping value.
As a Manager, you’re no longer shipping code (or at least not as much as you used to). You’re now helping engineers grow, distilling company goals, writing specs, unblocking engineers, etc… This cycle takes months or years. Sometimes it’s hard to grok the value you’ve provided until an engineer leaves the company or one of the engineers you’ve mentored over the years grows a few levels! Don’t let this discourage you though, as you mature as an EM you’ll be able to see how you provide value, even if it’s not as clear as shipping code.
One way to track this value is to keep track of feedback and decisions you’ve made over the years. A simple log can go a long way and allows you to look back and see how things turned out. For me, this is a long-running note where I store the date, the person/project, the decision or piece of feedback given and then a column for how things turned out. This definitely isn’t a perfect system as it requires some foresight into whether the decision or feedback is important enough to track but it’s useful to be able to reflect and see the outcomes.
Making Mistakes
Everyone makes mistakes, the problem is when you make mistakes as a manager, it often involves people’s lives. As an IC you can build features behind feature flags and if something goes wrong it can be turned off with a flip of a switch. It’s harder for managers to A/B test different feedback formats as it affects people’s potential success at the company. This is another place where keeping a log of decisions and outcomes can come in helpful. You can keep track of the way you provided feedback to someone and then track the outcome over time. Or how you made a decision related to project planning and the outcome of the project.
The most important part of making mistakes as a manager, especially when it involves people is to take responsibility for the mistake and be transparent about how you’re going to improve in the future. Everyone makes mistakes, what people want to see is how you respond to it and improve.
Preparing to be an Engineering Manager
Honestly, there’s only so much you can do to prepare to become a manager. Most, if not all of your learnings will come from trying things, failing, trying different things, getting mild success and iterating. There are a number of great resources you can read if you’re interested in becoming an engineering manager.
Just remember, moving to the management track isn’t an upwards move, it’s a lateral one. Don’t think of it as a career ladder but more of a career jungle gym. If Management isn’t for you just know that returning to a developer role isn’t a step backward.