Field Notes from My Journey into Engineering Management

I am going through what one might call “career puberty”. I’m growing up and moving to an engineering manager role. It’s more of a recognition of a position I reached organically and a job I’ve been de facto doing for some time now, rather than an abrupt change dictated by external factors.

And yet, the change is difficult. What on one hand feels like a natural progression of my career, on the other, it feels like I have to change everything about the way I work.

There are three dimensions to explore: “how I see myself”, “how do I solve problems” and “how others see me”.

How do I see myself

I have always seen myself as a programmer. I like to code and I don’t get to do that anymore. My new responsibilities focus on making sure that the members of my team can code efficiently, not me. And fuck me I do miss coding.

I remember an anecdote my algebra professor used to tell us: there was once a debate between mathematicians and engineers on whose craft is the more important one. The mathematicians proclaimed theirs to be the superior discipline, as engineering cannot exist without mathematics. Plain and simple. The engineers countered by pointing out that without real-life applications, mathematics by itself is worthless. The debate went back and forth for a while and the engineers were winning the argument on the base of practicality: there’s no tangible benefit in doing mathematics just for the sake of mathematics. When all seemed lost, the dean of the mathematicians stood up and said: “We have sex because we like it, not only to have children. Same with mathematics, we do it because we like, not because you need it!”. Needless to say, the mathematicians won.

In a lot of cases, the engineers don’t code for the product, we code because we like it. We code for the code.

It is the same for programming. In a lot of cases, the engineers don’t code for the product, we code because we like it. We code for the code. There’s a certain je ne sais quoi to a well-architected codebase that makes us feel warm and fuzzy on the inside. To the point, that product requirements become somehow secondary.

On the other side of the table sits the product team, whose role is to push for new features and user-facing improvements. For them, the code is just a means to an end. They don’t care whether the underlying technology is Java or python or if the frontend is Vue or React. In the same way, I don’t give a fuck about where the potatoes have been grown when I buy french fries. Or vodka.

The relation between the engineering and product teams is bumpy, each pushing for its own goals and vision. Based on the balance between the two, I see 4 cases:

• they both suck — combining a weak engineering team with a weak product team is a recipe for disaster. Nothing much to do here. Moving on.
• weak engineering team with a strong product team — the product has all the right features but it’s slow and clumsy. Crashes often and new developments are always lagging behind schedule. Full of security holes. Think Windows 95 / 98 / Millenium Edition / XP (I haven’t used Windows in more than 10 years, so I don’t know how the new versions are)
• strong engineering team with a weak product team — the product works really well, it’s reliable, robust, secure, doesn’t crash. Nobody wants to use it. Think hardcore versions of Linux: Slackware, Kali, Arch.
• strong engineering team with a strong product team — the product is nice, usable, reliable, secure, and robust. Think of Google or Apple.

Of course, the last case is the desirable one. Companies everywhere strive to achieve it and spend huge amounts to hire the best and brightest. But at times, the results are not at the level one might expect. The culprit is the everpresent problem of efficient communication. Two teams, two sets of values, two distinct visions. A Venn diagram where the circles don’t intersect at all.

And this is where the engineering manager comes in. It’s my job to bridge the communication between the two parties. And for that, I need to understand product people better.

I’m starting on two fronts: first — actually paying attention during meetings. With the whole shebang: active listening, taking notes, asking questions. And second, finding a common language, by linking product metrics with technical ones. Bounce rate and performance score for example. It’s easier to collaborate when we’re looking at two workstreams aimed towards the same goals rather than the “us versus them” approach.

It feels like going through puberty again. Back then, I was discovering that girls are not actually that bad. Now I’m learning that product owners and projects managers are not that bad either. Let’s hope it goes better this time…

How do I solve problems

As an engineer, I had to solve technical problems. And when confronted with those, I’m applying technical solutions. Which tend to be straight forward: “refactor this”, “unit test that”, “upgrade these libraries”. With the occasional “who’s the idiot that wrote this? Oh, it was me 6 months ago…nevermind!”. Over time, I got really good at solving this type of problems.

But that’s the past now. As an engineering manager, I cannot follow my first instincts and dive in. If there is an issue that prevents the team from reaching a solution, I need to identify and fix that issue, get the roadblock out of the way and let the team find the technical solution.

Trying to code a solution myself is the wrong thing to do. It doesn’t address the underlying problem within the team and, as such, it will most likely reemerge in the future. Even if I try, the impact will be minor. I cannot outcode the rest of the team. I’m good, but I’m not *that* good. And if I could, there wouldn’t be much need for a team to begin with.

I cannot outcode the rest of the team. I’m good, but I’m not *that* good.

Unfortunately, I have seen this in practice several times and invariantly the results have been disastrous: while the extra effort did help the team hit one or two minor milestones, the managers in question got overwhelmed and eventually burned out. The team was left in disarray as the underlying problems were never addressed. And in the end, either the manager or a significant portion of the team resigned.

I need to learn to stay out of the game. From the player, I need to become the coach. But this is the easy part. The difficult part is line-managing other engineers.

As far as domestic animals go, cats are notoriously difficult to train. They’re extremely independent and don’t hunt in packs. They don’t listen to instructions and teamwork is not their natural state. To the point that we have an idiom — herding cats — to convey the difficulty to organize and control a group of inherently uncontrollable entities.

I’m a few months into the job and I feel bad for every manager I have ever had

We have a saying: managing software engineers is like herding cats! There are even books addressing it: Herding Cats and Coders: Software Development for Non-Techies or Herding Cats: A Primer for Programmers Who Lead Programmers to name a couple. And it’s true. It’s complicated as fuck. I’m a few months into the job and I already feel bad for every manager I have ever had.

I need to switch my development from purely hard skills to soft skills. Until now, my focus was to learn framework X or Y or to be up to date with the new trends. Now I need to be able to handle a contradictory discussion without losing my shit.

How others see me

The last point that changes is my relationship with my peers. As a staff engineer that’s been in the company for years, I was seen as one of the veterans. The elders. Most of my colleagues in Frontend have been interviewed by me. I have designed the interview process. My opinion carries a lot of weight.

As an engineering manager, I’m a rookie. Just starting up, testing the waters with my toes. Trying to learn from the more experienced ones. From their successes and their mistakes. I know I will have to learn from my own mistakes too, but this is an area I want to start small.

Time to check tomorrow’s meetings…