The trap of slowly ramping up from Engineering to Manager

Becoming an engineering manager I have seen can happen in at least one of two (there are more) ways: slow ramp-up from a team of 2 (you and a report) or an overnight large team switch. In this post, I will talk about my experience (and failures) of the first one.

An engineering mindset #

One of the patterns in software development to migrate from an older system to a new system is following the Strangler Pattern.

In a nutshell, wrap the old systems in an API, and slowly route traffic to the new emerging system(s). The main goal of this is to reduce the risk of a big rewrite (there will be bugs) and allow for a smooth transition.

So my manager came to me with the opportunity to become an engineering manager, I would have a team of 1 and take on a very necessary but narrowly scoped project. The goal was to balance between making and managing, and this sounded like a reasonable way to approach the problem.

A bit like the strangler pattern, I would add a layer on top of my existing maker mode and gradually migrate to this new manager functionality. This reduces risk in the transition since there is little overhead of communication, 1-1s and amount of admin associated with managing the one other person in your team which you work with all day long.

This worked well and both my report and I were happy and managed to delivery in time and also build rapport among us. I felt like I was really good at this new management role.

Scaling up the two-person team #

Projects are getting delivered, my report’s feedback is good, spirits and productivity are high. First few months pass by and surprise, success pays off and I got a larger team. We are now three, we got larger scope projects and stakes are higher.

This scaling up process went on and on until I reached the current count of 6 direct reports and around 2 years since it started. Then something clicked, the amount of work of my new management function was overtaking my previous maker mode. Basically, I was still trying to make time for my maker mode while keeping up with increasing managerial responsibilities. The legacy system was fighting back.

Engineering management is not a promotion, it’s a career change #

And what happened to me when I had to consider a career change? I end up in an identity crisis.

I had always defined myself as a software developer, someone that solves problems usually by writing code. I felt in the zone and at my best when I was getting to rejuvenate an old legacy system into a new life, constantly looking for the next challenge to test my skills.

I love working in software and solving problems, lots of emotion goes into it and it’s what I’ve been doing for a very big part of my life. It’s now obvious to me that it will conflict with the new emerging identity of the manager.

The moment of realisation #

I think that the slow build and gradual increase that made this process a lot more subtle and ultimately harder to acknowledge. Somewhere deep inside there was a sense that things were changing but I could not make sense of it soon enough.

This is by no means a criticism to the support I had been given to start with, there were plenty of signs along the path and people trying to let me know where I was headed.

So after almost two years that it took me to realise the role I had volunteered into, it was now that I had realised the price: things had to change.

Going back to why #

I’ve recently started on a path to incorporate reading into my habits, originally the motivation was to reduce my consumption of technology and work on my focus.

I managed to make good progress and apart from my focus slowly building up, I also started finding myself reading up on quite relevant and interesting topics.

Two books that made a huge impact were Start With Why from Simon Sinek and Atomic Habits from James Clear, and even though it may not be immediately obvious these two books have one key topic: identity as the base for behaviour.

Sinek calls it the Golden Circle and explains how really successful companies (movements, personalities) differentiate from the rest. The key is they have a very strong identity and bring it to everything they do, they communicate by starting with why they do the things they do, then how and finally what.

Further along the book he also explains how after achieving success companies can end up losing the identity that made them successful at the beginning and how that can spiral into their downfall.

James Clear presents this concept of Identity-Based habits and again a similar diagram is used where at the centre is the identity (why), then processes or systems (how) and finally outcomes (what). Change can happen in any of these layers, and the key to long term change is the order (again).

By defining who we want to become, this triggers a cascading effect on our processes and finally present itself in outcomes.

To bring up the engineering mindset and quoting Kent Beck:

“for each desired change, make the change easy (warning: this may be hard), then make the easy change”

Reshaping my identity #

One of the suggestions on Start with Why and how to resolve losing perspective on identity is to go back and think about what is the constant that defines us through time, grab that and make it the starting point of everything we do.

A big part of why I do what I do is about people, form the almost 10 years of experience, I always chose to work with people I can trust and lean on, we can laugh together and stand by each other when things are not so good. Some of those people I consider great friends and our relationship span further than the jobs.

Building software was always there, but it was the team and the people that really made it all that much special. And this is what I now understand to be my mission: I want to build this trusting healthy environment where we can have a shared human experience while building amazing software products.

Wrap up #

Writing this up was mostly a cathartic mechanism, I been finding that writing things down helps settle my thoughts. I hope that by publishing this someone else can benefit, identifying the slow raising temperature before boiling and making the adjustments to a happier, more meaningful career.

Links to books


Now read this

The developer years - Part 1

The first job was back in 2009 in my hometown: La Plata, Buenos Aires, Argentina. Sort of halfway in my Computer Science career, I got connected to a professor from the university that was looking for developers to work in a small... Continue →