If you are good at what you do, stepping back from the work feels like a step backward. It is not. It is the only way the business grows beyond you. Here is what I had to unlearn.
For the first several years of running CX IT Services, I was the best engineer in the room.
That is not a boast. It is an honest description of a problem.
I had built the business on the back of technical capability. Clients trusted us because I personally understood their environments, personally diagnosed the complex issues, personally made the recommendations. My involvement was the product, in a meaningful sense. When things were difficult, I fixed them. When clients were uncertain, I explained. When something went wrong, I was the one who stayed on it until it was resolved.
The business grew. We hired engineers. And I kept doing exactly what I had always done — which meant that as the team got larger, the work I was doing made less and less sense for someone in my role.
I was a director who was behaving like a senior technician. And the cost of that was invisible to me for much longer than it should have been.
The Illusion of Staying Involved
The story I told myself was that my technical involvement was protecting quality.
If I stayed across the complex issues, nothing would fall through the cracks. If I reviewed the configurations, the standards would hold. If I was available for client escalations, the relationship quality would remain consistent.
This was partly true. But it masked something that I only understood later: I was not staying involved because the work required it. I was staying involved because I was uncomfortable not being involved.
I had built my professional identity around being technically excellent. Stepping back from the technical work felt, at some irrational level, like becoming less capable. Even though what I was actually being asked to do — lead a team, set strategy, manage client relationships at the account level, build the business — required completely different skills, some part of my brain had not made the transition.
The result was a business where the director was routinely doing work that should have been handled by engineers, engineers were not developing because the most interesting problems were being absorbed by the director, and the strategic work that only I could do was being crowded out by technical work that others on the team could do just as well.
The Incident That Made It Undeniable
There was a specific moment that cracked the story I had been telling myself.
I was deep into a complex infrastructure issue for a client — hours into it, properly absorbed in the diagnostic work — when I realised I had missed a call with another client that I had agreed to take that morning. Not a routine call. A strategic conversation about a significant technology decision they were about to make. The kind of conversation where my input actually mattered at a level no one else on the team could yet provide.
I had traded the high-value work that only I could do for the technical work that I did not need to be doing. The client with the infrastructure issue had two engineers on the team who were fully capable of handling it. I had not passed it to them because — and I had to be honest with myself about this — I had not wanted to.
I called the strategic client back. The conversation was awkward because the moment had passed. They made the decision without my input, and it was not the decision I would have advised.
That was the cost of staying in the work I was comfortable with.
What Delegation Actually Requires
I thought delegation was about trust. I would learn to trust my team to handle the work, and then I would let go of it.
This turned out to be the wrong frame. Delegation is not primarily about trust. It is about discipline — specifically, the discipline to resist re-engaging with work that is no longer yours to do.
Even when I genuinely trusted an engineer to handle something, I would check in. Ask for updates. Offer suggestions. Make myself available for consultation in ways that subtly communicated that my involvement was always possible, that the ownership was shared rather than transferred.
The engineer sensed this, even if neither of us named it. They would come to me with questions they could have resolved themselves, because experience had taught them that I was available and engaged and would give them an answer faster than working it out would take. I had accidentally trained the team to route around their own problem-solving capacity.
Proper delegation required me to be genuinely unavailable for work I had handed over. Not absent — available for questions, for direction, for review of significant decisions. But not dippable into for the routine back-and-forth that should stay within the team.
This was uncomfortable. It still is, sometimes. The discomfort is the point — it is the sensation of the boundary holding.
The Things I Kept
Delegation does not mean disappearing from the work entirely. It means understanding which parts of the work actually require the director.
I kept the client relationships at the account level — the strategic conversations, the annual reviews, the moments where the business relationship needed to be tended at the senior level. This is work that a director should be doing, and it suffers if it is delegated.
I kept the significant hiring decisions. The culture of a business is set by who is in it. Getting those decisions right matters in a way that justifies director involvement.
I kept the decisions about which clients to take on and which to decline — which, as I have written about elsewhere, is genuinely directorial work, not administrative process.
And I kept the moments where a client is experiencing a crisis and needs to know that the principal of the firm is personally engaged. Not to do the technical work — that is the engineer’s job — but to be present, to communicate, and to own the situation at the relationship level.
Everything else, I have progressively moved out of.
What the Team Gets From It
The underappreciated consequence of a director who holds on too long is what it does to the team.
Engineers who are not given real ownership of problems do not develop the judgment that comes from solving complex problems without a safety net. They remain capable technicians rather than becoming the senior engineers and team leads the business needs as it grows. The director has inadvertently created a ceiling.
When I genuinely stepped back — when I passed ownership and held the boundary — I watched people on the team grow in ways that would not have been possible while I was occupying the space they needed to grow into. Problems I would have absorbed in an hour, they worked through over a day and built a genuine understanding that I could not have transferred by simply telling them the answer.
Those engineers are now the people I rely on. The investment in their development — which required me to be patient with slower resolution times and occasionally messier outcomes than I would have produced myself — has compounded into a team that can handle things I am not across.
That is the business I was trying to build. It just required me to get out of the way to let it happen.
The Question Worth Asking Yourself
If you are a business director or founder who is technically capable in your core discipline — whether that is IT, accounting, legal, trade, or anything else — the question is worth sitting with: are you still doing work that someone else on your team could do?
Not in a crisis. Not when the standards require it. But routinely, as a default, because it is the work you are comfortable in and the strategic work makes you uncertain?
If yes, the cost is probably invisible to you right now. It will express itself eventually — in a team that has not developed, in strategic opportunities that were missed because you were absorbed in the work, in a business that is as large as you can personally keep track of but no larger.
The business grows when the director gets out of the work. It sounds obvious. It took me longer than it should have to actually do it.
