Doing It Yourself vs Delegating: Faster, and Harder to See

Everything here waits for the same pair of hands, and they are yours.

Last issue closed by naming what this one would cover: why the person at the center of all this is the one least able to see it.

From the center, the thing making you the bottleneck feels like the thing making you good. Someone brings you a problem. You solve it quickly and well. They thank you and go back to work. Every signal that reaches you says the operation is working, and the cost lands somewhere you are not standing.

What it looked like from inside

For a good portion of my earlier career I optimized for velocity. How fast could I diagnose the problem. How quickly could I build the team. How soon could I show results. It worked. It also had a cost I kept paying without auditing it.

One instance of it. I was running profitability analyses and rationalizing a product portfolio. In practice that was profit maximization in a vacuum: my data, my model, my conclusions. On paper, some of the products were fringe.

Then we went through it with the stakeholders. A field rep pointed out that some of those fringe products were the differentiators. They were what had secured the customer's loyalty. None of that was in any file I had worked from. The sample room, where some of those SKUs were being made, put it most simply: customization wins loyalty.

That was the pattern, and not only in that analysis. I was deciding before I had heard the other opinions. I was developing fewer people than I could have, because that is slower than doing it yourself. I was reading my own conviction instead of the room. Speed required me to act like the smartest person in the room, and the smartest person in the room is the one who has stopped learning.

A mentor of mine once pointed out that most people only remember the first half of the adage. If you want to go fast, go alone. If you want to go further, go together. I had been running on the first half.

And I did not see it. I did not notice what it was taking until I noticed I had stopped learning. Every fast decision looked like competence from my chair, because in the moment it was. The people I did not develop did not send me a report. The opinions I did not wait for did not arrive late and complain. The field rep's point would never have reached my model on its own.

The second scene is more recent, and it is a different kind of evidence. I used to do horizon scanning by hand: research, record, aggregate. I would sit down on a Tuesday with eighteen browser tabs and a blank file, and by Thursday I would have the file, and by Friday I would be too depleted to interrogate what was in it.

So I built a ChatGPT task. One prompt, one output, industry signals in a table, categorized and sourced. Six minutes instead of six hours. Then I systematized it until the table produced itself every Monday morning.

What came back was not time. It was different time. The hours that used to go to assembling the file went to pressure-testing what was in it. I have described that before as pushing the assembly down and keeping the judgment up. For a long time, the thing below me was an analyst, an engineer, or a systematized process. Now some of it is AI.

That scene is a good one, and I still think the principle is right. But the same speed that freed those hours also makes my answer the fastest one available to anyone who brings me a question, and every time that is true, the fast answer beats the slow lesson by a wider margin than it used to.

I have not measured that in my own work. It is what the mechanism predicts. The career version of me could not see the cost of being fast. A faster version of me has more reasons to miss it.

Where you stand

You cannot design the process while you are inside it.

The people at the center of an operation are usually the most capable people in it. Where you stand decides what information reaches you, and the information that would show you the problem is exactly the kind that never travels to the center. What those fringe products were worth lived with a field rep and a sample room. It did not live in the file, so it did not live in my analysis.

Three minutes, every time

Every time something comes to you, there are two things you can do with it. You can answer it, or you can teach the person who brought it how to answer the next one.

Answering is faster today. Teaching is faster over a year. And you decide today.

Nobody at the center chooses dependency as a strategy. It gets chosen a few minutes at a time, and each individual choice is correct on its own terms. The problem is real, the customer is waiting, and you are the fastest path to a good answer. Taking the fast path once is good judgment. Taking it every time is how an operation ends up built around you.

What makes it invisible is the feedback. The answer you gave shows up right away: a problem closed, a person unblocked, a thank-you. The capability that was not built never shows up anywhere. Nothing you review records it. From your chair, every data point is positive.

Chapter 3 of my book, in the Servant Leadership framework, has a ratio for this. A leader takes three minutes to solve a problem that one of her engineers takes forty minutes to solve. The book reads that as forty minutes once to teach capability, against three minutes repeated forever to maintain dependency. The same section describes that leader's success as organizational failure disguised as high performance. The team shipped the work. The leader shipped much of it herself. The metrics measured output and not capacity.

That example predates AI, and the book does not apply it to AI. What follows is mine. The arithmetic treats the three minutes as fixed. They are not fixed anymore. When AI makes the person at the center quicker, it does not change the choice. It changes the price of one side of it. The fast answer gets cheaper and faster. Teaching stays nearly as slow as it was, because teaching runs on the other person's learning, and a tool does far less for that. If three becomes one, forty against three becomes forty against one. More decisions arrive at the desk whose answer is now the cheapest one available, and nobody decided that either.

From inside, it reads as leverage. You are getting through more. Your output is up. The instrument you would use to notice the problem is your own sense of how productive you are, and that instrument is reading higher than it ever has.

How it stays hidden

Measure your own output. It points the wrong way. Speed shows up in your output. What it costs shows up in other people's capability, which your dashboard does not track. The better your numbers look, the more reassured you are.

Give everyone the same tools. If AI made you faster, hand it to the team. They will get faster at their own work, and that is worth doing. But the exceptions came to you for a reason, and the reason was judgment and authority, not typing speed. A tool moves neither. The team gets quicker and the hard calls still arrive at your desk.

Ask the team. This feels like the honest check, and people will usually tell you it is fine. To them, your fast answer is the best service anyone offers. Asking the people who depend on the arrangement whether the arrangement works gets you their view of it, and their view is also from inside.

All three are checks run from somewhere inside the thing being checked.

One move this week

Pick the person who brings you the most questions. Ask them what they would do with the next one if you were unreachable for a week, and let them answer without helping. Listen for whether they describe a decision or describe waiting.

You are not asking whether the arrangement works. You are hearing what it does when you are taken out of it.

The view from the center

Three issues, one argument. Operations come to rest on one person without anyone choosing it. An operation's value is the part that still works when that person is gone. And the view from the center is the worst view of the problem, because every signal that reaches the center says it is working.

Next issue starts the second argument: why an operation that gets fixed at one level tends to break again at another, on a delay.

Oscar

Want to see which calls in your operation would wait if you were unreachable for a week? The Resilience Engine Systems Audit maps it: myresilienceengine.com/systems-audit