Why Continuous Improvement Stops Improving

Organisations have spent decades learning how to learn.

They built feedback cultures, retrospectives, lessons-learned processes, continuous-improvement systems, employee surveys, coaching practices and performance reviews. The language differs by industry, but the underlying idea is remarkably stable: work produces experience, experience produces insight and insight changes future behaviour.

Something happens. Someone notices. Someone adapts.

This sequence is so familiar that it rarely receives much attention. Feedback is treated as an input, almost like data travelling through the organisation. If enough information flows and people feel safe enough to speak, improvement should follow.

But feedback does not improve anything by itself.

For feedback to matter, there must be a sender, a receiver and an actor. Someone observes a difference between what happened and what should have happened. Someone understands what that difference means. Then someone changes behaviour, judgment, a decision rule, a process or a system.

Until now, organisations could usually assume that these functions would remain connected through human work. The person doing the work experienced the result, the team discussed it, a manager intervened, a specialist noticed a pattern, etc. Even when the formal learning process was weak, some adaptation happened simply because people remained in contact with the consequences of their actions.

AI changes that assumption.

Increasingly, the visible behaviour inside an organisation is no longer produced entirely by a person: a recommendation is generated by a model, a decision document is drafted by an assistant, a customer interaction is handled by an agent – or a workflow changes course because a system classified a case, predicted an outcome or selected the next action.

When that behaviour turns out to be wrong, incomplete or inappropriate, the familiar language of feedback starts to become strangely imprecise. Who, exactly, should receive it?

While Learning Loops asked Why are organisations creating less learning?
This article asks: What happens when organisations no longer know where learning is supposed to occur?

Feedback culture had a hidden dependency

A feedback culture assumes that the receiver can change through the act of receiving feedback.

That sounds obvious, but it distinguishes feedback from ordinary information transfer. Feedback has direction. It points from an observed outcome towards a different future behaviour.

When a manager tells an employee that a decision was escalated too late, the purpose is not merely to document the delay. The employee is expected to recognise the pattern, interpret the consequences and respond differently the next time. The person who acted is also, at least in principle, the person who adapts.

The same logic exists at team level. A retrospective connects delivery experience to future ways of working. A post-incident review connects failure to revised judgment. Customer feedback connects an encounter to a change in service. Neither the meeting nor the report creates improvement. Improvement occurs when the receiver incorporates what happened into future action.

Human beings do this socially.

We interpret feedback in relation to intention, context, identity, norms and expectations. We can notice that an action technically succeeded while still violating what others needed from us. We can understand that a decision created costs outside the metric by which it was evaluated. We can change because someone explains an impact we did not previously see.

That process is imperfect. Feedback can be misunderstood, rejected, softened, politicised or weaponised. It can arrive too late or reach someone without the authority to act. Yet the mechanism is recognisable: experience changes the actor through meaning.

An AI system does not participate in that mechanism.

You can provide additional information to a model. You can correct an output, adjust a prompt, change a threshold, add a rule, modify the workflow, replace the model or retrain the system. These interventions may produce better future results. But the system has not reflected on its behaviour. It has not reconsidered what it did. It has not understood the effect it had on somebody else. It does not return to work with a changed interpretation of its responsibility.

The system has been modified and modification requires a modifier.

Correction can survive while learning disappears

From the outside, an automated system may look as if it is learning continuously.

Performance is monitored. Outputs are rated. Users accept or reject recommendations. Exceptions are captured. The model may even improve over time. The loop appears intact: signal, correction, better output.

At the level of the technology, this may be entirely accurate.

At the level of the organisation, something else can be happening.

Suppose an AI-supported customer-service process repeatedly produces answers that are factually correct but unhelpful in context. Customers complain. Employees intervene. The responses are corrected and the prompt is refined. Output quality improves.

Who learned?

Perhaps the operations team learned that the prompt was underspecified. Perhaps the model owner learned which examples to add. Perhaps frontline employees learned which outputs require intervention. Perhaps the vendor’s system incorporated a new pattern.

Or perhaps none of these actors developed a fuller understanding of why the original responses failed. The symptom was removed, the output improved and the workflow continued. The local correction succeeded without strengthening organisational judgment.

The central risk.

Automated systems can become better at producing accepted outputs while the organisation becomes worse at understanding the work those outputs represent.

Continuous improvement then continues in appearance. Error rates fall, cycle times improve, fewer cases are escalated, etc. At the same time, the people around the process may gradually lose contact with the reasons one answer works and another does not. They learn how to operate the system, how to classify its failures and how to trigger a correction. They do not necessarily learn the underlying practice.

Improvement becomes located in the artefact rather than in the organisation.

The system performs better. The company knows less.

When the actor and the learner separate

Human work traditionally tied performance and learning together, however imperfectly.

A person prepared an analysis and, through preparing it, learned which information mattered. A manager wrote a decision proposal and, through writing it, clarified the trade-offs. A team handled an unusual customer case and, through handling it, developed a more precise understanding of the customer’s situation.

The effort was not incidental to learning. Working through the problem produced the experience from which judgment grew.

Automation can separate these functions.

• The system generates the analysis. The person reviews it.
• The system drafts the proposal. The leader approves it.
• The system handles ordinary cases. The employee receives only the exceptions.
• The system recommends an action. The decision-maker accepts or overrides it.

The human remains formally involved, but involvement has changed. Production becomes supervision. Practice becomes review. Repeated exposure to the full task is replaced by selective exposure to outputs and anomalies.

This changes the path through which feedback travels.

If a person creates a weak recommendation and receives feedback, the creator can adapt. If a system creates the recommendation, the reviewer receives feedback about behaviour they did not produce. They may be accountable for the outcome while lacking direct contact with the reasoning that generated it.

The reviewer can correct the output. The process owner can change the workflow. The model team can adjust the system. The vendor can improve the product. Each actor holds a fragment of the loop.

No one necessarily holds the whole act of adaptation.

Organisations already struggle with fragmented ownership. AI adds another fragmentation: the entity producing the behaviour cannot own its consequences, while the people owning the consequences may not control how the behaviour was produced.

Feedback still arrives but its address has become unclear.

The receiver is replaced before anyone notices

Automation programmes usually describe the tasks that will change.

Drafting will become faster. Classification will become automated. Recommendations will become more consistent. Routine interactions will require less human effort. Review will replace production in selected parts of the workflow.

What rarely appears in the design is a map of the learning that currently happens through those tasks.

• Which judgment is formed by drafting?
• Which weak signals become visible during classification?
• Which assumptions are tested while comparing options?
• Which customer realities become apparent through repeated interaction?
• Which professional instincts are developed through ordinary cases rather than exceptional ones?

These questions are difficult because the learning is often informal. It does not sit in the process map. It is not recorded as an output. It occurs inside the work.

A task can therefore look like an attractive automation candidate precisely because the capability it develops remains invisible.

Once the task disappears, the organisation may retain the deliverable and lose the developmental mechanism behind it. The report still exists. The recommendation still arrives. The customer still receives an answer. Nothing appears to have been removed except effort.

Only later does the system discover that effort carried information.

This does not mean all manual work should be preserved in the name of learning. Organisations contain waste, repetition and friction that deserve to be removed. But automation decisions made solely through the lens of throughput cannot distinguish useless effort from capability-producing effort.

Because both look slow and both consume time. Yet, only one leaves the organisation more capable after the work is finished.

The last mile feedback problem

The problem becomes more visible when automated behaviour crosses organisational boundaries.

Consider customer feedback: a customer reacts to the organisation, not to its internal architecture. They do not care whether a disappointing interaction was created by an employee, an AI agent, a policy, a workflow or a model supplied by a vendor. For the customer, the company acted.

Inside the company, however, the signal may travel through several layers before reaching anyone able to change the underlying behaviour:

• The frontline employee sees the complaint but does not own the model.
• The process owner owns the workflow but not the training data.
• The model team controls technical configuration but lacks the customer context.
• The vendor can modify the product but does not own the organisation’s promise.
• The executive sponsor owns the outcome but may see only aggregated performance.

Each party can truthfully say that the relevant cause sits elsewhere.

Eventually, the complaint may be converted into a category, a score or a ticket. Once translated, it can be counted and routed. But part of its meaning may disappear in the process. A social signal becomes a technical defect. A disappointed customer becomes a failed response. A breach of expectation becomes a prompt issue.

The correction may be technically valid and organisationally incomplete.

This is how AI can replace the receiver of organisational feedback without any formal decision to do so. The feedback remains visible. Dashboards may show more of it than ever. Yet the relationship between experience, interpretation and authority has been split across a chain of actors who each receive only the part they can process.

The organisation becomes excellent at handling signals and weak at being changed by them.

Feedback without consequence

There is another reason this matters: feedback creates obligation.

Once a problem has been surfaced, somebody is expected to respond. The cost of feedback lies partly in what happens next: priorities may need to change, resources may need to move, a decision may have to be reversed or a process may have to slow down.

This is why organisations frequently celebrate voice more readily than adaptation. Asking for feedback is culturally attractive. Acting on it creates trade-offs.

Automation makes it easier to absorb feedback without disturbing the organisation. A model can be adjusted. An exception route can be added. A guardrail can be strengthened. A user interface can be changed. These interventions may be useful, but they can also contain the signal locally.

The underlying operating model remains untouched.

If employees repeatedly override an AI recommendation because it ignores an important contextual factor, the immediate answer may be to improve the recommendation. A deeper reading might reveal that the organisation never decided how that factor should influence the outcome. The system is being asked to resolve a trade-off leadership left ambiguous.

Correcting the model can then become another form of buffering.

The technical layer absorbs contradiction so that authority does not have to choose.

Over time, the system accumulates exceptions, rules, thresholds, confidence levels and escalation paths. Each modification makes sense. Together they can encode years of unmade organisational decisions.

At that point the AI system has not learned the organisation’s judgment – it has inherited its avoidance.

Who exactly is meant to improve?

The question sounds simple until it is applied to a real workflow.

When an AI-generated output causes a poor outcome, who should become better because of it?

• The individual user may need to improve at verification.
• The team may need to improve its review criteria.
• The process owner may need to redesign the workflow.
• The model owner may need to improve system performance.
• Leadership may need to clarify the trade-off the system is expected to apply.
• Procurement may need to reconsider the vendor relationship.
• Risk or compliance may need to change the boundaries of acceptable automation.

Several of these responses may be necessary at once. Yet unless the operating model assigns responsibility for adaptation, the most immediate correction usually wins. It is visible, actionable and narrow enough to complete.

Change the prompt. Add another check. Train users again. Escalate unusual cases. Document the limitation. The workflow resumes and the organisation records progress.

What remains unanswered is whether the same underlying failure will return in a different form. The output may improve while the decision logic remains incoherent. Users may become better reviewers while losing the ability to produce the work independently. The system may handle more cases while employees become less able to explain why its answers are acceptable.

A functioning feedback loop therefore needs more than an owner of the output. It needs an owner of adaptation.

Someone must be responsible for deciding where learning lands.

Designing an organisation that can still be changed

Future operating models will need to treat adaptation as explicitly as they treat automation.

That begins by separating three questions which are easily collapsed into one:

• What should the system do differently?
• What should people understand or do differently?
• What should the organisation decide differently?

A technical correction answers only the first.

Sometimes that is enough. A clear defect requires a clear repair. But when behaviour touches judgment, customer expectations, risk, fairness, professional standards or unresolved trade-offs, improving the system alone may leave the organisation unchanged.

The second design requirement is to preserve access to the reasoning behind important work.

People cannot learn from decisions they experience only as outputs. If human judgment will remain accountable for an AI-assisted decision, the role must provide enough exposure to assumptions, alternatives and failure modes for that judgment to develop. Review cannot be reduced to approval. An approval button creates a record of acceptance, not evidence of understanding.

The third requirement is to keep feedback close to authority.

Signals should not end in reports whose recipients lack the power to alter the system. Nor should model teams be expected to resolve organisational tensions through technical configuration. When AI behaviour repeatedly exposes a conflict between priorities, policies or stakeholder needs, the signal has reached leadership territory.

The fourth requirement is to examine successful automation with the same seriousness as failure.

A system can produce better results while weakening capability, narrowing understanding or increasing dependence. Delivery metrics will not reveal this. Leaders must ask whether the organisation could still explain, challenge and recover the work if the system became unavailable or began failing in unfamiliar ways.

Finally, organisations need deliberate moments at which correction becomes learning.

Not every model output deserves reflection. That would create an impossible burden. But recurring overrides, consequential failures, surprising successes and changes in decision patterns should trigger a review at the level where future behaviour can actually change.

The purpose of such a review is not to discuss whether the AI performed well but to determine who must now adapt.

The unlearning company

An unlearning company does not stop collecting feedback. It may collect more than ever.

Every interaction produces data. Every override becomes a signal. Every output can be rated. Every deviation can be classified. The organisation appears attentive, responsive and continuously optimised. Yet its capacity to be changed by experience declines.

Humans encounter less of the work through which judgment was formed. Feedback is routed towards systems whose behaviour can be modified but which cannot understand the social meaning of the correction. Responsibility for adaptation fragments across users, process owners, model teams, vendors and leaders. Local defects are repaired while the underlying decision logic remains untouched.

The company improves its outputs and loses its ability to explain how improvement happens.

That is unlearning.

It is not forgetting in the ordinary sense. The organisation may retain more information, more documentation and more recorded decisions than before. What disappears is the living connection between action, consequence and changed judgment.

Eventually, expertise becomes concentrated in systems nobody inside the organisation fully owns. Employees know when to approve, reject or escalate. Managers know which indicators to monitor. Governance knows where responsibility is formally assigned. But fewer people understand the work deeply enough to reconstruct it, challenge it or redesign it when the familiar failure modes no longer apply.

The organisation remains efficient as long as reality stays within the boundaries its systems recognise.

Outside those boundaries, it discovers what it failed to preserve.

Bottom line

Feedback culture was built for a world in which the actor receiving feedback could change through receiving it. AI breaks that link.

A machine-generated behaviour can be corrected, but correction does not automatically create organisational learning. Someone still has to interpret what happened, decide what it means and change the future system of action. When this ownership is missing, feedback travels through the organisation without finding a responsible receiver.

The danger is not that organisations will stop improving their AI systems. They probably will improve them, repeatedly and at speed. The danger is that they will mistake better system performance for stronger organisational adaptation.

Every time a human learning loop is replaced by an AI execution loop, leadership inherits a design decision: Where should the learning that used to happen through the work now take place?

If the answer remains implicit, it will usually be displaced. Into a model team without business authority. Into reviewers without sufficient practice. Into frontline employees handling exceptions. Into vendors outside the organisation. Or into no one at all.

Continuous improvement does not fail because the feedback disappears. It fails because the receiver does.

The future learning organisation will therefore be defined by more than its ability to gather signals or optimise systems. It will be defined by whether someone remains capable, authorised and obliged to be changed by what the organisation experiences.

Otherwise, the company may become faster, more consistent and more responsive with every iteration… and less able to learn.

And you might ask now: If output improves, KPIs improve, customers are happier and the business performs better… does the loss of learning actually matter?

The answer is yours, as is its consequences.

More end-to-end accountability. More “act like an owner.” More “single throat to choke.” More “you build it, you run it.”

And then we’re surprised when people do the opposite: they hedge, defer, escalate late, speak in plural pronouns, and design exit ramps into every commitment.

Here’s the question underneath all of it:

If failure has consequences, won’t people avoid ownership?

Most leadership advice answers this like a character problem. We say people need courage or grit or “bias to action” or resilience or better mindsets… you get the drift.

But avoidance often isn’t a mindset problem. It is designed into the very core of most companies.

If you want (real) ownership, you need to design failure correctly.

Reframe failure from an event to a signal

Failure is usually treated like a moment: a missed target, a slipped date, a broken metric, a disappointing launch. But organizations learn from signals – patterns that trigger interpretation and change. Single moments don’t matter in the long run.

That’s why failure itself isn’t the core issue: the system can tolerate failure. The system cannot tolerate failure that produces no signal or failure that produces the wrong signal.

There are three common failure regimes.

Regime one: failure without consequence.

Nothing meaningfully changes after a miss: Scope expands to redefine success; the deadline moves; the KPI is “re-baselined.” The narrative is rewritten so the outcome was never the outcome.

This kind of failure produces noise. People become conditioned to treat misses as weather: unfortunate, but not actionable.

If nothing changes, nothing is learned.

It’s not about pain or punishment, but because the system didn’t generate a binding decision.

Zero learning (micro-case)

A product team misses its launch KPI by 40%.
Instead of changing direction, leadership reframes the metric (“early traction indicator”), extends the timeline, and keeps funding unchanged.
Six weeks later, the narrative is that the product is “still in validation.”
No decision was made, so nothing was learned.

Regime two: failure with disproportionate consequence.

A miss triggers shame, scapegoating, political damage, or career risk that exceeds the magnitude of the miss. People learn fast – but what they learn is concealment. They learn to protect themselves, not the outcome.

This regime creates fear, which forces the system into blindness. Errors are reported late. Risks are reframed as certainties. Issues become “complexities” until they become emergencies.

Avoidance (micro-case)

A team flags early that a project is likely to slip by two weeks.
The message escalates, and by the next steering meeting the delay becomes a reputational issue: the team is labelled as “unreliable,” leadership questions competence and future scope is reassigned.
The next time risk appears, the team waits longer before saying anything.

Regime three: failure with designed, predictable consequence.

Here, consequence pre-committed feedback. A miss triggers a specific, proportionate adjustment that everyone understands in advance: scope changes, resources shift, options narrow, or priorities are explicitly re-ranked.

This is where learning lives. Not because of the “pain”, but because failure produces a clean signal: the organization will now do something different.

That’s the reframe: the point of consequence is information.

Pre-committed consequence (micro-case)

A growth experiment is pre-defined with a clear threshold: if conversion does not improve by 15% within four weeks, the initiative loses priority and the team shifts to the next opportunity.
When the threshold is missed, the decision is executed as agreed (i.e., the team drops the initiative despite prior investment). No debate about interpretation, no narrative rewriting.
The loss is visible, but the signal is clean.

Expose avoidance as a rational response

Once you see failure as system design, ownership avoidance becomes easier to interpret. People avoid ownership because it’s often the rational response to incoherent systems. Consider what ownership actually asks of someone: commit to an outcome under uncertainty, expose your judgment publicly, and accept blame when reality disagrees. Why wouldn’t someone avoid that?

Three forces make avoidance logical.

First: identity is tied to success narratives.

Modern careers are built on consistent stories: “I deliver,” “I lead,” “I scale,” “I fix.” Ownership threatens those stories, because outcomes are never fully controlled. If identity depends on winning, then taking on uncertainty is gambling with the self.

Second: organizations punish failure socially even when they excuse it formally.

Many companies say “you’re allowed to fail,” but what they really mean is: you’re allowed to fail in ways that don’t matter, don’t embarrass anyone senior, and don’t change resource allocations.

The formal rule says “safe.” The informal rule says “don’t look stupid.” People follow the informal rule, because that’s where promotions, reputation and belonging live.

Third: ambiguity creates dignity-preserving exits.

Ambiguity is not just confusion: it’s protection.

If ownership is vague, people can leave without losing face. They can say: “It was shared,” “We aligned,” “Dependencies,” “The market shifted,” “The strategy changed.”
Those phrases aren’t excuses. They’re how people preserve standing in systems where consequences are unpredictable and socially loaded. In such systems avoidance is not cowardice but coherence – a self-preserving necessity .

If the organization doesn’t reliably distinguish between:

• a smart bet that failed,
• a reckless bet that failed,
• and a non-bet dressed up as progress…

…then people will optimize for the one outcome they can control: their exposure.

We don’t need “more consequences.” We need tolerance for visible loss.

At this point, the argument can be misunderstood as a call for harsher accountability. It’s the opposite.

If you want ownership, you don’t need more consequences. You need something much harder:

You need leaders willing to live with visible loss.

Because real consequences are not abstract. They show up as losses someone can see – loss of:

• options (you can’t keep every path open)
• status (someone’s credibility shifts)
• resources (budget, headcount, attention moves)
• narrative control (the story becomes “we were wrong,” not “we were early”)

This is where most ownership cultures fail. Not because leaders don’t talk about accountability – they do (a lot). They fail because leaders refuse the losses that make accountability real.

They want the benefits of ownership without paying for the bindingness of it. They want:

• people to commit, but not to narrow options;
• people to be accountable, but not to lose status;
• teams to be responsible, but not to lose resources;
• learning, but not to admit that the prior story was wrong.

So here’s a practical mirror: Which losses are you actually willing to tolerate – and which ones are you pretending don’t exist?

If the honest answer is “none,” then ownership will remain symbolic, accountability will remain fictional and incentives will remain dishonest.

Leaders own consequences (micro-case)

A strategic initiative fails to deliver expected results.
Instead of pushing accountability down, the executive sponsor states: “We chose this direction; we were wrong.”
Budget is reallocated, the priority is dropped, and the decision is documented. The team moves on without reputational damage.
The loss is carried at the level where the choice was made.

A quick note on “better culture”

“Better” is relative and domain-specific. There is no one-size-fits-all, and not every concept needs to be applied in every organisation.

More importantly: culture can’t be demanded. It is designed through incentives, consequences and boundaries. And then reinforced in practice.

In most organisations, the issue is not the behaviour of the broader workforce, but the incentive design at the top.

Conclusion: So… once consequences are stated, how do we prevent avoidance?

Better culture… That’s the easy answer. It’s also the wrong one.

You can’t prevent avoidance with slogans. You prevent it with design. Ownership becomes possible when three conditions are true:

1) Consequences are pre-committed and proportionate.

People don’t fear consequences but they distaste arbitrary consequences. Predictability reduces panic.
Proportion reduces concealment.

2) The organization separates learning from scapegoating.

If every miss becomes a morality play, people will optimize for innocence over truth. If misses become structured signals, people can stay in the game long enough to improve the system.

3) Leaders absorb some of the loss themselves.

Ownership can’t be demanded from below while leaders protect themselves from the same exposure. When leaders model “we chose, we missed, we changed,” they turn consequence from threat into operating system.

That’s the paradox resolved: Yes – if failure has consequences, some people will avoid ownership.

Unless the organization makes ownership safer than avoidance by designing consequences that create learning, not fear – and by being honest about the visible losses that real accountability requires.

Because the opposite of ownership is self-preservation in a system that can’t decide what failure means.

Why speed erodes human backup systems

AI is making work faster: Analysis, code, reports, decision documents – all can be drafted, formulated and polished now in minutes instead of hours or days. It feels effortlessly.

For managers, this looks attractive, as more output can be delivered with less manual input.

But what effect does this have on the expertise in the organization when effort turns into prompting and passive oversight?

Skills decay when work disappears

Surely, we will not replace humans any time soon – yet. Though, already the “Human in the loop” approach puts human into passive “consume” mode: Reviewing, checking, approving.

Yes, this preserves a form of control, but it does not retain the same capability within the organization.

Reviewing an output does not train the same judgment as creating it in the same way approving a recommendation does not build the same understanding as working through, and condensing all the available options does. Checking a deliverable does not replace designing it. How can the skills needed to oversee the AIs output be retained, let alone be developed without exercising the “creation muscle” in exactly these movements.

Automation removes learning loops

Automation removes friction, and this is useful. Many organizations have too much friction, reduction SHOULD be the goal here.

But friction is also where learning happens, for example:

• Designing a process exposes dependencies.
• Preparing a steering decision clarifies trade-offs.
• Defining a Key Result forces outcome thinking.

Just to name a view.

When these activities are delegated, the learning loop comes to a halt (or at least is externalized!). Read further in this deepdive article: AI Learning Loops: When Speed Kills Improvement

This creates a fragile system. It is highly accelerated when everything runs smoothly but stalls to a halt, or even worse, spirals into error territory, as soon as an exception occurs.

The organization can produce more, report more and process more. But when the system is wrong, fewer people can intervene meaningfully.

Everyone coordinates and reviews.

But nobody observes, contributes and THINKS from the grassroots up.

AI operating models drift into exactly this pattern: humans are drastically reduced and only remain involved as monitors and approvers. Governance still exists. Meetings still happen. Progress is still reported. But the ability to challenge, redesign and manually intervene gets thinner.

What aviation gets right

Aviation has worked with high automation for decades.

Modern aircraft can automate large parts of navigation, flight management and landing. Yet pilots were not turned into passive observers.

The system was designed to preserve human capability to avoid exception cases turning into catastrophes. That is the relevant management lesson for AI-enabled transformation execution.

Four design principles

1. Keep critical decisions explicitly human-owned

In aviation, the pilot in command remains responsible, even when autopilot is engaged.

AI operating models need the same clarity.

Define:

• who owns the decision
• who can override the system
• which decisions must stay human-owned
• when escalation is required
• what evidence is needed before accepting an AI-supported recommendation

“Human in the loop” is often too vague – aim for “human in the lead” (i.e. clarify unambiguously accountabilities)..

2. Design roles around judgment and expertise

Pilots are not designed into the system as passive reviewers of autopilot output. Their role is to preserve operational judgment, which means: noticing when the aircraft is doing something unexpected, comparing instrument indications with the real flight situation, and take manual control when needed.

In the same way: Weak AI roles are built around checking outputs.

That means people must still be able to:

• challenge assumptions
• detect context drift
• understand failure modes
• compare outputs with business reality
• decide when to escalate
• revert to manual execution when needed

Think: A product owner who only reviews AI-generated user stories may become faster at backlog handling, but weaker at product judgment.

3. Embed learning into the operating cadence

Airlines use operational data and reporting systems to constantly learn from operations to improve safety. This even is mandatory by FAA.

In the same way AI capability cannot live only in training sessions. Every AI-enabled workflow should constantly generate learning signals:

• which outputs failed
• where humans overrode the system
• where confidence was misplaced
• where handoffs broke
• where context was missing
• which capabilities need reinforcement

These signals belong into retrospectives, risk reviews and transformation governance.

All to answer a simple question: what did execution teach us about the capability of the system?

4. Delivery metrics only show half of the picture: Track capability signals instead

A flight can land safely and still contain warning signs: too fast, too high, unstable descent rate, late configuration, weak energy management or a missed opportunity to go around. If you only measure “arrived safely” or “arrived on time,” you miss important indicators for the continuous operation of the system you designed.

Yet, most transformation governance still focuses on delivery:

Timeline, budget, milestones, scope, output quality, risks, next steps.

But more importantly: “No need for a Retro if the output was delivered as expected”.

These remain relevant. But they are not enough when AI takes over large parts of execution.

Because a team can deliver faster while losing domain judgment. The same way a function can reduce effort while increasing dependency.

Add capability signals:

• quality of human overrides
• clarity of decision ownership
• recurring AI failure patterns
• escalation frequency
• manual fallback capability
• ability to explain AI-supported recommendations
• dependency on specific tools or individuals
• capability gaps observed during execution

Three questions before automating further

Before automating a workflow, ask:

1. What capability does this workflow currently train?

Because some manual work looks inefficient but builds understanding.

2. What happens when the system is wrong?

The critical test is detection of edge cases and how smooth the handover to human actors works.

3. Who owns the judgment?

Ownership means accountability. Without it, people will default to output review. That is too weak.

Final thought

AI can make organizations faster.

But that comes with strings attached.

If automation removes friction without preserving judgment, organizations become more efficient and more dependent at the same time.

The operating model needs to protect where humans must stay sharp: in roles, decision rights, governance, learning loops and leading indicators.

Everyone knows that resources are finite, priorities collide, objectives compete and not everything can be optimised at once. And yet, in practice, most organisations behave as if this constraint could be softened, delayed, or somehow designed away. They can’t.

Trade-offs are a structural property of coordinated work under constraint and not just mere side effects of imperfect planning. Which leads to a much less comfortable position:

The question is never whether trade-offs exist.
The question is always where they land.

The Illusion of Avoidance

Explicitly addressing trade-offs requires accepting discomfort:

• naming what will not be achieved
• identifying who will carry the downside
• accepting that some outcomes will be worse in order to improve others

That’s where leadership becomes visible and where resistance, conflict and negotiation surface. So organisations develop alternatives because the immediate pressure to move forward without friction is strong:

• They push decisions slightly forward.
• They soften language.
• They ask for “alignment”.
• They wait for more data.

But this does not remove trade-offs, it defers them. And once deferred, they do not remain abstract. They begin to relocate – they move the moment when they become unavoidable.

Example: Growth vs. Load

A company commits to aggressive growth targets, while at the same time:

• no additional hiring is approved
• existing delivery timelines remain fixed
• quality expectations stay unchanged

No explicit decision is made about the obvious trade-off “growth vs. load vs. quality.”
Instead, the message becomes: “We trust our teams to find a way.”

While that sounds empowering, what actually happened is that the trade-off was not resolved and it was relocated downward.

Trade-offs Do Not Disappear. They Move.

When a trade-off is not resolved explicitly, the system still has to function: work continues, decisions are still made and outcomes are still produced.

Which means the trade-off is resolved anyway… just not where it should have been.

Over time, a predictable pattern emerges:

• what is not decided formally is resolved informally
• what is not negotiated openly is absorbed implicitly
• what is not owned collectively is carried individually

Don’t blame this on culture (yet): it is a structural dynamic before it becomes a cultural issue – and to understand it properly, it helps to distinguish where trade-offs can reside.

Three Layers of Trade-off Distribution

Trade-offs in organisations do not “exist”, they “reside” somewhere: they move across three layers.

1. Decisions – explicit allocation of consequence

At the top layer, trade-offs are handled where they belong – the place they are designed to be handled: decisions.
This is where organisations are at their most coherent and trade-offs in this layer are:

• articulated clearly
• debated explicitly
• owned unambiguously (i.e., understood in terms of consequences)

Someone says:

• we will prioritise speed over precision
• we will reduce scope instead of increasing capacity
• we accept short-term loss for long-term positioning

In short: someone takes responsibility for the choice, so that the downside is acknowledged before it materialises.

This makes the system slower in the moment, but more stable over time. This early, cheap friction is what removes costly ambiguity later. Because once a trade-off is decided, coordination becomes easier, ambiguity is reduced and downstream compensation is minimised.

Effective leadership fixes the location of the trade-off early, instead of letting it distribute itself later.

Case: Product vs. Compliance

A financial services firm faces a clear conflict:

• product wants faster releases
• compliance requires extended review cycles

In one organisation, leadership makes the trade-off explicit:

• certain release types are slowed intentionally
• others are exempt with defined risk thresholds

Result:

• slower in some areas
• but clear and stable overall

In another organisation:

• no decision is made
• both priorities remain “critical”

Result:

• teams negotiate every release
• escalation becomes constant
• lead times increase instead of shrinking

Same trade-off. Different location. Different cost.

2. Culture – implicit resolution through norms

When decisions don’t resolve the trade-off, culture does. Because the system cannot pause, it has to adapt.

This is where culture enters as a mechanism (not as a value statement). Culture, in this context, is not what organisations say they believe. It is what the system consistently reinforces under ambiguity.
It answers unspoken questions like “What gets prioritised when everything is urgent?” or “What gets compromised when nothing can be dropped?.”

In the absence of explicit decisions, culture begins to define acceptable behaviour, interpret conflicting signals and resolve contradictions informally. It does this through:

• peer expectations
• informal escalation patterns
• social reward and punishment mechanisms

The critical shift here is subtle but important: The trade-off is no longer decided – it is lived.

Instead of: “We prioritise speed over precision in this context.”
It becomes: “Around here, you’re expected to be fast – even if things break.”

No one formally made that decision. The system did through repetition.

Example: “Ownership culture”

An organisation promotes “ownership”, while in practice:

• priorities conflict
• decision rights are unclear
• escalation paths are slow

What happens? “Ownership” starts meaning:

• resolve contradictions locally
• don’t bother leadership with trade-offs
• make it work, regardless of constraints

Over time, a rule emerges: Good people absorb problems instead of escalating them.
Is that culture as a value, or rather culture as a trade-off resolution mechanism?

Case: Customer-centricity vs. Efficiency

A company claims:

• “customer-first mindset”
• strict cost targets

When conflicts arise:

• frontline teams make exceptions
• middle managers push back
• finance enforces budgets

No explicit rule exists. But culturally, teams learn:

• exceptions are tolerated short-term
• but punished later through targets

Result:

• people hesitate
• decisions become inconsistent
• customer experience depends on individual risk appetite

The trade-off is active… and invisible.

3. Operating Model – structural embedding of contradiction

If culture stabilises these implicit resolutions long enough, they do not remain behavioural but become structural; embedded in the system itself.

At this stage the trade-off is no longer negotiated at all: no one questions the contradiction, it is simply “how things work” – how work is organised. You see it in:

• role design
• KPI structures
• governance models
• escalation paths

This is where contradictions become normalised:

• roles expected to deliver incompatible outcomes
• teams measured against competing incentives
• accountability assigned without corresponding authority

But at this point, the original decision context is gone and only the consequences remain.

And the system continues to function. Instead of solving the trade-off, it is constantly being compensated for. Constantly ramping up the bill.

Example: (“Emerged”) Hybrid roles

A role includes:

• execution
• coordination
• decision-making
• escalation management
• reporting

Each responsibility reflects a different trade-off:

• speed vs. control
• autonomy vs. alignment
• delivery vs. reflection

None of these were resolved explicitly, so the role absorbs all of them. And from the outside it looks like a “broad & complex role” but from the inside it’s continuous context switching and unfinished work.

Case: Shared accountability

A transformation introduces:

• cross-functional ownership
• shared accountability

But does not change:

• incentives
• decision rights
• escalation clarity

Result:

• everybody is involved
• nobody decides
• outcomes drift

The trade-off between “collaboration vs. accountability” was never decided.
So the system resolves it structurally: Shared ownership → Diluted accountability.

From Decisions to People

The movement across these layers has a direction:

When trade-offs are not resolved at the decision layer
they move into culture,
from there into the operating model,
and from there into people.

That last step is where the cost becomes most visible – if you know where to look – not as a single event, but as a pattern:

• increasing coordination overhead
• recurring misalignment
• constant exception handling
• overwork in specific roles
• dependence on “strong individuals” to keep things together

From the outside, this often looks like:

• resilience
• flexibility
• commitment

From the inside, it is continuous compensation for unresolved contradiction.

In short: If you follow the path across layers, you see clearly:

• decisions → visible trade-offs
• culture → implicit trade-offs
• structure → embedded trade-offs
• people → absorbed trade-offs

Concrete pattern

Take the earlier growth example, where no leadership decision is made:

1. Culture kicks in → “good teams deliver regardless”

2. Structure adapts → overloaded roles, unrealistic sprint commitments

3. People compensate → longer hours, shortcut decisions, quality erosion

Nothing “broke”.
The system adapted.
The trade-off is fully paid, but not by the people who avoided the decision.

Why Culture Gets Overestimated

Culture is attractive because it feels like a solution (without confrontation). No need to name losers, no need to force alignment and no need to expose trade-offs.

The assumption is simple: If culture is strong enough people will “do the right thing” even under ambiguity. There is some truth in that. A well-aligned culture can accelerate execution, reduce the need for coordination and enable decentralised decisions.

But this only holds under one condition: The underlying trade-offs have already been decided.
Without that, culture does something else, because it has as hard limit:

Culture cannot decide. It can only distribute.

And the trade-off is distributed, often invisible and almost always unevenly.

Where culture works

Culture is powerful when:

• trade-offs are already explicit
• decision logic is clear
• priorities are stable

Then it:

• accelerates decision-making
• reduces coordination cost
• reinforces consistency

Where culture fails

Culture fails when it is asked to replace decisions. Then it:

• hides trade-offs
• redistributes cost unevenly
• protects ambiguity

The Cost of Substitution

When culture substitutes for decisions, three things happen simultaneously:

1. Trade-offs become harder to see (Invisible)

Because they are no longer discussed explicitly → nobody can challenge them.

2. Trade-offs become harder to challenge (Personalised)

Because they appear as “how things work here” → individuals carry system problems.

3. Trade-offs become harder to rebalance (Fixed)

Because they are embedded across roles and structures → harder to change later.

This creates a system that is locally stable, but globally inefficient and it runs at a cost that is difficult to locate.

Case: “Execution failed”

A common pattern:

• strategy remains high-level
• conflicting objectives remain unresolved
• ownership is symbolic

Execution begins and teams must:

• interpret priorities
• resolve conflicts
• manage dependencies

When outcomes fail, the label “Execution failed” appears. But execution did not fail, it did exactly what the system was (unconsciously) designed to do: It resolved trade-offs locally, inconsistently, and under constraint.

Reconnecting to Leadership

Most leadership narratives focus on alignment, culture, or execution.
But the core responsibility is not simply “defining culture”, “improving alignment messaging” or “increasing engagement.”

Underneath all of these sits a more fundamental responsibility:

Leadership decides where trade-offs should live.

Not eliminating, not softening nor delegating them. Deciding them.
Because if that decision is not taken explicitly, the organisation still decides – just differently.

• Upfront, visible, owned.
• Or downstream, invisible, distributed.

Only one path is leadership.

Final Reflection

Organisations do not avoid trade-offs, they relocate them across:

• decisions
• culture
• structure
• people

Instead of asking yourself “Do we have a strong culture?”, ask “Where are our trade-offs currently being resolved – and who is carrying them?”

Because if the answer is unclear to you, you better belief that the system has found one. Someone is already paying – and once that cost has been distributed widely enough, it no longer feels like a decision.

It feels like reality.

When AI Accelerates Learning – and When It Kills It

Organisations talk constantly about learning: Continuous improvement. Feedback culture. Retrospectives. Lessons learned.

The language is familiar, polished and reassuring. It suggests that as long as information flows, organisations will get better over time.
That assumption breaks once AI becomes embedded in daily work.

AI changes where learning should happen, who should adapt and what actually compounds.

Some organisations will learn faster with AI in the system. Many will not – and the difference has very little to do with data quality, tooling, or intent.
It has everything to do with whether learning loops are designed or is merely assumed to survive acceleration.

The Design Constraint We Keep Ignoring

Learning does not happen automatically at speed.

In human systems, learning requires three things to line up:

1. A signal that something deviated from expectation
2. A responsible agent whose behaviour is expected to change
3. Time and space for reflection before the next iteration

None of these are guaranteed just because more information is available.

AI systems are excellent at producing signals. They are very good at identifying patterns, anomalies, correlations and opportunities for optimisation. What they do not do is:

• experience surprise,
• feel dissonance,
• internalise responsibility,
• or adapt behaviour socially.

In other words: AI produces information but not automatically learning.
Learning still has to happen in the human and organisational layer. That layer has limits.

Human attention is finite. Reflection competes with delivery. Responsibility diffuses easily under pressure. When speed increases, learning does not automatically keep up. It often degrades.

When speed stops producing improvement

Many organisations notice a strange pattern after introducing AI into execution:

• Output increases
• Cycle times shorten
• Decisions feel faster
• Activity intensifies

And yet, over time:

• The same mistakes recur
• The same edge cases reappear
• Workarounds harden instead of disappearing
• Confidence in decisions erodes rather than improves

Nothing is obviously “broken”, but the organisation stops getting better. The learning-loop stopped working.

AI shortens the distance between action and outcome – yet learning requires a pause between outcome and next action. When that pause disappears, systems run faster while learning less. The organisation becomes more productive, but less adaptive.

Mistakes don’t hurt long enough to teach and successes don’t linger long enough to understand.

Being productive does not (automatically) mean one learns; two things can be true at the same time:

• the organisation gets more productive AND
• the organisation stops learning.

Why more insight can mean less learning

AI produces insight at a scale and speed humans cannot match. Dashboards update in real time. Models evaluate thousands of variants. Recommendations arrive continuously. This creates a subtle but powerful shift:

• Insight becomes abundant
• Interpretation becomes rushed
• Reflection becomes optional
• Closure disappears

Teams move on before meaning stabilises.

In many environments, yesterday’s learning is irrelevant by tomorrow morning. Yet the environment didn’t truly change, the system just did not slow down long enough to integrate what happened.

Learning becomes noise.

This is why organisations can “learn” the same lesson repeatedly without changing behaviour. The loop never closes. Information is generated. Reports are written. Actions follow. But ownership of adaptation remains unclear and the next iteration restarts before anything has settled.

The failure mode: learning outsourced to systems

When AI is embedded deeply into workflows, a tempting shift occurs:

• Deviations are flagged by systems
• Corrections are implemented by systems
• Optimisation happens centrally or automatically

Human actors are left to supervise outcomes rather than adapt behaviour.

At first, this looks efficient. Over time, it is corrosive because humans only learn through the exercise of judgment. And when judgment is removed from daily work, expertise decays – even if outcomes look fine most of the time.

The organisation becomes faster and more dependent at the same time.

When systems fail, humans are expected to intervene – but their ability to do so meaningfully has eroded because learning loops were never feeding back into practice.

(That is not a de-skilling argument yet, it is a learning-loop argument. De-skilling will be elaborated in detail in an upcoming article.)

Learning loops are structural (not cultural)

Organisations often treat learning as a cultural achievement:

• Encourage feedback
• Reward curiosity
• Promote psychological safety

While this matters, it’s far from sufficient. Learning at organisational scale is a structural property, not a mindset.

Well-designed systems make learning unavoidable:

• Review cycles are built into execution, not added afterwards
• Responsibility for reflection is explicit, not collective
• Successes are examined under the same discipline as failures
• Signals from delivery feed back into decision rules, not just reports

Poorly designed systems do the opposite:

• Reflection competes with delivery and usually loses
• Responsibility for adaptation diffuses across roles
• Learning is delegated to retrospectives with no authority
• Insights accumulate while behaviour stays the same

In those systems, asking people to “learn more” is ineffective and (often) cruel.

The system-level consequence

Organisations run harder but learn less.
When learning loops fail under acceleration, predictable patterns appear:

• Rework increases (undetected)
• Documentation multiplies defensively
• Escalations rise without clarity
• Confidence in judgment decreases
• Responsiveness replaces effectiveness as a performance signal

From the outside, the organisation looks busy, data-driven and proactive. From the inside, people sense that nothing really improves – it gets just faster.

This is how organisations drift into a brittle state: high output, low insight, fragile adaptation.
The damage does not appear immediately. That is what makes it dangerous.

When AI Does Accelerate Learning

AI does not inherently suppress learning. Under the right conditions, it can accelerate it materially. What changes with AI is not whether learning is possible, but where learning must occur and what it requires.

AI tends to support and accelerate learning when several conditions are deliberately designed into the system.

AI scaffolds practice, not just outcomes

Learning improves when AI supports humans in doing the work better – for example through tutoring-like feedback, exposure to high-quality exemplars, or guided iteration – rather than simply delivering correct answers or optimal decisions.

Responsibility for adaptation is explicit

Learning compounds when a specific role or decision owner is accountable for changing future behaviour, rules, or decision logic based on what occurred. Learning stalls when insight remains informational rather than owned.

Time pressure is experienced as challenge, not compression

Speed can intensify learning when individuals have sufficient resources, autonomy and slack to interpret feedback as a challenge. Under cognitive overload or chronic compression, the same speed erodes learning.

The system forces verification and reflection at defined moments

When workflows intentionally pause at critical decision points – before irreversible commitments – learning has space to resolve. When uninterrupted flow is treated as the primary optimisation target, learning rarely closes into behaviour.

In these conditions, AI can shorten learning curves, diffuse best practices and raise baseline competence – particularly for less experienced actors.

How high-functioning systems absorb acceleration without losing learning

Organisations that continue to improve under AI acceleration do not rely on better tools or smarter people. They make a few disciplined design choices.

1. Learning is anchored to ownership

Someone is explicitly responsible for changing future behaviour based on what happened. Not a team. Not a report.

2. Review happens at the right altitude

Not everything is reviewed deeply – but critical decisions are revisited where judgment actually occurred, not where reporting sits.

3. Feedback loops are closed before speed resumes

The system slows down on purpose at defined moments so learning can resolve before the next cycle.

4. Learning is treated as a system cost

Time spent integrating insight is considered part of execution, not overhead to be minimised.

These organisations accept a difficult truth: Speed that does not compound learning is just motion wrongly interpreted as performance.

Bottom line

Whether AI accelerates learning or suppresses it is not a cultural question and not a tooling question. It is a system-level design choice. Organisations that continue to improve under AI do not rely on intent or intelligence.

They redesign accountability, pacing and feedback so learning has somewhere to land.

Those that do not often remain busy, data-rich and confident – until judgment fails faster than it can be rebuilt. By removing friction, AI removes the pauses where learning used to hide. By increasing output, it increases the need for judgment without increasing capacity to absorb it.

Whether organisations learn faster or stop getting better depends on leadership accepting that trade-offs are real: Learning takes time. Judgment takes energy. Reflection consumes capacity.

When systems are designed as if these were infinite, learning loops collapse by design.
The system design fails and we blame it on culture. And once AI is in the loop, that failure accelerates.

Evolution and decline of your workforce are no coincidence. It’s a design choice that needs to be taken early – one that creates work that does not break.

Why Task Reconfiguration Breaks Job Design

In many organisations, the breakdown does not show up as a dramatic failure: There is no outage, no scandal and no obvious crisis. Instead, it shows up in a more corrosive way: people are constantly busy, permanently responsive and yet rarely feel effective.

Work keeps moving. Meetings multiply. Decisions are made. Outputs are produced.
But underneath the motion, something fundamental has fractured: roles no longer hold.

This article examines a design failure that is becoming increasingly common as AI reshapes work faster than organisations redesign jobs: the rise of hybrid roles. Not as an intentional choice, but as an unresolved system consequence.

The Design Constraint We Keep Ignoring

Cognitive coherence matters.

Humans do not struggle primarily because work is difficult. They struggle when work is fragmented across incompatible cognitive contexts without boundaries, sequencing, or closure.

A role is not simply a bundle of tasks, it is a pattern of thinking:

• what kind of attention is required
• what decisions recur
• how authority and responsibility align
• how effort accumulates and resolves

When these elements are coherent, even demanding roles can be sustained. When they are not, performance degrades – erratically.

The mistake organisations keep making is subtle: they reconfigure tasks and assume roles will somehow re-stabilise on their own. They won’t.

When tasks change faster than roles

AI does not merely automate work it rearranges where human effort sits in the system.

When execution accelerates, generation becomes cheap and analysis multiplies, what remains for humans is rarely “less work”. It is different work:

• reviewing instead of producing
• supervising instead of executing
• handling exceptions instead of following flows
• explaining outcomes instead of creating inputs
• coordinating across systems instead of working within them

Each shift makes sense locally, but the problem is what happens in aggregate.

Tasks are added, removed, or transformed faster than roles are redesigned – forcing roles to absorb the change.

This is how hybrid roles emerge – not through deliberate design, but through accumulation.

The anatomy of a hybrid role

A hybrid role is not “broader” in a healthy way. It is a role where distinct cognitive modes are collapsed into the same person, often within the same hour, without sequencing or clarity.

Many modern roles now combine:

• execution (doing the work)
• supervision (monitoring AI or others)
• exception handling (intervening when things break)
• coordination (aligning across teams, tools and priorities)
• accountability (owning outcomes without full control)

Individually, none of these are problematic – but together, without design, they are – because each mode requires a different stance:

• Execution rewards immersion and flow.
• Supervision rewards vigilance and scepticism.
• Exception handling demands urgency and judgment.
• Coordination requires social navigation and context switching.
• Accountability adds emotional and cognitive weight to every decision.

When these modes are entangled, the role loses rhythm. People feel permanently “on” but rarely finished.

Why this feels exhausting even when workload looks reasonable

From the outside, hybrid roles often look manageable:

• Headcount is stable. 
• Working hours may even appear reasonable. 
• Productivity dashboards still show output.

And yet people report:

• mental fatigue without clear cause
• constant task switching
• difficulty prioritising
• a sense that nothing is ever truly “done”
• anxiety about responsibility without clarity on authority

This is not a resilience problem; it is a design problem.

Cognitive load does not only come from difficult tasks it comes from context switching, unfinished loops, ambiguous ownership and incompatible demands sharing the same mental space. And hybrid roles maximise all four.

A role works because it makes an implicit promise: that effort will resolve into outcomes.

Hybrid roles break when that promise disappears.

The system-level consequence

At a system level, the effects compound because roles are fragmented:

• Decisions slow down despite faster tools.
• Escalations increase, not because issues are bigger, but because ownership is unclear.
• People over-document, over-check and over-coordinate.
• Responsiveness replaces effectiveness as a performance signal.

Organisations interpret this as a need for more skills, more training, better tools or clearer instructions. But none of those address the underlying issue: The role itself has lost its integrity.

People are not failing at their jobs. Their jobs are failing to hold together as units of work.

Why AI makes this worse – not because it’s wrong, but because it’s fast

AI is not the root cause of hybrid roles; it is the accelerant.

At human speed, weak role design can remain tolerable because latency hides fragmentation and informal judgment compensates. Yet AI removes those buffers.

When outputs multiply and cycles compress:

• micro-decisions accumulate faster than reflection
• interruptions increase
• optionality explodes
• accountability tightens without becoming clearer

Hybrid roles become cognitively unsustainable not because any single task is too hard, but because the role no longer has a stable centre of gravity.

The failure mode leaders miss

Many leaders interpret hybrid roles as maturity:

• “Our people have broader scope now.”
• “They operate across silos.”
• “They’re closer to the end-to-end picture.”

Sometimes that’s true – but only when roles are consciously designed. Otherwise, they don’t get “broader”; they get blurrier.

But most hybrid roles are not designed end-to-end. They are the result of:

• incremental automation
• layered responsibilities
• shifting expectations
• and unresolved trade-offs pushed downward

The result is not empowerment – it is role overload disguised as versatility.

How the operating model absorbs the problem

High-functioning organisations do not try to “fix” hybrid roles by simplifying people. They redesign the system so roles can recover coherence.

Several design moves show up consistently.

1. Roles are designed around outcomes and decision scope, not task lists

Task lists fragment roles – outcomes stabilise them.

When a role is anchored to

• a clear outcome,
• a defined decision scope and
• explicit trade-offs it is allowed to resolve,

tasks can change without breaking coherence.

Without that anchor, every new task is just more cognitive noise. This is why many AI-augmented roles feel heavier even when tasks are faster: the role has no clear decision centre.

2. Interfaces between roles are explicitly designed

Most fragmentation happens between roles, not within them. Unclear handoffs, partial ownership, shared accountability and invisible dependencies force people to hold too much context “just in case”.

Well-designed systems make interfaces explicit:

• where responsibility ends
• what quality looks like at handover
• when escalation is expected
• and when interference is not allowed

This reduces coordination load without reducing collaboration.

3. Work is sequenced so cognitive modes don’t collide

Hybrid roles often fail not because they include too much, but because everything is concurrent: Execution, supervision, coordination and exception handling compete for the same attention window.

Sustainable systems sequence work:

• focus blocks are protected
• review happens at defined moments
• exceptions interrupt by design, not by default
• coordination has rhythm, not randomness

This restores cognitive rhythm – something humans rely on far more than capacity.

4. Priorities are stabilised long enough for roles to make sense

Constant reprioritisation is one of the fastest ways to destroy role coherence.

When direction shifts faster than roles can adapt:

• ownership feels provisional
• accountability feels unfair
• and effort feels wasted

Stabilising priorities is not about rigidity, it is about giving roles enough time to form meaning. Without that, no amount of clarity survives.

Designing work that can be trusted

The goal is not to eliminate hybrid roles entirely (many modern roles do require breadth). The goal is to restore integrity:

• a role with a centre
• boundaries that protect focus
• ownership that matches accountability
• and sequencing that respects human limits

Efficiency gains without role integrity do not create performance, they create fragility.

When Hybrid Roles Work – and When They Don’t

Hybrid roles are often discussed as if they were either the future of empowered work or the cause of modern overload.

Both views miss the point: Hybrid roles are neither inherently good nor inherently broken. What matters is how they are designed and governed.

Research shows that roles combining execution, coordination, sense-making or boundary-spanning activities can improve performance, innovation and learning – when conditions are right. Relevant interruptions can support engagement. Autonomy enables job crafting. Leadership support mitigates ambiguity. Cross-boundary roles can create real organisational value.

But those same studies also show the other side of the ledger: increased role stress, cognitive strain and performance erosion when demands accumulate without structure. That is the line most organisations cross.

Hybrid roles stop working when they collapse incompatible cognitive demands into the same moment. When people are expected to deliver, supervise AI outputs, handle exceptions, coordinate across teams and remain accountable – all at once. When priorities shift continuously. When ownership is unclear and escalation is emotional rather than structural.

In these environments, hybridity no longer integrates work – it fragments it.

People appear constantly active but struggle to reach closure. Context switching becomes the default mode. Cognitive load rises, not because tasks are too complex, but because the role never resolves into a stable pattern of judgment and action.

The problem is not flexibility, it is unsequenced flexibility.

Well-designed operating models absorb hybrid complexity before it reaches individuals. They define when work requires deep focus versus monitoring. They stabilise decision scope and sequence collaboration instead of letting it interrupt everything else. They make boundaries explicit so people don’t have to hold the entire system in their head “just in case”.

When roles are designed this way, hybridity scales.
When they aren’t, roles become patchworks – and people pay the cognitive price.

Hybrid roles don’t fail because they are demanding – they fail when the system treats human coherence as optional.

(For a deeper look at what happens when supervision and judgment are added to roles without capacity or sequencing, see The Verification Tax.)

The bottom line: Hybrid roles are not evidence of progress by default

In most organisations, they are a signal that task reconfiguration has outpaced job design.

People feel constantly “on” because the system demands it. And they feel rarely effective because the role no longer resolves into something whole.

This is neither a talent problem, nor a motivation problem – and it is not fixed by coping strategies or better tools.

It is an operating model problem that requires conscious design choices.

If organisations want AI-enabled performance that lasts, they must stop treating roles as flexible containers and start treating them as cognitive systems with limits.

Watch efficiency gains collapse into exhaustion, friction and lost judgment or design for role integrity – for work that does not break.

So, there you are.

After countless strategy sessions, setting up your AI-enhanced operating model and assigning influential stakeholders to their roles.

You’re ready. Ready to finally get your hands dirty and to kick off the transformation towards your big, hairy, audacious vision.

But immediately everything screeches to a halt, just as you finally were able to kick off the whole thing.

You wonder what happened? You got entangled in an argument over an operational decision in an alignment meeting. This led to a decision meeting with all relevant stakeholders that took forever to schedule. And eventually, its final decision was later again overruled in a SteerCo meeting by strategic management.

Welcome to corporate decision-making.

Decisions are the bottleneck of transformation

“Strategy is deciding what not to do.” – Steve Jobs

He was as right as one could be. Good strategy, and even more, its successful execution is the direct result of excellent decision making within an organization.

But far too often decisions are slow, unclear, or avoided altogether.

But what does excellent decision making actually look like?

This article will equip you with a three-layer model, optimize your organizations decision-making capabilities with four design principles and give actionable cues to exercise your personal decision-making muscle as a leader for timely and high-quality decisions.

Decision-making is a team sport (Layer 1, Decision Making System)

Don’t get me wrong. It’s healthy if strategic decisions arising from operational topics are escalated in SteerCos to strategic management. What is not healthy is when decisions are always escalated to a decision-making superhero.

But wait, concentrating decision-power on few decision makers gives management full agency, and therefore ultimate control on the outcomes of a transformation. Doesn’t this sound effective?

Even if this feels tempting, it is a slippery slope, leading to issues down the line.

Heroic decision-makers don’t scale.

When concentrating decision power, top management becomes a bottle neck for decisions. It puts the brakes on the company’s strategic development, because it forces top-management – whose core responsibility is to orchestrate the bigger picture – to continuously switch between operational and strategic topics. It does not only consume time that could have been spent on strategic decisions, but even worse, causes “switching costs” and decision fatigue, proven to reduces overall decision quality. (Source)

Additionally, there are negative effects outside of the management board: Heroic decision-making fosters a culture of “not deciding” and deteriorates ownership, buy-in and agency in operational layers. This can be experienced in several symptoms within the team:

• Meetings become discussion clubs.
• Everyone is “aligned” – but nothing moves.
• Decisions get passed around like a hot potato.

Does this sound familiar?

Decision-Making needs a systemic approach: 4 design principles

Decision-making is not an individual skill.
It’s an organizational capability.

To develop this capability, it is crucial to build a system that puts the decision-logic in operation. This must be embedded in the existing operating model and reflect four design principles, that ensure decisions are made…

• …transparent.
  Decisions are visible. Ownership, inputs, and outcomes are clear to everyone involved with no hidden agendas.
  If decisions are not visible, they will be challenged repeatedly.
• …understandable.
  Decisions can be explained. The logic behind them is clear and structured.
  People don’t just see the outcome, but understand the “why”.
  If a decision cannot be explained, it will not be executed.
• …repeatable.
  Decisions don’t depend on individuals. The organization develops consistency in how it decides, so similar situations, follow similar logic, leading to similar results.
  If decisions depend on individuals, they will not scale.
• …consistently improved.
  Decision-making gets better over time, as outcomes are reviewed and the system is refined based on the results.
  If decision logic is not repeatable, every situation becomes a new debate.

The ideal setup can differ from organization to organization. You can find  a proven model in this article Spotlight On: Collaboration

Concluding on a decision (Layer 2, Decisiveness)

The decision-making process provides the frame, in which individual leaders can contribute. Still, the individual capabilities matter – a lot.

Whereas decision-making describes the process of collecting, evaluating and concluding the available options, decisiveness is the timely, confident action-taking required to commit and execute on a single option.

Decisiveness is the opposite of decision-paralysis

Decisiveness is a lot of “filling in the blanks”, because often not all or ambiguous information, is available when a decision must be made. It is the human factor in decision-making, because it takes courage, in-linear thinking, abstracting knowledge from previous unrelated experiences, and willingness to execution at the same time.

But this implies one thing, that there is a possibility of being wrong.

Put bluntly: We optimize our decision‑making to consistently make the right choices.

All the data driven decision-making, first-principle thinking and scenario-planning implies the desire to optimize to be less wrong, and more right. And that is a noble goal. But eventually we operate in an environment that is becoming increasingly complex and in-comprehensible.

Decision accounting: Cost of Error vs. Cost of Delay

Transformations are uncertain by design. Here is a helpful perspective to navigate decision-making in ambiguous and uncomprehensible situations.

Every decision comes with two types of costs. The cost of being wrong and the cost of being slow. Both are due at all times. Most organizations are wired to avoid wrong decisions. They analyze, align and escalate to make the “perfect” decision.

But in doing so, they introduce something, such as costly: Delay.

While everyone is busy minimizing the risk of being wrong, time passes, opportunities close, and momentum is lost. This stalls transformation.

The irony is, that in many cases, a slightly wrong decision made quickly creates more value than the perfect decision made too late. Very view decisions are irreversible, or at least, can be made in a way, that they can be course corrected after their execution.

Take the launch of an online service chatbot of a retailer for example, they theoretically could fire all their service staff and launch their chatbot, all at once, with a big bang approach. Or, more pragmatic, launch the chatbot as an additional service offering and refining it iteration by iteration, slowly reskilling service reps, to act as second level support, or offer value adding services to their clients.

If a decision is reversable or at least adjustable after their execution, account for the cost of delay, similarly as the cost of making a “wrong” decision.

The best decision is worthless if it’s executed poorly (Layer 3, execution)

Congratulation! A decision was made.

But nothing happens. Or inversely, a strategic decision is challenged or even re-interpreted, hence diluted, by middle management as it cascades into the organization. Politics and different interests of stakeholders collide and influence its result.

Silent disagreement is the biggest enemy of execution.

Every strategic decision must translate into a chain of smaller decisions on operational level. Commitment on all levels is key for effective decision execution. Without it, decisions don’t cascade.

But commitment is often misunderstood. In many organizations, alignment is pursued in the form of agreement. Stakeholders align on outcomes, responsibilities, and timelines. Decisions are documented and communicated.

Yet, execution still breaks down.

The reason is that disagreement does not disappear simply because it is not voiced. What is not challenged openly will be resisted silently.

This is a critical dynamic in decision-making. If disagreement is not surfaced during the decision process, it will reappear during execution. This could be hesitation, reinterpretation, or deviation from the original solution. As a result, each organizational level effectively becomes a new decision point, slowing down or even blocking execution.

Once a decision is made, however, it must be carried forward consistently.

Because only decisions that are truly committed to will cascade. And only decisions that cascade will reach execution.

Make decisions that survive contact with the organization.

If decision making happens transparent, understandable, and repeatable, you are off to a good start. But reality shows that consensus cannot always be reached in all stakeholders. Genuine commitment depends therefore strongly on the ability for stakeholders to disagree with its outcome but commit to and support the decision.

This concept is widely known as “disagree and commit”. It requires that stakeholders are given the space to challenge a decision, understand its trade-offs, and make their perspectives visible.

Once a decision is made, however, it must be carried forward consistently. If stakeholders raised a concern yet were not able to swing the decision with their argument, they are expected to commit to its outcome. This concept is attributed to Andrew Grove, the former CEO of Intel.

It sounds simple, but its execution all but trivial.

It’s typical blocker is missing understanding of trade-offs. That is because alignment is usually uniquely focused on the “outcome” side. What shall be achieved. How it shall be achieved. Who is responsible.

But never on the resulting trade-offs.

The options that were left on the table. The side effects of the short-term focus on the long term progress, of speed and quality etc.

Or, closing the loop to our initial Stefe Jobs quote, “What you decide not to do”.

Make them visible by stating them clearly. One by one.

Because these are our typical discussion points when cascading decisions through operational layers: Why didn’t we chose to do this instead?

To enable stakeholders to commit, whilst disagreeing with the decision, you need to create this transparency. Whilst it is not a guarantee for general commitment, missing transparency is a sure way for lack of commitment.

For smooth cascading of decisions from strategy to execution use the following sequence:

Collect and clarify trade-offs during your decision process. Involve your operation al leaders, responsible for cascading the decision afterwards in order to cover existing blind spots. Cut corners in this step and you will lose decision quality.

Then commit. Then cascade.

If you want to learn more about decision-making in transformations discover five mechanisms that build alignment in our article: Stop Chasing ‘Buy‑In’.

Final Thought

If it’s not yet documented, sketch out how decision-making is performed in your organization.

Is it transparent? Is it understandable? Is it repeatable? How does it improve over time?

And most importantly: Does it build commitment?

Because transformation relies on how decisions are formed, how they are committed and how they are executed.

Describe – but more importantly – fix that system. Then decisions will stop being the bottleneck and start becoming the driver of transformation.

Because decisions don’t create value. Executed decisions do.

“The Model Said So” Is Not a Defence

In every organisation that embeds AI into daily decisions, a shift happens. Not all at once but unmistakable once you see it – unannounced.

Decisions start moving faster. Recommendations look sharper. Outputs feel more confident. And yet, when something goes wrong, accountability gets strangely fuzzy.
No one quite decided.

The system suggested. The model recommended. The dashboard flagged.
So, who’s responsible?

This is the accountability gap. And it is not a tooling problem: It’s a design failure.
Those systems did not emerge accidentally; they were approved, scaled and legitimised by leadership.

Most accountability discussions assume a human decision-maker who fails to act.
This article addresses a different failure: systems where responsibility becomes structurally unassignable, even as risk scales and consequences remain very real.

It explores why responsibility disappears before risk does – and why leaders remain accountable for the systems that make this disappearance possible

The Design Constraint We Keep Ignoring

Responsibility cannot be automated.

Execution can be accelerated, analysis can be augmented, options can be generated at scale, but the moment an outcome matters – legally, financially, reputationally, ethically – responsibility is still human. AI does not carry consequence. It does not get fired, sued, promoted, trusted or avoided. People do.

Yet many operating models now distribute decision power without redesigning decision ownership. The result is a structural imbalance: authority flows downward via systems, while accountability flows upward through hierarchy.

People act on recommendations they didn’t choose. Leaders carry outcomes they couldn’t see forming. That gap is where trust erodes.

“The model said so” as an organisational reflex

In high-paced environments, “the system said so” becomes more than a phrase. It becomes a protective reflex.

• It reduces personal exposure.
• It deflects blame.
• It short-circuits uncomfortable judgment calls.

This isn’t bad faith. It’s rational behaviour inside a poorly designed system.

When the cost of being wrong is high and ownership is ambiguous, people will naturally lean on artefacts that appear objective. Algorithms feel safer than judgment, dashboards feel sturdier than intuition and escalations feel like insurance.

But the irony is: The more organisations rely on AI to depersonalise decisions, the more personal the fallout becomes when things fail.

The system-level consequence

Accountability gaps don’t stay local, they compound.

At the task level, people follow recommendations. At the team level, ownership fragments. At the leadership level risk concentrates. Several predictable patterns emerge:

• Decisions feel diffused.
• No single moment of choice is visible.
• Responsibility dissolves into process.
• Escalations increase not because issues are bigger, but because no one feels authorised to decide.

Judgment gets conservative. When downside is personal and authority is unclear, people choose avoidance over resolution. Leaders lose visibility. Outcomes arrive without a traceable decision path.

This mirrors the “verification tax” described earlier in the series: AI reduces local effort but increases system-wide cognitive and governance load. Responsibility becomes heavier precisely where it is least supported.

Why hierarchy makes this worse

Traditional hierarchy assumes decisions flow up and execution flows down. AI inverts this.

Decisions are increasingly embedded inside workflows, tools and models – far below formal decision rights. But when consequences materialise, escalation still follows hierarchy upward. So we get a mismatch:

• Teams execute without authority.
• Leaders are accountable without insight.

Both sides feel trapped and neither is technically at fault.
This is not a problem you can solve with clearer approval matrices or stricter sign-off rules. That only adds latency and fear.

The issue is when and where responsibility is made explicit.

Accountability is a design property

Well-designed systems make responsibility obvious before decisions happen, not after outcomes land.
In organisations that absorb AI without accountability gaps, several design principles show up consistently.

1. Decision rights are designed before tools are deployed

AI should enter decisions that are already owned – not create new, ownerless ones.

Before introducing recommendations, ask:

• Who is allowed to overrule this?
• Who must stand by the outcome?
• What happens when signals conflict?

If these questions don’t have answers, the system isn’t ready for automation.

2. Accountability follows outcomes end‑to‑end

Responsibility should track the impact of a decision, not the organisational layer where it occurred.
The person closest to the decision context often has the best judgment. The organisation must give them both:

1. the authority to decide and
2. the safety to own the result.

Without that pairing, accountability becomes ceremonial.

3. Escalation is structural, not emotional

Escalation should exist to handle genuine trade‑offs – not as protection against blame. That requires explicit triggers:

• uncertainty thresholds
• risk boundaries
• cross‑domain conflicts

When escalation is designed into the workflow, it stops being a signal of fear.

4. Principles prevent hiding behind the system

Rules are brittle. Models are opaque. Principles scale.

Shared decision principles – when to favour speed over precision, autonomy over consistency, local optimisation over global risk – create coherence that tools alone cannot.

They restore human judgment where it matters most.

Making responsibility explicit without slowing everything down

The fear many leaders have is that clarity will kill speed – but in practice, the opposite happens.

When people know:

• what decisions they own,
• where boundaries are,
• and when escalation is expected,

they decide faster – with less second‑guessing and documentation overhead.

Clarity removes defensive behaviour. Responsibility, when well designed, is an accelerant.

AI is not the cause, it’s the amplifier

Removing the buffer

At this point, it is worth pausing to clarify the argument.

AI is not creating accountability problems out of nothing. It is amplifying what is already there.
When decision ownership is unclear, escalation is informal, or authority and consequence are misaligned, those weaknesses often remain tolerable at human speed. Friction hides them. Latency absorbs them. Informal judgment compensates.

But AI removes that buffer. Once AI enters the decision loop, structural ambiguities stop being forgiving. Responsibility can drift away from control even as output quality appears to improve.

Responsibility without control

Research consistently shows that in complex automated systems; humans are often held morally or legally responsible despite having limited visibility into – or influence over – how outcomes emerge. This has been described as the moral crumple zone: when something fails, responsibility collapses onto the nearest human actor, even if control was distributed across tools, models and teams.

Decision‑support systems introduce a related effect: an attributability gap. Decisions still embed human judgment and values, but these become harder to locate. Judgment is smeared across recommendations, thresholds, defaults and workflows.

Responsibility diffuses across chains rather than attaching to a clear moment of choice.

Accountability reconstructed after the fact

Where outcomes emerge through sequences of small, AI‑assisted decisions, no single step appears decisive. Accountability is reconstructed after the fact rather than experienced at the moment of decision.

Accountability gaps form not through abdication, but through accumulation without ownership.

This distinction matters because behaviour follows felt responsibility more reliably than formal role descriptions. Experimental studies consistently find that interacting with AI can reduce people’s experienced sense of authorship, especially in high‑stakes or morally charged contexts – even when humans formally “own” the decision.

How blame shifts

At the same time, evidence is clear on one important point: “The model said so” is not a universal shield.

Observers do not reliably excuse decision makers simply because an algorithm was involved. In some cases, blame intensifies when people perceive responsibility was deferred. In others, blame shifts toward the system itself, enabling scapegoating dynamics.

AI does not remove accountability. It destabilises how accountability is perceived.

Why reminders are insufficient

One finding is especially relevant for leaders designing operating models: declaring responsibility is not enough.

Explicit reminders – “you are responsible” – do not reliably reduce over‑reliance on AI. What helps more consistently is verifiability: making system limitations visible, highlighting the possibility of error and enabling meaningful interrogation of outputs.

What AI exposes

Put differently: AI does not cause accountability gaps – it removes the slack that used to hide them.

• If responsibility was implicit before, it becomes invisible.
• If escalation was emotional before, it becomes political.
• If judgment was distributed informally before, it becomes untraceable.

That is why this is not a tooling problem and not a compliance issue, but an operating‑model problem.

Designing work that can be trusted

Accountability gaps are not a moral failure nor a training gap. They are not fixed by telling people to “be accountable” or by writing stronger policies.

They emerge when systems distribute influence without consequence.

If AI is to improve performance without breaking trust, organisations must redesign responsibility as deliberately as they design throughput.

“The model said so” is never a defence. But a system that makes ownership explicit, judgment visible and escalation purposeful – that is.

Operating models do not emerge accidentally. They are shaped through explicit and implicit leadership choices: what gets automated, where authority is placed and which risks are absorbed centrally versus pushed downward.

That’s how you design work that doesn’t break.

Why AI Productivity Can Kill Decision Quality

AI tools promise leverage. Faster drafts. More options. Instant analysis. And in isolation, they often deliver exactly that. But at the system level – across teams, decisions and accountability chains – something more subtle and corrosive appears. Leaders feel busier, not calmer. Output increases, but confidence erodes. Decisions move faster locally while getting worse globally.

This is not a tooling failure. It is a design failure.

The missing concept is what I call the verification tax: the cumulative, usually invisible cost of interpreting, validating and taking responsibility for AI-assisted outputs. Organizations treat this tax as free. It is not.

This article builds on the core premise of Designing for Human Limits: human judgment is finite, fragile and non-linear. When we design systems that scale output without redesigning judgment, we don’t get productivity – we get decision debt.

This article explores why faster decisions become worse decisions.

The Design Constraint We Keep Ignoring

Human judgment does not scale linearly with output.

Every AI-generated suggestion – no matter how good – still requires a human to:

• Interpret it in context
• Judge whether it is good enough
• Detect subtle errors or omissions
• Decide when to stop iterating
• Carry accountability for the outcome

AI reduces execution effort. It does not reduce responsibility. In many cases, it increases it.

Research on human–AI collaboration consistently shows that review and verification are cognitively expensive, often more demanding than producing a first draft yourself. Detecting errors requires focused attention, domain knowledge and sustained vigilance – especially when outputs are mostly correct.
This cost is highest under conditions of high apparent correctness and low-salience errors; precisely where human reviewers are least reliable and most confident they are not.

The result is a structural mismatch: systems optimized for throughput, layered onto humans optimized for judgment.

From Local Speed to Systemic Drag

At the task level, AI looks like a win:

• The draft arrives faster
• The analysis is broader
• Options are plentiful

At the system level, something else happens.

Verification effort accumulates. People double-check. They regenerate “just once more”. They hedge decisions. They escalate for reassurance. They document defensively. None of this shows up in productivity metrics.

Studies on automation bias and selective adherence show a paradox: people either over-rely on AI when verification feels costly, or they over-verify when trust is low. Both patterns degrade decision quality in different ways .

This is the verification tax in action:

• More output → more decisions about output
• More decisions → more cognitive load
• More load → worse judgment 

Speed increases locally. Decision quality degrades system-wide.

Why Leaders Feel Busier – and Less Confident

Many leaders report a strange emotional pattern after AI adoption:

We’re moving faster, but I’m less sure we’re making good decisions

That feeling is rational.
AI expands optionality. Every output could be improved. Every answer could be questioned. Closure becomes subjective. Progress depends less on criteria and more on confidence.

Human–computer interaction research shows that when systems increase the frequency of judgments – even small ones – mental fatigue rises sharply, independent of task difficulty. This is not about complexity. It’s about accumulation .

The system hasn’t removed work. It has shifted work from execution to evaluation.
And evaluation is where human limits bite hardest.

Accountability Is the Hidden Multiplier

There is another reason the verification tax grows so quickly: accountability does not scale with automation.

When AI contributes to a decision, responsibility does not diffuse. It concentrates.

Legal, ethical and organizational research on algorithmic accountability is clear: humans remain accountable even when systems advise, recommend, or pre-structure decisions. The burden of justification shifts to the human reviewer, not the tool.

This creates a predictable behavior:

• People verify not for quality, but for self-protection
• Decisions become conservative and defensive
• Escalation replaces ownership
• Verification becomes anxiety, not discernment.
• The tax increases again.

How the Operating Model Absorbs the Tax (Without Naming It)

High-functioning organizations don’t eliminate the verification tax. They design around it.
Not by verifying everything, but by verifying at the right altitude.

1. Decisions Are Anchored to Outcomes, Not Tasks

Teams are not rewarded for “using AI well.” They are accountable for outcomes.
This collapses endless iteration. It forces the question: What decision is this output meant to support?
When outcomes are explicit, verification becomes purposeful instead of exhaustive.

2. Ownership Is Clear – and Personal

Someone owns the decision. Not the prompt. Not the model. The decision.
Research on meaningful human involvement shows that clear ownership increases calibrated trust and reduces both over-reliance and over-checking .

Ambiguous ownership is the fastest way to inflate the tax.

3. Verification Effort Is Made Visible

Verification time is tracked – not to optimize people, but to design systems.
When leaders can see where judgment is being consumed, they can:

• Simplify tasks
• Reduce optionality
• Change review depth by risk

What remains invisible cannot be designed.

4. Principles Act as Guardrails

Principles prevent re-litigation.
When teams share clear decision principles, they don’t debate every AI-assisted choice from first principles. They know what “good enough” means.

This dramatically reduces judgment load while preserving quality.

Verifying at the Right Altitude

The goal is not to verify everything. It is to decide where human judgment adds the most value:

• High-stakes, irreversible decisions → deep verification
• Reversible, low-risk decisions → spot checks
• Repetitive, stable tasks → automation with audits

Research consistently shows that selective, well-designed verification outperforms blanket review – both in accuracy and in human sustainability.

This is an operating model question, not a tooling one.

The bottom line

Leadership must stop pretending that human judgment is infinitely elastic. It is not.

Every AI system consumes judgment somewhere. If you don’t design for that consumption, the organization will absorb it; through burnout, hesitation and degraded decisions.

The future of AI-enabled work is not about faster output. It is about preserving judgment under acceleration.

Design for human limits – or pay the tax later, with interest.

For the last decade, organizations have treated performance as a capacity problem. If results fall short, the answer is usually more effort, more tools, more change. But the reality leaders are now running into – especially with AI in the system – is simpler and more uncomfortable:

Work is breaking because it is designed as if humans were infinite.

Decision load is treated as free. Attention is assumed to scale. Accountability is stretched without being redesigned. Learning is expected to “just happen” alongside execution. When systems fail under that pressure, we label the outcome burnout, resistance or skill gaps. But those are symptoms, not causes.

This series starts from a different premise: Performance is not a motivation problem. It is a design problem.

Human limits are not weaknesses to be trained away. They are constraints that must be designed for – just like latency, capacity or risk in any other system. Ignore them and systems become fragile. Design around them and performance becomes durable.

The issues explored in this series don’t persist because people lack skill or discipline. They persist because operating models assume levels of capacity, judgment and accountability that humans simply don’t have at scale. Fixing them requires redesigning the system, not asking individuals to compensate for it.

This is not a series about working less. It is a series about designing work that can actually be sustained – under uncertainty, speed and continuous change.

Work that does not break.

All articles of the Designing for Human Limits series:

• The future of work is burnout. What performance means in the age of AI.
• The Verification Tax. Why AI Productivity Can Kill Decision Quality.
• Accountability Gaps. “The Model Said So” Is Not a Defense.
• Hybrid Roles. Why Task Reconfiguration Breaks Job Design.
• Learning Loops. When AI Accelerates Learning vs. Kills It.
• Deskilling by Design. When Automation Weakens Expertise.
• The Unlearning Company. Why Continuous Improvement Stops Improving?
• More articles to follow.