Tips to thrive outside of the corporate ladder
When discussing their journey as engineers, managers, VP, or CTO with my friends, colleagues, and peers, a striking observation always remains: there’s a vast diversity of journeys.
I used the word “journey” intentionally and not “career,” as I prefer that framing. I find it particularly restricting to picture progress as a “career ladder,” in which you’d have to tick the boxes to climb to the next level. A ladder is a possible way to visualise that journey, but I encourage everyone to question what their journey should be.
The main issue that I see with the concept of “ladder” is two-fold. First, it suggests that the higher, the better (analogous to similar organisational considerations I’ve always found awful). Second, it indicates that the journey is dramatically linear. To formulate a couple of other criticisms, it also suggests a form of “the sooner, the better,” and even worse to me; it implies that there’s a final rung you can reach (yes, “the end,” my friends).
Still, we all want to make progress in our respective journeys. So, when reflecting back on mine and all the great conversations I had with my peers, colleagues, and friends, I thought it could help to put some of my thoughts on paper to explain how I would personally articulate what that journey could look like for engineering managers.
Allow me to start with a trivial observation. I know very few people who graduate and begin that journey as an EM straight away. To the best of my knowledge, there’s no school with a major in “Engineering Management.”
After a quick research, these options seem to be extremely limited and barely connected to the software industry. This impossibility to start our journey as EM with no prior experience implies a transition period in our professional journey, a point where we decide to become an engineering manager (most of the time after a few years as a software engineer).
The responsibilities vary significantly from one company to the next. Then the way EMs within the same company spend their time can also differ substantially from one team to the next. To be exhaustive, an EM in the same team will probably have to spend their time differently from one quarter to the next.
In my case, at the time of writing, this represented about 32 quarters spent leading a dozen of different teams (depending on how you count), directly or indirectly, in three different companies. Some of these quarters were focused mainly on “shaping processes,” whilst in some other quarters, I spent the majority of my time hiring or building a prototype of a next-gen recommender system (as I would have done as a software engineer), or writing papers.
Of course, these changing points of attention are in addition to all the other more fundamental activities you would expect from an EM: design reviews, giving feedback, helping everyone grow, resolving potential conflicts, and consolidating a vision with my product counterparts. Each company and EM will have its list of fundamentals, but this is at least what was expected in the companies I worked with — which I believe could serve as a reasonable standard for all.
Amongst all these possible activities, how do you grow then? As the terminology might vary between companies, and because the journeys between two EMs can be different — senior manager, director, senior team lead, head of engineering, etc. — I’ll use the fictitious title “Super EM” from now on.
So, what does the transition from “engineering manager” to “super engineering manager” look like? As stated earlier, I don’t think there is, nor should there be, a unique answer to that question. I find it annoying (read: boring) that a ubiquitous answer when discussing this topic around me seems to be, “you need to be managing managers!” This statement alone needlessly blurs the causal line between what’s expected (“managing managers” → “Maybe[Super EM]”) and what is likely to happen, eventually (“Super EM” → “Maybe[managing managers]”).
The way I see it, and I reckon it sounds trivial, is that you need to be an excellent manager to continue that journey toward “super manager,” whatever it means to you if this is what you’re after. There’s no need to be a “perfect” manager and nail every possible dimension (technical leadership, people leadership, etc.) I’ve seen leaders doing “just OK” when leading their immediate team but revealing themselves as incredible managers of larger groups.
I also noticed the reverse — this is again why I think it’s a matter of journey, not ladder climbing. If you want to continue down that EM path (exploring completely other roles is equally valid), there’s a set of fundamentals that need to be fully internalised. If nothing else, this is where “engineering ladders” help: to identify that set of fundamentals valued by the organisation. However, I believe it’s even more critical to appreciate the rationale behind that introspective process.
I mentally picture the underlying hypothesis as follows: if I dedicate 100% of my time to my fundamental EM duties to master them at, say, 95%, then if I reduce the time focused on these fundamentals to 50%, the effectiveness shouldn’t drop to 50%, but maybe 80%.
You read that correctly: in absolute terms, I do think I’m a worse “team manager” now than I was earlier in my journey, as I often need to spend a considerable amount of my time not working closely with my teams–or not as closely as I used to. Now, should I notice something that requires my attention, I know I can trust some foundational skills to provide the necessary support swiftly. I know that if I reallocate 100% of my attention to a problem one of my team experiences, I should feel fully effective because this is how I was operating at some point.
But I consider we need to experience that apex first to decide to throttle back deliberately. If you don’t know how fast a car can go, then when you want to drive more quickly, you should better see if you’re able to. I call that state where we are 80% effective in about only half the time “passive effectiveness.”
The free time newly acquired, thanks to strong fundamentals, is what will define the next step of your journey. Trivially, this can include anything that’s not already included in the other 50%. There is a considerable amount of possible options. To name a few:
- Set up a new team, branch, or office (or improve existing ones)
- Set up new processes. policies (or improve existing ones)
- Set a new goal, direction, or strategy (my view is that most of the time, it’s mostly “refine, improve, remove an existing one”)
- Drive or support the execution of a larger initiative (you can probably provide technical expertise, organisational support, or both)
- Capitalise on your team, strengthen the expertise and drive more impact (can you “squeeze the lemons,” by developing deeper expertise along with your team?)
- Experiment with a different role (does your organisation lack Product / SRE / Data leaders?)
Can you imagine if you could ensure 80% of your EM role in only half the time and dedicate enough time to one of the above as if it was your primary responsibility? This emerging opportunity is my personal view on how to progress in the EM journey. Then there are two questions we need to answer:
- How to achieve this state of “passive effectiveness?”
- How to pick the most relevant item(s) in the list above?
If you onboard with my views so far and ask me these questions, I think there’s one trait that can address both questions. In my personal experience, this is thinking analytically, which allowed me to make numerous deliberate decisions to identify what to prioritise, and the actions I needed to take to make the decisions I would have had to make blindly otherwise. Since we are here, I can use the rest of this article to share how I approached both challenges.
For this first question, I always keep in mind that I don’t want to build perfect teams but high-performing teams. I don’t need that design document to contain “all the details I would have put myself,” I don’t need all the processes to be perfect, I don’t need all the JIRA tickets to look like “what I would like them to be,” and I don’t need the cycle time or other variant to be under one day.
Being specific at first is an excellent way to build up the EM muscle, understand what that means to design scalable and reliable architectures, track and improve the delivery cycles, improve quality and engineering excellence, conduct effective planning meetings, etc. Working on all this with my teams was a fantastic way to develop the fundamental skillset (give adequate guidance, provide feedback, evaluate individual and team performance, etc.)
But as I grew that muscle quarter over quarter, it became like racing an F1 car as an F1 pilot: you know the track so well that you don’t need your eyes to know where to turn, where and how to break, etc. (check out that Ferrari’s Blindfold Challenge With Vettel And Leclerc!) These pilots could enjoy a coffee whilst driving their car, maybe not at 200mph, but perhaps 160mph.
Here, once you master your EM track perfectly, you’re not going to spend the time drinking coffee but exploring the next step of your journey. Achieving that level of proficiency can be highly contextual; to simplify, it probably depends on the car you’ve been given and the track you have to race. But invariably, you’ll need to analyse what you have to appreciate if you need a better engine, different tyres, more fuel, more (or less) pit stops, better breaks, etc.
Once you reach a satisfying state, this is your knowledge of the car and the track that will allow you to drive blindly, whilst you can continue relying on your accrued expertise to react quickly if there’s a sudden change that requires your attention, similar to when the weather conditions change during an F1 race.
To conclude this first part, I believe that a good analytical judgement allows us to identify the fundamentals that need to be solidified; then solidifying these fundamentals is what will allow us to later reach a state of “passive effectiveness” — performing at 80% with only 50% of our attention.
Next, to identify what to do with that 50% time, in retrospect, the answer was also relatively simple to me: observe, analyse, explore. Talking with my peers, colleagues in other parts of the organisation, my team, and some of our business leaders provided me with all the inputs required to paint the landscape of what I could improve in our organisation. Then it was up to me to identify what I thought could greatly benefit the organisation and align with my interests.
Most of the possible initiatives, irrespective of their size and complexity, are achievable with the right level of focus and dedication: this is why freeing up 50% of your bandwidth will be instrumental.
I think it’s also worth sharing that I don’t believe these most transformative initiatives are necessarily the most complex ones, as we‘d typically think about “complexity.” An accurate diagnosis of the pain points and opportunities could reveal that setting up the appropriate meeting (or the right architecture or software component) with the right persons, executed the right way, can help a broad group achieve an objective pivotal for the organisation.
These “low-effort, high-impact” opportunities are often overlooked if the journey we envision — often illustrated in some “ladders”– incentivises implementing complex solutions over solving complex problems. Another thought: we all complain about ineffective meetings; thus, there should be plenty of opportunities for everyone to help improve at least one of them.
The second conclusion is not different from the first: an excellent analytical judgement allows us to identify the untapped opportunities that have the highest potential, and when we can align these opportunities with our interests, we’re on track for the next step of our journey. But, of course, this is only possible if we can dedicate enough time to invest in ourselves. Oh, another possible way to spend 50% of that time growing out of your EM track is, of course, to write.