The transition from a software engineer to an engineering manager. Pt1.

Intro

There are tons of articles, books, and blogs written about the transition from an individual contributor (software engineer) to a manager, so here’s another one. It is solely based on my personal experience and is very subjective.

I became an engineering manager three years ago. Before that, I was a software engineer for roughly 6 years. Below are my thoughts, observations, comments, and recommendations to someone who finds themselves in a similar situation.

Context Switching 🤹

The first thing that hit me is that I don’t have the luxury of putting on my noise-canceling headphones, playing a favorite tune, and just coding for several hours. Instead, things were changing fast: 1:1s, tech discussion meetings, product meetings, interviews with candidates, catch-ups with people from different departments, etc.

My calendar started looking like Tetris. I remember that by the end of the day, I would come back home and actually try to speak as little as possible. My wife would talk to me, and I would be somewhat numb and struggle to respond. I was drained.

Power of No 🤔

It’s fine to refuse a meeting in favor of deep work. If it’s not something that really needs your presence: 1:1, interview with a candidate, tech discussion where you can bring a valuable input—feel free to click that “No” button in your calendar. As a new leader, you want to participate and be involved everywhere—but you can’t focus on everything. I think that context switching is a productivity killer. Of course, there will be crunch days where you need to grind and be committed and invested in 8 meetings, but it should be rather an exception.

I really encourage you to think before participating in the meeting consciously: if you really need to be there and start going to those where you can really contribute and commit.

Have a plan but also be ready to change it ⏪

As a software engineer, I was used to succeeding by completing planned, prioritized, refined, and precisely described tasks. What I found out pretty quickly is that management is entirely the opposite. To some extend, things are plannable, but not really.

You can’t put into the plan that people in your team will have a conflict, and you will be expected to jump in and guide them out of it. You can’t plan people leaving the company / getting sick.

Deal with uncertainty ⁉️

There are so many variables in the managerial equation — it’s just not worth trying to put up a perfect plan. You have to be ready to accept the change and own it, together with the (light) anxiety that it gives you.

Allow yourself to fail 🧘

The first thing that I got recommended to read as an engineering manager is a “blue book,” and frankly, I think it was excellent advice; however, I understand now that there were many facts/statements that made sense when I read it. After reading it, I thought I would go out into the real world and start implementing what the author suggests. Only now do I realize that this understanding was relatively shallow. The reason for that is that I didn’t fail myself, learned from it, and finally, I had an in-depth knowledge of it. Instead, I tried to practice something that I haven’t earned myself — As Pat Kua writes in this book when describing a tech lead role:

When other people are about to make mistakes, you will want to jump in because you want to help avoid them. You may convince them to use a different solution, but unfortunately, the next time a similar problem arises, they may not remember to take that course of action.

We want to live in the ideal world and always learn from other people’s mistakes, but it simply doesn’t work in some cases. Sometimes you can do that, and sometimes to draw a conclusion, you have to fail and learn the hard way.

To be continued.