When Everyone Can Execute

A COO at a mid-sized company spends her Friday afternoon building an internal workflow tool. She is not a developer. Six months ago, she would have written a requirements document and waited three weeks for engineering to prioritize it. Even more likely, it would never have been built at all. Now she describes what she needs, iterates with an AI assistant, tests it with her team, and ships a working version before the weekend. She has something engineering never had: the full operational context of why this tool matters and exactly how it needs to behave.

The distance between knowing what needs to be built and actually building it has become very short.

The cost of doing things yourself used to be prohibitive

Organizations have spent decades separating knowledge from execution. The people who understood the problem deeply (like domain experts, managers, operators) wrote specs and handed them to the people who could build things. This made sense when building was expensive and slow. Specialization was an economic necessity.

That cost structure is changing. AI tools have not made expertise unnecessary, but they have made execution so much more accessible. The person who understands a problem most deeply can now act on that understanding directly. Not always well, but often enough to matter.

This changes who moves fastest.

Three kinds of delegation

In practice, getting things done now involves three modes of delegation, often within the same day:

Delegating to people: still the most important and most difficult. It requires trust, clarity about goals, and the willingness to let others find their own path to a solution.

Delegating to AI: a different skill than it appears. The quality of the output depends almost entirely on the quality of the input: how well you frame the problem, how clearly you define constraints, how critically you review what comes back.

Doing it yourself: not because no one else can, but because sometimes you are the person with the most context, and the fastest path from idea to result runs through your own hands.

The advantage goes to people who move fluently between these three modes. Not specialists in one, not generalists who dabble in all, but people who judge, in the moment, which mode fits best.

Context has become the bottleneck

When execution was expensive, the bottleneck was capacity: how many people, how much time, how large the budget. Organizations optimized for throughput. Roles were defined by what you could produce.

When execution becomes cheaper, the bottleneck shifts. It moves to context: who understands the problem well enough to direct the work? Who knows why this matters, what has been tried before, what constraints are not written down anywhere?

Domain knowledge, organizational memory, and a clear sense of direction used to be inputs to a specification. Now they can be inputs to direct action. Whoever holds the fullest context can also build the first version, test the first approach, and iterate before anyone else is involved.

This does not mean working alone. It means the starting point of collaboration moves further along. You arrive with something concrete rather than something abstract.

Understanding the work your team does

There is a style of management that treats the work itself as a black box. The manager handles process and headcount and escalation paths. The team handles the actual work. In German this kind of manager has a name: “Abteilungsleiter”, roughly “department head”. And it works well enough when the manager’s job is resource allocation and the work itself is stable.

It works less well now.

A significant portion of what teams do today involves AI collaboration: choosing when to use it, how to prompt it, how to review its output, when to trust it and when to override it. These are judgment calls that happen dozens of times a day. A manager who cannot evaluate AI-assisted work, who cannot tell the difference between productive use and performative use, loses the ability to coach, to set standards, and to recognize where the team is actually struggling.

Not every manager needs to write code. But understanding the texture of the work - including the new texture that AI has added - is no longer optional. Managers who stay close enough to the work to understand it make better decisions about it. This was always true. The stakes are higher now because the work is changing faster.

Evidence from unexpected places

The most interesting examples of this shift are not coming from engineering teams. They are coming from the edges.

Executive assistants are building automations that previously required a developer. Operations leaders are prototyping tools for their own teams. Non-technical founders are iterating on product directly, testing ideas in hours instead of planning cycles.

These people are not learning to code in any traditional sense. What they are doing is more significant: they are connecting expertise they already had (deep operational knowledge, organizational context, a clear picture of what needs to happen) to the ability to make it happen. The barrier that used to stand between knowing and doing has become thin enough to step across.

Connected expertise

This is not a story about generalists winning and specialists losing. Depth still matters. Knowing a domain deeply, understanding its edge cases and failure modes, does not become less valuable when tools get better. If anything, it becomes more valuable, because the tools amplify whatever understanding you bring to them.

What changes is that depth alone, isolated from the ability to act on it, becomes less of an advantage. The shift is from isolated expertise to connected expertise. Connected to execution, to the people around you, and to the tools that let you move from insight to outcome without waiting for someone else to do the building.

The people I see moving fastest right now are not the ones with the most skills. They are the ones who refuse to treat the boundaries between understanding and execution as walls. They have always existed: the technical leader who also managed well, the operator who could prototype, the founder who stayed hands-on. What is different now is that the cost of operating this way has dropped dramatically. It used to require rare combinations of talent. Now it requires willingness and judgment.

What this means for roles

Role boundaries are softening; they are not disappearing, but becoming more permeable. The question “is this my job?” is becoming less useful than “do I have the context to move this forward?”

This is uncomfortable for organizations built around clear role definitions. It creates ambiguity about ownership, about standards, about who reviews what. Those are real problems, and they need answers.

But the discomfort should not be confused with the direction. The direction is clear: the people and organizations that figure out how to connect expertise to execution, be it across traditional role boundaries, across human and AI collaboration, or across knowing and doing, will move faster than those that keep them separate.

Not because speed is always the goal, but because when the cost of trying something drops, the cost of not trying it becomes visible.