As you grow in your career and you get given more and more responsibility, there comes a point in time when the whole texture of reality undergoes a phase shift – somewhat akin to how at some point water starts to turn into vapour when heated enough. This point in time can only really be recognised in hindsight, and the later you recognise it the more painful the recognition will be. This post will help you recognise that point earlier and hopefully save you some amount of pain.
But what changes?
What changes is that the amount of work that your team is responsible for exceeds your cognitive capacities – yours or of any other human. The amount of work being generated is simply too large for any one person to know it all well. It is no longer possible for you to have more context on any given piece of work than the person working on it does. And what this means is that you can no longer 'control' the outcomes of the team.
This of course, comes as a surprise. Until it was just you and your small team of three-four people, you could know pretty intimately what everyone was doing. You would review all the code and jump in with rolled-up sleeves at a moment's notice (and let's be honest, sometimes just for the fun of it). But as the size of the team grew you found that you could not review all the Pull Requests any more, it just caused too much of a bottleneck. You had to delegate the work to others and somehow hope and pray that you'd taught them well enough to bring you close to the output you needed.
Then comes the next blow – you can't spend enough time with new joinees to properly teach them your 'one true way'. This task also gets taken up by others in the team and you stay awake at night wondering if everyone knows what they need to know to be effective.
Predictably, a project gets into trouble and you roll up your sleeves only to find that someone has completely rearranged all the code in the meantime and you struggle to find your way around the codebase. Also, what is this code even? It would never have passed your review! Is this the kind of shit that passes for software engineering in your team now?
Shock turns to fear, fear turn to rage, rage turns to suffering. Pause here.
Ah, so now you know what has changed.
If this moment is still in your future I am sorry for any spoilers that ruin the experience for you. For those of you who have felt the loss of control deeply, viscerally and rising like bile into your mouth I have news for you – that moment is one of the most important moments in your career as a leader of teams. I invite you now to take a closer look at what that moment in pointing to.
Seniority is the trading off of control for influence
Get used, first of all, to the idea that things are now outside your control. Many people will read this and think that just because things aren't in their control it means that things are completely out of control. This is far from the truth. The truth is that 'control' merely means that your will gets turned into reality with a high degree of fidelity. But when the amount of work produced by the team exceeds your capacity, you start to delegate more and more of the work and this necessarily means a reduction in the 'fidelity' of the output.
And when more and more of the work is done by other people, you cannot rely on brute force and constant supervision to ensure the work gets done right.
Running an org is not a strength game. In fact it is more like Judo – where one uses the energy of the situation, instead of resisting it, to guide it to the desired outcome. This is what it means to 'scale' as a leader – to let go gracefully of precision in exchange for scale. In other words – exchanging control for influence.
So what is to be done?
A wise man once said
Never treat a lever like a hammer. You don't get leverage. You get haemorrhage.
Keep reading with a 7-day free trial
Subscribe to The Engineering Organisation to keep reading this post and get 7 days of free access to the full post archives.