What Scaling an Engineering Team Taught Me

There is a specific moment when your job stops being about the code you write. For me it came somewhere between founding Estoul, where I wore every hat because there was no one else to wear them, and leading larger teams at Majid Al Futtaim and Careem, where the code I personally wrote stopped mattering almost entirely. The transition is not a promotion so much as a change of job. Most of the advice I got early on missed that. Here is what I wish someone had told me.

Your output is no longer code

As an engineer, a good day is measured in what you shipped. As a manager, you can have a great week and touch nothing in the repo. That felt wrong for a long time. The reframe that helped: your output is now the decisions your team makes when you are not in the room. If they consistently make good calls without you, you have done your job. If everything routes through you, you have built a bottleneck and called it leadership.

Distribute context, not decisions

The instinct when a team grows is to centralize. More people, more moving parts, so you try to stay in every thread. It does not scale, and it is the fastest way to burn out. What actually scales is context. People make good decisions when they understand the why: the constraints, the tradeoffs, what the business actually needs. Most bad decisions I have seen were not a lack of talent. They were a lack of context that a five-minute conversation would have fixed. So I spend a lot of my time making sure the why travels as far as the what.

Hire for judgment and trajectory

Skills are easy to assess and easy to teach. Judgment is neither. When I interview, I care less about whether someone knows today's framework and more about how they reason: how they scope an ambiguous problem, what they choose not to build, how they talk about a project that went badly. A strong engineer who is still learning will out-deliver a polished one who has stopped, every time. Hire for the slope, not just the current position.

Process is a tax

Every process you add is a tax the whole team pays forever. Sometimes it is worth it. Often it is a scar from one bad incident that you are now making everyone pay for. Startups taught me this the hard way. At Estoul there was no process to hide behind, so we only added a step when the pain was real and specific. I try to keep that discipline even in bigger orgs. Before adding a ritual, ask what problem it solves and what it costs. If you cannot name both, do not add it.

The job is mostly removing things

Engineers do their best work with long stretches of focus and a clear sense of what matters most. Almost everything about a growing organization works against that: more meetings, more stakeholders, more context-switching. A lot of my week goes into removing things. Killing a meeting. Saying no to a request so my team does not have to. Turning ten priorities into one. Protecting focus is not a nice-to-have, it is the whole game.

Being kind is being clear

The hardest parts of the job are the human ones: honest feedback, the performance conversation, occasionally letting someone go. For a long time I confused being kind with being gentle, and I softened messages until they lost their meaning. That is not kindness. People deserve to know where they stand while they still have time to do something about it. The kindest thing you can do for someone is to be clear and early, and then help them get where they need to go.

What I keep coming back to

None of this is about being the smartest person in the room. It is the opposite. The teams I am proudest of are the ones that got better without me in the loop, where good decisions kept happening whether I was there or not. That is the real measure. Build people who do not need you, and the work takes care of itself.