Delegation Is a Skill, Not a Reflex

For years I treated delegation as something that happened automatically once I had enough people. Hire competent engineers, point them at problems, and the work would distribute itself. That belief survived right up until the night I found myself rewriting a reconciliation job at two in the morning because, somewhere along the way, I had quietly become the only person who understood it. I had a team of twelve and a bus factor of one. The problem was not their capability. The problem was that I had never actually delegated anything; I had simply assigned tasks and reabsorbed the hard parts whenever they got uncomfortable.

Delegation, I have come to believe, is a discipline you practice deliberately, not an instinct that arrives with seniority. It is closer to a craft than a permission slip. In a regulated payments environment, where a missed control or an unowned process can turn into a compliance finding rather than just a bug, getting this wrong is expensive in ways that go well beyond a single late night. This is what I have learned about doing it on purpose.

The Reflex That Fails You

The default reflex for most technical leaders is to delegate the work we find boring and keep the work we find interesting or risky. It feels responsible. The risky parts are the ones where mistakes hurt, so surely the most experienced person should hold them. The trouble is that the interesting, risky work is exactly the work that builds judgment, and by hoarding it we guarantee that no one else ever develops the judgment to share the load. We become the bottleneck we complain about.

This reflex is reinforced by short-term math. In any given week, doing the hard task myself is faster than explaining it, watching someone struggle, and correcting the result. The cost of delegation is paid up front and visibly; the cost of not delegating is paid later and diffusely, in key-person risk and a team that cannot operate without me. Reflexive leaders optimize for the visible cost every single time, and the invisible one compounds.

I now treat the urge to keep the hard thing as a signal rather than a conclusion. When I feel it, I ask whether I am protecting an outcome or protecting my own sense of being needed. More often than I would like to admit, it is the latter.

Handing Over Ownership, Not Tasks

The most common mistake I see is confusing task assignment with delegation. Telling someone to implement a feature to a precise specification is assignment. It can be useful, but it does not transfer responsibility; it transfers labor. The person executes my decision and learns very little about why the decision was the right one. When the next ambiguous situation arrives, they come back to me, because I kept the part that mattered.

Real delegation hands over a problem and its boundaries, not a recipe. Instead of describing how to build the rate-limiting layer, I describe the outcome I need, the constraints that are non-negotiable, and the budget of time and risk available, and then I let the owner decide the approach. The difference shows up immediately in the questions they ask. Task-takers ask how. Owners ask why, push back on the constraints, and occasionally tell me the outcome I asked for is the wrong one.

If the person you delegated to never disagrees with you, you have not delegated anything. You have hired a very expensive remote control.

Calibrating Trust and Verification

Delegation lives in the gap between trust and verification, and the art is in calibrating that gap to the stakes. In a fintech context the stakes are not uniform. A change to the internal dashboard and a change to the ledger posting logic occupy completely different risk tiers, and pretending otherwise either smothers low-risk work in oversight or leaves high-risk work dangerously loose.

I think about verification as a dial, not a switch. For reversible, low-blast-radius decisions, I want almost no verification; the cost of a mistake is a quick fix and the lesson learned is worth more than the prevented error. For irreversible or regulator-facing decisions, I want strong verification built into the process rather than my personal review, because relying on me to catch things is itself a single point of failure. The goal is to make the verification proportionate and, wherever possible, structural.

• Reversible and contained: delegate fully, review after the fact if at all.
• Reversible but broad: delegate the decision, ask to be informed before rollout.
• Irreversible but low-stakes: delegate with a lightweight checkpoint.
• Irreversible and regulated: delegate the work, but require a documented control, a second reviewer, and a clear audit trail that does not depend on me.

Context Is the Real Payload

When delegation fails, the post-mortem almost always reveals missing context rather than missing skill. I told someone what to do but not what I knew. They did not know that this particular customer had a contractual SLA, that the legacy service times out under load in a non-obvious way, or that legal had already ruled out a tempting shortcut. They made a reasonable decision with the information they had, and it was the wrong decision because I held the information that would have changed it.

I have learned to treat context transfer as the bulk of the work, not the preamble to it. Before handing over a meaningful problem, I try to articulate the history, the failed past attempts, the political and regulatory constraints, and the things that look optional but are not. This is slow and it feels redundant when I can see the answer in my head. But the entire point of delegation is that the answer should not live only in my head.

Documentation helps, but living context is richer than any document. The most effective transfer I know is to narrate my own reasoning out loud while a problem is still open, so the owner sees not just my conclusions but the moves that produced them. That is how judgment actually propagates through a team.

The True Cost of Taking It Back

The most damaging thing I can do after delegating is to quietly take the work back the moment it gets hard. It feels like rescue, and in the moment it often is. But every time I reabsorb a delegated problem, I teach the team a precise lesson: when the stakes rise, the real owner reappears, so do not bother building the muscle to handle it yourself. A few repetitions of that lesson and delegation becomes theater that everyone has stopped believing in.

There is a version of this that is subtler and more corrosive, which is taking back only the decision while leaving the labor. The owner still does the work, but at the critical fork I step in and choose the direction. This is the worst of both worlds: they carry the effort and the blame, while I carry the authorship, and they learn that ownership was never real. If I am going to intervene, I try to make it explicit and rare, framed as a decision I am consciously pulling back rather than a habit I am indulging.

When something genuinely is going wrong, the better move is to widen support rather than seize control. Pair them with someone, surface the constraint they are missing, extend the timeline, or escalate the risk openly. All of these keep ownership intact while protecting the outcome.

Delegating Upward and Sideways

We usually talk about delegation as something that flows down an org chart, but the same discipline applies to peers and to the people above me. Delegating upward means handing my manager or the executive team the decisions that genuinely belong to them, rather than absorbing ambiguity that is not mine to resolve. Early in my career I would silently make tradeoffs between speed and compliance that should have been surfaced to the people accountable for the regulatory posture. I thought I was being decisive. I was actually hoarding decisions that were above my pay grade.

Sideways delegation is about resisting the urge to solve a neighboring team's problem because it is faster than negotiating with them. In a payments organization the boundaries between teams often map to boundaries of accountability, and quietly fixing something in another team's domain can break that mapping in ways an auditor will eventually notice. Respecting ownership across the org is the same skill as respecting it within my own team.

Both forms require me to tolerate a decision being made more slowly, or differently, than I would make it. That tolerance is the price of an organization where responsibility sits where it belongs.

Growing Owners on Purpose

If delegation is a skill, then the corresponding leadership skill is deliberately growing the people I can delegate to. This does not happen by accident, and it does not happen by handing someone a stretch project and hoping. It happens by sequencing responsibility so that each handover is slightly beyond what the person has done before but within reach of what they can learn quickly.

I think of it as expanding someone's radius of independent action over time. The first delegation might be a contained component with a clear spec. The next might be a problem with real ambiguity but low stakes. The one after that might be a high-ambiguity, moderate-stakes decision with a safety net. Each step, the verification dial loosens and the context I have to supply shrinks, because they have accumulated their own.

The signal I watch for is whether people start anticipating the constraints I used to have to spell out. When an engineer comes to me having already considered the SLA, the audit implications, and the failure mode I would have flagged, I know the radius has grown. At that point I can hand over not just tasks but whole domains, and I can finally stop being the load-bearing wall.

Delegation When the Pressure Is Real

It is easy to delegate well on a calm Tuesday. The test is what happens during an incident, an audit, or a deadline that has slipped. Pressure pushes every leader back toward the reflex, because under stress the up-front cost of delegation feels unaffordable and the instinct to grab the controls is overwhelming. I have watched careful delegators turn into micromanagers the instant a regulator asked a hard question.

What I try to do under pressure is the opposite of seizing control: I narrow the scope of what I personally own to the genuinely irreducible decisions and push everything else outward as fast and as clearly as I can. During a live incident, my job is rarely to fix the system; it is to hold the framing, protect the team from distraction, and make the two or three calls that truly require my authority. If I am in the code, I have usually failed at my actual role.

The teams that handle pressure best are the ones where delegation was already real before the pressure arrived. You cannot suddenly trust people in a crisis if you have spent the calm months quietly doing their hard parts for them. The crisis simply reveals which kind of leader you have been practicing as.

Conclusion

Delegation is not a reward you grant once people prove themselves, and it is not a reflex that switches on when your team gets big enough. It is a skill you practice deliberately, with all the awkwardness and visible cost that practicing any skill involves. It means handing over problems rather than tasks, transferring context rather than instructions, calibrating verification to real stakes, and resisting the urge to reabsorb the hard parts the moment they get uncomfortable. In a regulated environment the discipline matters even more, because unowned work does not just slow you down; it becomes risk that someone external will eventually find. The reconciliation job taught me that the bottleneck was never my team's capability. It was my own unexamined reflex. Treating delegation as a craft, and getting a little better at it each quarter, is the highest-leverage thing I have done as a CTO, because it is the thing that lets me stop being the thing everything depends on.