Changing Roles: from Engineer to Manager 👔

How to stop thinking as a player, and start thinking as a coach.

and

Mar 10, 2022

One of the most difficult transitions that I’ve gone through, and have since supported numerous others going through, is the transition from being an engineer on a team to being the manager of that team.

I’ve always learned best by reading, so at the time I picked up a copy of Andy Grove’s High Output Management. One of the book’s highlights is Grove’s seminal take on management:

The output of a manager is the output of the teams under their supervision or influence.

But I’m not going to lie – I didn’t know what to do with this idea. How could I increase my team's output?

I could try to spend more of my time coding.
I could try to grow my team.
I could push the team to work harder.

Each idea seemed appealing, but also came with serious side-effects. I was in a tailspin.

The best advice I can ever give anyone in such a tailspin is: step away from the keyboard. (Or, as I later learned from an unlikely source, Dora the Explorer: “let’s stop and think.”)

Hey 👋 this is Luca! Welcome to a ✨ free edition ✨ of Refactoring. Every week I write advice about some engineering or leadership topic, backed by my own experience, research and case studies.

This is a guest post written by my friend Louis Bennett. As an EIR at Reforge, he leads its programs on Engineering Management and Technical Strategy. Previously, he was VP of Engineering at VSCO and led engineering teams at Intercom & Trulia.

Fast forward four years. I’m checking in with a first-time EM on my team, Sasha.

They’re new to the role, and grappling with the same question that threw me for a loop: what is my job, exactly, and how can I be effective?

If Sasha’s job is to deliver impactful and reliable output, how should they think about their role, vs. their teammates’?

I am a big sports fan, and I like to think of this as the transition from being a player to being a coach — things that make you effective as a coach are often quite different from those that make you effective as a player. Just like IC vs EM roles.

Let’s dissect this a bit, using basketball as an example:

🏀 As a player, you’re on the court. You’re responsible for executing plays and defending effectively. You may be the captain, in which case you’ll also make decisions in real-time on which plays to execute throughout the game.
👔 As a coach, you’re off the court. You set the strategy for the game, and build the plays that the team executes. You’re responsible for ensuring your team is healthy and strong – physically and mentally. And, when the game is not going your way, you’re responsible for picking the right play and/or changing strategy accordingly.

✏️ Creating the plays

The best coaches differentiate themselves by coordinating their team‘s efforts effectively and continuously. Similarly, as an EM, the most effective levers you have to influence your team’s output are the systems and processes of how it works. You set the direction for the meetings you have and the way they run.

Just as coaches watch the tape after a game to plan improvements, you can leverage regular retrospective meetings to address inefficiencies and adjust how you work to improve output every week. Done well, you’ll also have your team thinking about ways to increase its impact.

🔍 Keeping focus on the court (while you’re off the court)

Let’s return to Sasha, the first-time manager I mentioned earlier.

In their previous role as senior engineer on the team, they were used to taking on complex tasks each sprint, breaking them down, and transforming the sometimes abstract requests into working features.

As they transitioned into management, their natural bias was to continue to tackle the most complex work each week, contributing to their team’s velocity by completing some story points.

Besides, it felt good to be in an IDE, doing “real work” – a break from back-to-back meetings. As Yurii Mykytyn noted in our community thread, the dopamine hit you get from closing out tickets is real!

What Sasha didn’t realize, though, was that by tackling tickets they were limiting the growth of the players on their team. Essentially, they were taking away opportunities for their team members to learn.

By spending their time on development instead of management, Sasha missed the opportunity to step away from the keyboard and craft a strategy for her team to succeed.

Does this mean that, as a manager, you need to step 100% off the coding work? 👇

🏃‍♂️ The working manager

The idea of being a working manager may be laughable, but it does not have to be a paradox, or a curse. Let’s talk about how and when this is okay:

🔨 Take on small, non-urgent tasks — It’s okay to take some tickets when you’re a manager. One strategy I’ve used effectively is to keep a queue of small work items for anyone to tackle between larger tasks. (Using the Eisenhower Matrix methodology, they should be important but not urgent.) If a work item can be started and then set aside easily mid-sprint – and assuming it’s not a bug that’s a direct result of a teammate’s previous work – it fits perfectly in this queue.
👯‍♀️ Pair with others — You can change your focus from solo work to pairing. By working closely with members of your team, you can help them uplevel while you also get deeper insight into how they work.
⏱️ Be realistic about your time — The amount of coding work you can do in a given work week is inversely proportional to the number of people whose work you are responsible for.

When it comes to the time you can spend coding, I like to approximate it mathematically as:

(1 - min(team_size/4, 1)) * working_hours

E.g. if you manage a team of 3 developers, and an engineer spends 32 hours/week on sprint work, you should be able to budget 8 hours. Responsible for the work of more than 4 people? Budget zero.

📖 Building the playbook

Effective coaches create focus for their teams by choosing a strategy and crafting play to win a specific game – the game plan. As an EM, you’ll do this sprint over sprint by guiding choices around what work to do and how.

To do this properly and keep alignment, you need to manage stakeholders effectively.

Whether they are in product management, finance, engineering, or another group, you’ll want to work with them to ensure that your team is focused on the most impactful work in the short and long term.

If you do this well, you will do fewer things at any given time, but have a greater impact.

It seems paradoxical that doing less can get more done, but consider what a lens does: it creates focus by blurring things out. This, combined with doing the right things, is when you can crank the impact knob to 11.

I like how Intercom’s Des Traynor summarized this in his talk at Web Summit 2021:

“Always ensure all the important things are getting done, everyone is working on the most important things they can, and that nothing unimportant is getting done.”

As an EM, you need to know what are the most important things for your company, and that your team is working on them. Your stakeholders should both provide and validate these. At the same time, you need to filter out everything else.

One team’s winning game plan is another’s losing game plan. By leaning in to what’s important to your team, you are more likely to win.

❤️ Ensuring your team is healthy

One thing that’s a clear equivalent between sports teams and software development teams is: they’re made of people.

It doesn’t matter how much of a wunderkind your favorite coach is – if the team’s players are not healthy, the team can’t reach peak performance. Recently, focus has shifted from solely physical health to also include mental health – not just baseline health, but also in consideration of peak performance.

The exact same thing applies to software teams.

As Emmanuel Conrardy pointed out in the community thread, most teams have some aspect of dysfunction. As a manager, it’s on you to address them. As numerous Olympic and World Cup teams have proven over the years, players that are fit but don’t gel together can easily lose to a team that’s less fit but more gelled.

You can coach your team to peak performance with conversations and feedback. As a manager, your 1:1s are a perfect place for regular health checks. If your check-ins tend to focus on tactical work items rather than individual and interpersonal ones, here are a few simple questions to try out:

☀️ How are you doing this week? Listen! Take off your manager hat for a minute and be a curious and empathetic person – besides building trust, you might learn something new. For example, higher or lower performance often depends on reasons outside of work. Your report is not obliged to share those, of course, but they might if they sense that you sincerely care about their wellbeing.
❤️ How do you like to receive feedback? This simple question is one of those you can ask in an initial 1:1s. Not only does it help to understand someone’s personality, it lays the foundation for trust by showing that you want to create an environment where they can do their best work.
📈 How do you think <project> is going? Do you think there’s anything about how our team operates that has helped or hindered the project? As a manager, hearing others’ perspectives on your projects is like viewing the same play from different angles. This line of questions, in particular, can help to surface and debug interpersonal and interdepartmental issues that can impede delivery.

Last, but not least, when taking care of your team, don’t forget to take care of yourself! Besides prioritizing basic human things like eating and sleeping well, step away from the keyboard and ask yourself the first and last question above every once in a while.

That’s it! I hope the ideas we’ve touched on here are useful. I’m working with a lot of folks much smarter than me to unlock more ideas, tools, and frameworks for Reforge’s newest program, Engineering Management.

If you're interested in joining the program, the Spring cohort kicks off the week of March 21. Check it out below, then apply to join 👇

✨ Learn more about the program ✨