The Individual Contributor to Engineering Manager Switch

I was in a session for people that might be curious about trying management out to talk with existing managers to hear why they made the switch, what kind of problems exist, and why they keep doing it. This got me thinking about some of the common issues that come up, especially when making the individual contributor (IC) to engineering manager (EM) switch, that are worth talking about. Most notably, I’d like to talk a bit about rewiring your reward center as an engineering manager since you probably are not doing the same things that used to give you satisfaction.

Rewiring Your Reward Center

One of the things that came up, and a relatively common occurrence from folks transitioning from IC to EM, is the need to rewrite the satisfaction centers of your brain a bit to continue to feel successful. If you’re an engineer, debugging a code issue, pushing a feature, and all the many other small dopamine hits are easy to get just about every day. Switching to management means you are choosing to forgo those things most days favoring observing your team and surroundings at a different level to take a different kind of action. However, this doesn’t mean you should give up on similar product-oriented thinking and bug fixing, you might just need to shift your perspective.

Management can feel quite lonely sometimes as you are less likely to get more direct feedback in many cases. Furthermore, the needs of the role are different per team, so it can be quite challenging to give another manager feedback since you don’t know the intricacies of their team dynamics. Looking to establish a peer group is still going to be valuable as a manager, however understand that it might be less solution oriented than seeking engineering advice from an engineering peer.

The kind of things that I now see as small rewards that I used to mark growth are things like seeing engineers speak up in meetings and gaining comfort addressing senior leadership without breaking a sweat, managers telling me their team is more often than not running itself, and they are trying to figure out how to use their time wisely, and peers outside my team asking me about one of my team’s processes. These are small, and certainly more nascent than shipping a feature to production, but it’s where I’ve personally learned to read this as some small successes.

The other useful tool I’ve offered is to give new managers the framing that their organization is the product they are building, and can (and should) approach it as such.

Organization as Product

Embracing the thinking that, as a manager, you’re still building a product, but that product is actually an organization of humans, was incredibly helpful to me. It let me think about what makes a best-in-class organization and what I needed to do to get my organization to that point. The core ideas I usually lean on are as follows:

• Iteration
• Transparency
• Letting Go

Iteration

Just like any product that you ship to customers, you need the ability to iterate on your organization as the growth might not be linear and the needs might not be linear. Building a focus around iterating will let you experiment with ideas for the team, as well as build an honest feedback loop with those that you’re responsible for of what is and isn’t working.

Using the same experimentation approach you would for a product feature can still apply here. Build a hypothesis, present the experiment with a time box to ensure there is a time when you will re-evaluate this decision, get some buy in, run the experiment! Keeping strong alignment with the time box that was set forth will let you also build trust and demonstrate accountability to the team. A team is not a static thing, so your process likely shouldn’t be static either.

If you don’t know where to start with iterating on your process, that’s a great place to start! Perhaps the team is missing a ritual like a regular retrospective to reflect on what they’d like to stop or start doing? If the team keeps meeting deadlines, perhaps it’s worth a specific retro to find out how we might better estimate. As you iterate, you may need to introduce or remove team rituals which will be little checkpoints in your process which will provide as much value as you and the team put into them.

Transparency

Being open and honest about why decisions are made, why processes have failed in the past, or even just what the team is currently working on are all versions of transparency that are valuable to different sets of stakeholders. Just like an application that has no telemetry, a team that is perceived as a blackbox is likely going to make things a bit more challenging both inside, and outside, the team.

Onboarding new folks to an opaque team is challenging as it might not be readily understandable how the team operates since there are no holes cut into the team’s operating process. This phrase was made famous by Andy Grove’s excellent book, High Output Management, but the sections around the black box are well summarized by Michael Dearing here. Being able to let people inside the team and outside the team peer into the process, and be aware that the team has a desire to be transparent will be valuable to create an open dynamic.

Letting Go

Building an iterative process by which you can address needs on the team is critically important, but so it gives the team the time and space to actually figure out what things are broken. There will never be a shortage of things that feel like you should fix them immediately, so you will have to learn to build a sense on what is actually urgent and important to fix/unbreak immediately. For this, I use an Eisenhower matrix to visually bucket things into different quadrants to see where I could/should delegate some things as stretch opportunities for others on the team, or where I actually shouldn’t do a certain thing.

The tool is less important than building a muscle around whether now is the right time to step in and start working on something, or if this is an errant data point for the time being. It’s a hard skill to build, but it comes with time, and it comes with being able to feel comfortable to let go a little bit. Being able to do this will also be a key way you scale yourself as you continue down the manager’s path in the future.

—

Rewriting your reward center is not the only thing that made the switch easier, but it certainly was the largest thing that helped me along my journey. Over time, you accumulate more tips, tricks, and tools to figure out what the shape of engineering management on your team actually is. Hopefully, this helps.