Delegation Poker sounds playful. Almost too playful.

But the problem it addresses is not playful at all.

Many companies do not have a delegation problem. They have an honesty problem.

They say teams are empowered. They say decisions should be made closer to the work. They say leadership wants ownership.

Then the first uncomfortable decision comes along and suddenly everything moves back to the top.

That is where Delegation Poker can help.

Not because it magically creates better leadership. It does not. And not because a deck of cards can fix trust issues. It cannot.

Delegation Poker is useful because it makes one thing visible that many organizations prefer to keep vague:

Who is actually allowed to decide?

It is not about giving power away.

It is about making power visible.

The real issue: fuzzy authority

Most organizations have job titles, reporting lines, steering committees, approval workflows and strategy decks.

And still, when a real decision needs to be made, people hesitate.

A product team thinks it owns the roadmap. Sales thinks customer commitments should drive priorities. Finance wants to approve anything with budget impact. Legal gets involved late and stops the train. The executive team says it wants empowered teams, but reverses decisions when the result feels uncomfortable.

This is not rare. It is normal.

The problem is that formal authority and practical authority are often two different things.

On paper, a team may “own” a topic. In reality, every meaningful decision still needs senior approval. Or the opposite happens: a team makes a decision and later finds out that leadership expected to be consulted.

That is how trust gets damaged.

Teams feel micromanaged. Leaders feel bypassed. Decisions slow down. People start managing politics instead of outcomes.

Delegation Poker does not solve all of this. But it exposes where the confusion sits.

That is already useful leadership work.

What Delegation Poker actually is

Delegation Poker is a Management 3.0 practice based on the Seven Levels of Delegation. It helps teams and leaders clarify who is responsible for what and to what degree.

The core idea is simple:

Delegation is not binary.

It is not just:

“The boss decides.”

Or:

“The team decides.”

There are useful levels in between. You do not need to memorize them. The point is to see that decision authority has shades.

LevelMeaningIn plain language1. TellThe leader decides and informs others.“I decide. You need to know.”2. SellThe leader decides and explains the reasoning.“I decide. I explain why.”3. ConsultThe leader asks for input, then decides.“I listen. Then I decide.”4. AgreeLeader and team decide together.“We decide together.”5. AdviseThe team decides after receiving advice.“You decide. I offer input.”6. InquireThe team decides and explains afterwards.“You decide. I ask how you got there.”7. DelegateThe team decides fully.“You decide. No approval needed.”

The cards are not the point.

The conversation after the cards are shown is the point.

If one person picks level 2 and another picks level 6, the exercise is working. The disagreement was already there. Now it is visible.

Before that moment, both people may have assumed they were aligned.

They were not.

Why this matters for leadership

Good leadership is not about making every decision yourself.

It is also not about pushing every decision downward and calling it empowerment.

Good leadership means placing decisions where three things come together:

1. The right information

2. The right competence

3. The right accountability

That third point matters most.

Accountability is where many empowerment conversations become vague.

It is easy to say:

“The team should decide.”

It is harder to answer:

Who carries the risk if the decision fails?
Who explains the decision to the board?
Who owns the budget impact?
Who handles the customer escalation?
Who documents the reasoning?
Who can reverse the decision?

These are not side questions. They are the real questions.

Delegation without accountability is not empowerment. It is abdication.

Control without clarity is not leadership. It is friction.

Delegation Poker helps leaders and teams discuss the space in between.

Empowerment is not the goal

Better decisions are the goal.

That distinction matters.

Empowerment sounds good in a town hall. But in the daily life of an organization, empowerment only matters if it helps people make better, faster, better-owned decisions.

That requires more than freedom.

It requires context.
It requires competence.
It requires boundaries.
It requires trust.
And it requires clarity about consequences.

Without those things, “empowerment” becomes a slogan people stop believing.

What research supports - and what it does not

Let’s be precise.

Delegation Poker itself is best understood as a practical facilitation tool, not as a standalone leadership theory with a large body of direct empirical research behind it.

That does not make it weak. It just means we should not oversell it.

The research does not “prove” Delegation Poker as a method. What it does support are the leadership mechanics around it: participation, role clarity, autonomy, trust, competence and accountability.

Research on delegation and consultation suggests that managers are more willing to delegate when they perceive people as competent and aligned with their goals. Research on empowering leadership also points to positive effects on performance, organizational citizenship behavior and creativity, while emphasizing factors such as trust and psychological empowerment. At the same time, reviews of empowering leadership warn that its effects are context-dependent and not always simple or linear.

In plain English:

More freedom can help when people have the skill, information and support to use it well.

More freedom without boundaries creates confusion.

More control without explanation creates resentment.

That is why Delegation Poker can be useful. It gives people a simple language for discussing decision rights without turning the conversation into a power struggle.

A deck of cards cannot fix weak leadership. It cannot create trust where there is none. It cannot make an unprepared team ready overnight. It cannot turn unclear strategy into clear decisions.

But it can reveal whether people are operating with the same assumptions.

Often, they are not.

A practical example

Imagine a company discussing this decision:

Who decides which features go into the next product release?

Product picks level 6:

“We speak with customers, support, engineering and sales every week. We have the best information. We should decide and explain afterwards.”

Sales picks level 3:

“Major customers are waiting for specific commitments. We need to be consulted before priorities are locked.”

The executive team picks level 4:

“Some roadmap decisions affect revenue expectations and board conversations. We cannot be surprised later.”

Engineering picks level 5:

“Product can decide, but delivery risk and technical complexity must be considered before anything is promised.”

This is not a personality conflict.

It is a decision-rights conflict.

Everyone is looking at the same decision from a different risk angle.

A reasonable outcome could be:

Product decides normal roadmap priorities at level 5. Sales and engineering advise before commitment. Executive approval is only required when the decision affects strategic accounts, external revenue commitments or delivery dates already communicated to customers.

That is not bureaucracy.

That is a working agreement.

And it is much better than discovering the disagreement after the decision has already been made.

The biggest misunderstanding

The lazy version of Delegation Poker is:

“Let’s empower the team.”

The useful version is:

“Which decisions are we actually willing to let the team make, even when we disagree with the outcome?”

That is the real test.

Many leaders are comfortable delegating decisions as long as the decision is the one they would have made anyway.

That is not delegation.

That is supervised agreement.

Real delegation includes the possibility that someone else makes a different call.

Not a reckless call.
Not an uninformed call.
But a different call.

This is where leaders often discover their own limits.

They want speed, but also control. They want ownership, but also veto power. They want teams to act independently, but also keep leadership comfortable.

Delegation Poker makes that contradiction harder to hide.

Where Delegation Poker fails

Delegation Poker fails when it becomes theater.

If leadership already knows the answer and only uses the session to create the appearance of participation, people will see through it.

It also fails when teams treat delegation as freedom without consequences.

Level 7 does not mean:

“We decide and nobody can ask questions.”

It means:

“We decide and we are prepared to explain, own and improve the decision.”

The method also fails when the decision areas are too vague.

“Strategy” is too broad.
“Technology” is too broad.
“People topics” is too broad.

Use real decisions:

• Who approves hiring for a new role?

• Who decides vendor selection below a certain budget?

• Who owns product roadmap priority?

• Who can change delivery dates promised to customers?

• Who decides architecture principles?

• Who approves exceptions to security rules?

• Who can stop a project?

• Who can spend from an approved budget?

Delegation Poker works best when the decision is concrete enough that people can imagine the consequences. This also matches the original recommendation to apply the seven levels to important decision areas rather than tiny individual tasks.

How to use it without turning it into a workshop circus

Start small.

Pick five to eight decisions that recently caused friction.

Do not begin with a company-wide delegation program. That usually turns into a heavy exercise with too many people and too little honesty.

Start with one leadership team, one product area, one function or one cross-functional group.

For each decision, ask:

What is being decided?
Who has the best information?
Who carries the risk?
Who needs to be consulted?
Who must be informed?
What is the budget or risk limit?
When does the delegation level change?

That last question is important.

A team may decide freely up to a certain budget. A manager may decide after consultation if customers are affected. A leader may retain decision authority when legal, compliance or reputation risks are involved.

This is not about trust versus mistrust.

It is about making the rules clear before emotions run high.

A simple delegation board could look like this:

Decision areaDelegation levelBoundaryTool choice inside the team6Allowed if annual cost stays below €10,000Product roadmap priority5Sales and engineering advise before commitmentStrategic customer promises3Leadership decides after input from sales and productArchitecture standards5Security must be consulted for critical systemsHiring a new role4Manager and leadership agree togetherBudget reallocation6Allowed within approved quarterly budget

A clear one-page delegation board is often more useful than a twenty-page governance document nobody reads.

What leaders should watch for

Delegation Poker reveals more than decision rights.

It reveals leadership culture.

If leaders always choose low delegation levels, the organization may have a control problem.

If teams always choose high delegation levels, they may underestimate risk.

If every decision lands at level 4, the company may be confusing collaboration with consensus.

Consensus feels safe. It can also become slow, political and expensive.

Not every decision needs everyone in the room.

One useful executive question is:

Is this decision hard to reverse?

If a decision is easy to reverse, move it closer to the people with the best information.

If it is expensive, public, legally sensitive or hard to undo, keep stronger leadership involvement.

This is a better rule than simply saying:

“We need more empowerment.”

Empowerment is not the goal.

Better decisions are the goal.

Getting Started

Run one focused session.

For a first pass, 60 to 90 minutes is often enough if the group works with a small number of concrete decisions.

Bring the people who actually matter for the decisions. Not everyone who has an opinion. Not everyone who might be interested.

Bring the people who decide, advise, own risk or live with the outcome.

Use real decisions. Avoid theory.

For each decision:

1. Clarify the decision in one sentence.

2. Let everyone choose a delegation level silently.

3. Reveal the levels at the same time.

4. Let the highest and lowest voters explain their reasoning.

5. Agree on one level.

6. Write down the boundary conditions.

7. Review it after a few weeks.

That last step matters.

Delegation is not a one-time announcement. It is a working agreement. It should change as competence, trust, risk and business conditions change.

Final Thoughts

I have rarely seen companies slow down because one team made one imperfect decision.

I have seen many companies slow down because nobody knew which decisions teams were truly allowed to make.

That is the quiet cost of fuzzy authority.

People escalate too much. Or they wait too long. Or they act without alignment and pay for it later.

Delegation Poker gives leaders a simple way to clean that up.

It is not a silver bullet. It does not replace trust, competence, judgment or courage.

But it does one thing very well:

It turns vague authority into a conversation people can actually have.

And sometimes that conversation is exactly what leadership has been avoiding.

Useful sources behind this article

Delegation Poker is a Management 3.0 practice based on the Seven Levels of Delegation. This article references the method for explanation and commentary. For the original practice, materials and licensing information, see Management 3.0.

• Management 3.0: Delegation Poker & Delegation Board
  https://management30.com/practice/delegation-poker/

• Jurgen Appelo: The 7 Levels of Delegation
  https://medium.com/@jurgenappelo/the-7-levels-of-delegation-672ec2a48103

• Gary Yukl & Ping Ping Fu: Determinants of Delegation and Consultation by Managers, Journal of Organizational Behavior, 20(2), 219–232, 1999
  https://www.jstor.org/stable/3100422

• Allan Lee, Sara Willis & Amy Wei Tian: Empowering Leadership: A Meta-Analytic Examination of Incremental Contribution, Mediation, and Moderation, Journal of Organizational Behavior, 39(3), 306–325, 2018
  https://research.manchester.ac.uk/en/publications/empowering-leadership-a-meta-analytic-examination-of-incremental-

• Minyoung Cheong, Francis J. Yammarino, Shelley D. Dionne, Seth M. Spain & Chou-Yu Tsai: A Review of the Effectiveness of Empowering Leadership, The Leadership Quarterly, 30(1), 34–58, 2019
  https://www.researchgate.net/publication/327535755_A_Review_of_the_Effectiveness_of_Empowering_Leadership

AI is entering technical organizations not as magic, but as a new layer in the workflow. It can watch, sort, draft, route and recommend, which means leadership is shifting from assigning tasks to designing how humans, software, approvals and exceptions work together. That shift does not stop with managers. Developers, engineers and other specialists are starting to act like team leads for AI agents1 too: assigning work, reviewing outputs, setting boundaries and deciding when human judgment needs to step back in.

AI is not replacing leadership. It is exposing weak leadership.

AI is unlikely to remove the need for leadership.

What it is much more likely to do is expose how much weak leadership was really just task chasing.

For years, a surprising amount of management in technical companies has been part judgment, part coordination and part damage control. Someone chases missing information. Someone translates between engineering and operations. Someone knows which spreadsheet matters, which planner to call and which exception to ignore because it usually looks worse than it is.

That glue work keeps the place running. It also hides weak process design.

Now AI is entering that world. Not as a robot boss. Not as a science-fiction replacement for experience. More like a new layer in the workflow: software that can watch, sort, draft, route, summarize and sometimes trigger the next step.

That is useful. It also forces companies to answer questions they have put off for years.

Who is allowed to decide what?
What needs human approval?
What happens when the system is wrong, but sounds convincing?
Who owns the exception?
Who owns the mess after the exception?

That is why this is a leadership topic.

Not because AI suddenly became wise. Because the old management model was often thinner than people wanted to admit.

The real opportunity is not “more AI”

Most companies do not need another AI pilot. In many cases, they need cleaner workflows.

That part gets buried under all the talk about agents, copilots, assistants, automation and digital labor2. The bigger opportunity is not one more clever tool. It is finally fixing work design that should have been fixed years ago.

Recent work from McKinsey, Microsoft and Deloitte points in roughly the same direction: AI adoption is moving faster than organizational redesign. The technology is spreading. The management model is still catching up.

And most organizations already know where the drag lives.

It lives in bad handoffs.
It lives in unclear approvals.
It lives in rework.
It lives in five people checking the same thing because nobody trusts the upstream input.
It lives in experienced employees carrying too much invisible context in their heads.

AI can help with that. Not magically. But enough to matter.

The manager’s job is moving up a level

The old question was simple: Who owns the task?

That is still useful. But it is no longer enough.

Once AI starts doing part of the watching, sorting, drafting or recommending, the more important question becomes: How should this system work?

That is a different kind of leadership.

It is less about assigning work item by item and more about designing the rules around the work. What is automated. What is assisted. What stays recommendation-only. What needs sign-off. What gets logged. What gets escalated. What gets reviewed a week later, when people can admit what really happened.

Where AI is allowed to route work, trigger actions or materially shape decisions, you are redesigning authority whether you use that language or not.

And this shift does not stop with formal managers.

In many technical teams, individual contributors are starting to take on a kind of frontline leadership too. A software developer working with several AI agents is no longer just writing code. They are assigning subtasks, reviewing outputs, rejecting weak work, setting boundaries and deciding when human intervention is needed. In practice, that starts to look a lot like being a team lead for digital workers, even if nobody changes the title on the org chart.

That matters because it changes where leadership sits. Some of the first real managers of AI systems will not be VPs. They will be developers, engineers, analysts and operators who learn how to direct, review and contain machine-driven work before the organization fully catches up.

Leadership teams usually do not notice any of this until the first uncomfortable moment.

The planner says, “I’m not taking a line down because the model flagged a pattern.”
The engineer says, “Why am I only seeing this after the system already routed it?”
The operations manager says, “If this is wrong, who owns the call?”
The project sponsor says, “Let’s not slow the rollout with too many controls.”

That last sentence causes more trouble than most AI demos.

Because nobody wants to look anti-innovation. So teams leave the boundaries fuzzy. They tell themselves they will tighten governance later. What that often means is that the workflow goes live before anyone has really decided where judgment still belongs.

What this can look like inside a real company
An example org chart for a technical organization where human teams and AI agents work side by side.

Example structure: formal managers still own accountability, but AI agents increasingly support workflows across engineering, operations, quality and finance. In some teams, individual contributors begin to act like frontline leads for digital workers.

Think shopfloor, not software demo

The best mental model for human–AI teamwork3 is not a futuristic office. It is a production line.

On a good line, nobody relies on heroics as the operating model. The flow is designed. Checks happen at known points. Escalation paths exist before the problem arrives. When something drifts out of tolerance, the system makes the issue visible and gets the right person involved.

That is how human–AI teams should work.

Let the system do the repetitive work machines are good at: watching signals, comparing patterns, pulling context, preparing first drafts, checking for missing information, routing the issue, flagging anomalies.

Let people handle the parts that are still stubbornly human: tradeoffs, timing, exceptions, accountability, safety, customer impact and those gray areas where the technically correct answer is not automatically the right business answer.

That split is not about human pride. It is about consequence.

The mistake many leaders make is assuming that because AI can produce an answer, it should also carry more authority. Those are different things. A system can be very useful without being given the keys.

What an AI agent actually is in practice

This is where the conversation often gets sloppy.

An AI agent is not a teammate in the normal sense. It does not own outcomes. It does not absorb blame. It does not understand internal politics, operational history or the fact that one supplier always says “confirmed” two days before missing the date.

What it can do is still valuable.

It can turn a messy input into a clean first pass. It can monitor signals at a scale no person wants to. It can surface patterns that would otherwise stay buried in logs, emails and maintenance notes. It can keep a workflow moving when the work is structured enough.

But here is the line leaders need to respect: speed is not judgment.

And the best early use cases are not just repetitive tasks. They are repetitive tasks with reasonably clean inputs, bounded failure costs and clear review logic.

That is where AI tends to help without creating more risk than value.

What strong leadership looks like now

Good leadership in a human–AI setup is not about who writes the best prompt in the room.

It is about four unglamorous things done well.

1. Clear decision rights

Desicion rights4:

• What may the system do on its own?

• What may it recommend only?

• What always needs human approval?

A maintenance system may suggest likely failure modes. That does not mean it gets to schedule downtime.
A service agent may draft a customer response. That does not mean it gets to make a concession.
A quality workflow may flag suspicious patterns. That does not mean it decides whether a shipment gets blocked.

These are leadership calls, not technical settings.

2. Guardrails that reflect reality

In practice, guardrails5 are simple. What data can the system touch? What systems can it access? Which actions are blocked? What thresholds force human review? What needs an audit trail?

If the answer is vague, the control is vague.

And vague control is how teams end up with automation that looks impressive in a dashboard and quietly creates risk everywhere else.

3. Escalation logic

This is the most underestimated part.

The question is not whether the system is right most of the time. The real question is what happens when it is wrong, late, overconfident or technically correct but operationally clueless.

Who gets pulled in?
How fast?
With what context?
And what stops the same failure mode from repeating next week?

A workflow without escalation logic6 is brittle.

4. Feedback that turns overrides into learning

One of the first signs of a weak rollout is that people start working around the system.

They ignore suggestions. They do the real work off-system. They approve recommendations without reading them. Or one trusted expert becomes the unofficial cleanup crew for every edge case the workflow cannot handle.

That is not just resistance. It is diagnostic information.

A particularly bad sign is the appearance of a shadow workflow7. The official process says the agent is triaging, ranking or drafting. The real process moves back to side chats, spreadsheets and quick calls between the same experienced people. The AI is still there, but now it is mostly generating extra steps.

You see this in real organizations when the pilot looks fine on Tuesday, but on Friday afternoon, when output pressure goes up, everybody quietly bypasses the system and goes back to the one planner, one engineer or one service manager who actually knows where the real constraint is.

That usually tells you something important: the model may not be the main problem. The operating logic around it was never believable enough for people to trust under pressure.

A plant-floor example, but the real version

Take a maintenance team in a factory.

The polished demo version is easy: the AI watches vibration data, reads operator notes, checks service history and proposes a likely diagnosis. Everyone nods. Great.

The real version is less clean.

The agent flags a motor as a likely failure risk on a line that is already behind schedule. The planner knows downtime will hit today’s output. The production manager thinks the model is too cautious. The reliability engineer wants a closer look because the same asset has already produced two false alarms this quarter. Meanwhile, the plant manager is asking why the “smart system” cannot just tell the team what to do.

That is a leadership moment.

Not because the answer is hidden in the model. Because somebody has to decide how authority, risk and timing are balanced.

A serious operating model might look like this: the system can triage and recommend, the planner approves downtime, the reliability engineer reviews repeated-failure patterns, changes to maintenance intervals require approval, high-cost actions trigger escalation and accepted and rejected recommendations are reviewed weekly to see whether the system is learning the right lessons.

Now the workflow is not just faster. It is clearer.

And clarity is worth more than speed in more situations than most people think.

The chance most technical leaders are missing

The biggest upside here is not labor reduction.

That is the shallow version of the opportunity.

The deeper opportunity is that AI can make organizations less dependent on invisible heroics.

A junior engineer gets a stronger first view because the relevant history shows up before they have to ask for it.
A planner spends less time chasing context and more time making tradeoffs.
A service manager sees recurring failure patterns earlier instead of hearing about them customer by customer.
A middle manager spends less time being a human router and more time making actual calls.

That matters especially in industrial and technical businesses, where expertise is unevenly distributed and too much operational continuity still depends on a handful of overloaded people who “just know how things work.”

That is not scalable. More important, it is fragile.

The promise of human–AI teamwork, done right, is not that it removes expertise. It gives expertise better reach.

One thing leaders still underestimate: trust is operational

Leaders often talk about trust as if it were a branding issue or an ethics slide.

It is much more practical than that.

People trust a system when they know when it acts, why it acts, when they may overrule it and what happens after they do. They trust it when the escalation path makes sense. They trust it when the same mistake does not keep showing up wrapped in slightly different wording.

They do not trust it because someone said the model is 92 percent accurate.

Trust in human–AI teamwork lives in boundaries, explanations, review loops (human in the loop8) and the everyday behavior of the workflow.

That is why leadership matters so much here. Leaders decide how trust gets built or destroyed in the real world.

Getting started without theater

Do not start with a grand AI vision statement.

Start with one ugly workflow.

Pick something repetitive, annoying, high-volume and important enough that people will care if it gets better. Maintenance triage. Quality deviation handling. Supplier follow-up. Service case routing. Engineering change requests.

Then map the real version of the work. Not the official process. The real one.

Where does it stall?
Where do people chase missing context?
Where do they re-enter data?
Where do decisions actually get made?
Where do exceptions land?
Where does one experienced person quietly save the day every week?

That last question is usually where the truth lives.

Then make the hard calls. What belongs to the system? What belongs to the human? What needs sign-off? What needs logging? What needs escalation? What needs weekly review?

That is where leadership starts.

Not with AI theater. With workflow honesty.

Final thoughts

The future of leadership is not human versus machine.

It is better judgment, supported by better systems.

The companies that get this right will not be the loudest ones. They will be the ones that quietly remove friction, clarify authority, improve handoffs and stop wasting experienced people on work that should have been structured better long ago.

And some of the people doing that redesign will not have “manager” in their title. They will be developers, engineers and other technical specialists who learn how to direct and review digital workers as part of their normal job.

The old manager asked, “Who owns the task?”

The stronger leader asks, “How should this system work when humans and AI share the job?”

That is the shift.

Done well, it is not the end of leadership.

It is leadership getting more serious again

Sources & further reading

This article draws mainly on a small set of current, high-signal sources on AI adoption, workflow redesign9, management change and workplace impact. McKinsey is the main anchor for the adoption-versus-value gap and the importance of workflow redesign. Microsoft is useful for the rise of “digital labor” and human-agent teams in knowledge work. Deloitte is strongest on the changing manager role and the tension between human and technological work. OECD adds a more grounded workplace lens through case studies and survey work in manufacturing and finance.

McKinsey & Company

• The state of AI in 2025: Agents, innovation, and transformation.

• The state of AI: How organizations are rewiring to capture value

• Why agents are the next frontier of generative AI

• One year of agentic AI: Six lessons from the people doing the work

Microsoft

• 2025: The year the Frontier Firm is born

Deloitte

• 2025 Global Human Capital Trends

OECD

• The impact of AI on the workplace: Evidence from OECD case studies of AI implementation

• The impact of AI on the workplace: Main findings from the OECD AI surveys of employers and workers

A note on evidence

Most of the management claims in this article are based on survey research, case studies and practitioner analysis rather than hard causal proof. That makes the argument directionally strong, but it should still be read as a practical leadership interpretation, not a law of nature.

Glossary

A lot of work doesn’t die because it’s a bad idea. It dies because someone quietly turns it into a spreadsheet-sized problem, right when it’s time to move.

Not with sabotage. Not with drama.
With a calm, reasonable-sounding “Yes, but…” that keeps growing until everyone eventually shrugs and says: “Maybe we should park this.”

That pattern has a name: avoidance through overcomplication. I call it the complexity brake, because it doesn’t crash the car. It just makes sure it never leaves the driveway.

Before we get into timeboxes and templates, let me show you what this looks like in the wild. There’s a short film that captures the entire pattern in one painfully funny scene.

A real joke from the Dark Ages (and why it hits so close to home)

Dark Ages (Finstere Zeiten) is a German short film from Badesalz1, a cult-famous comedy act from the German state of Hesse, that opens like it wants to be the most serious medieval epic ever made.

You get the full package: chaos, combat, torches, metal, mud, big dramatic energy. It sets the tone as “dark times”, the kind of story where you assume the main threat will be war, betrayal or some enemy at the gates.

And then the film pulls the rug.

Because the real threat isn’t an invading army.

It’s… a requirements discussion.

After the battle mood settles, King Arthur steps into the “new era” role. He’s got the big leadership speech, the big vision, the “we’re done with this nonsense and we’re building something better” posture. He wants to found the Round Table, a symbol of a different kind of order.

So far, this is every leadership offsite you’ve ever attended, just with more chainmail.

Then Arthur does the most normal thing a leader can do: he calls in someone to build the thing.

Enter the carpenter. A practical guy. Grounded. Confident. He’s not impressed by symbolism. He’s impressed by wood, measurements and what can go wrong if you do something “wrong.”

Arthur says he wants a round table for 25 people.

The carpenter does not say “No.”
He says “Sure.”

And then he starts doing what some people do incredibly well: he turns a simple “yes” into a slow-motion shutdown without ever openly opposing the idea.

It’s not one objection. It’s a cascade (in a thick Hessian dialect). A drip-feed of “practical” concerns that are individually reasonable and collectively lethal.

Arthur keeps trying to speak at the level of vision: what it means, what it represents, why it matters.

The carpenter keeps dragging the conversation down into gritty, exhausting detail, so relentlessly that the whole project starts to feel like a burden rather than an opportunity.

That’s where the comedy lives: the collision between myth and minutiae.

Arthur is trying to build a new society.
The carpenter is trying to “clarify the scope.”

And the carpenter’s superpower is that he makes the path forward feel endless. Each time Arthur tries to wrap it up, there’s another “one more thing,” another edge case, another condition that “we really should sort out first.”

You can watch Arthur’s energy drain. Not because he’s been defeated by a better argument (there is no decisive argument). He just gets worn down by the sheer weight of the conversation.

That’s the punchline: the king who survived war can’t survive an endless pre-flight checklist.

Eventually Arthur does what people do in real companies all the time: he disengages. He backs off. Not because it’s impossible, but because it’s become emotionally expensive. The table doesn’t happen. Not because the idea is bad, but because it’s been talked to death.

And then the film lands the extra little twist that turns it from “funny scene” into “ouch, that’s a pattern.”

A second legendary customer shows up: Robin Hood, with his own plan. And the carpenter runs the exact same routine again (immediately turning the next big idea into a swamp of “but what about…” until that customer also basically flees).

Same carpenter. Different initiative. Same outcome.

That’s the whole lesson in one medieval room:

Nobody says “no.”
They just make the “yes” so exhausting that the other side quits.

That’s the complexity brake in its purest form. Now let’s translate that into what it costs in a modern organization and what leaders can do about it.

Why leaders should care (this is not just an “efficiency” thing)

The complexity brake is expensive in a very specific way: it creates waiting.

If you’ve read my DIT piece about waiting time, you already know the punchline: customers don’t experience your internal effort. They experience how long it takes to get something real. Internally, teams experience the same thing (work sitting idle between steps, especially between decisions).

Over time, that “idle time” turns into outcomes you can feel:

• decisions get slower, so learning gets slower

• opportunities pass while you “align”

• teams get cynical (“we don’t do things here”)

• strong people leave because they’re tired of pushing air around

What this pattern is (and what it isn’t)

At its core, the complexity brake is simple: someone adds enough conditions, approvals, edge cases and “one more analyses” that action becomes socially impossible.

But it’s important to say what it isn’t, because otherwise the wrong people will use this post as a weapon.

It isn’t an argument for recklessness. It isn’t “move fast and break things.” It isn’t “stop thinking.”

Real diligence reduces uncertainty and creates a path forward.
Avoidance increases uncertainty and delays commitment.

A quick reality check, so nobody hears “speed at all costs”:

If you’re changing a safety interlock, signing an irreversible contract or doing something that could plausibly harm customers, patients or workers. You should be methodical. That’s adult supervision.

But if you’re debating a pilot, a draft or a two-week test and the room keeps inventing reasons to postpone… that’s usually not safety. That’s the brake pedal.

How it shows up in real life

You usually spot the complexity brake through timing.

Everything looks fine… until it’s time to start. Then suddenly the initiative becomes “more complex than we thought.”

It tends to show up in a handful of costumes:

Kickoff inflation. Two days before the start, new requirements appear. Not improvements. Gatekeepers.

Approval laundering. “I’m not against it, but Legal has to sign off.” “Security will never allow this.” “The CFO won’t like it.”
Notice what’s missing: someone actually talking to Legal, Security or the CFO (with a deadline).

Meeting motion without decisions. You get open questions, action items and follow-ups… and somehow no owner, no decision, no date. (If you’ve read my Meeting-Tourism piece, you’ve seen this pattern.)

Bikeshedding. The group debates easy details (wording, formatting, tooling) because the real decision is uncomfortable.

Risk as a veto. Risks are raised like stop signs, but nobody proposes a mitigation or a test.

Why people do it (and why it’s not always malicious)

Sometimes this is just human self-protection: fear of being judged, fear of being “the person who was wrong,” fear of conflict, fear of being evaluated.

Sometimes it’s overwhelm: complexity becomes a shield when someone feels out of their depth.

And sometimes it’s the system you built around them: unclear priorities, unclear decision rights, blame culture, chronic overload. In those environments, “not deciding” becomes a rational move.

This is where psychological safety matters, not as a soft topic, but because it determines whether people can say, “I’m not sure” or “Let’s test it small” without getting punished for it.

The intent question: self-protection vs. strategic stalling

Most leaders make the same mistake here: they treat every brake pedal like it’s the same.

Sometimes it’s unintentional: a smart person trying not to get burned.
Sometimes it’s intentional: complexity used to avoid ownership, avoid conflict or keep control.

You don’t need mind-reading. You need pattern-reading:

• Do they become “thorough” only when the work would put them on the hook?

• Do they slow down projects that threaten their turf, but move fast when it benefits them?

• Do they always “need alignment” but never do the aligning?

If it’s intentional, don’t solve it with more process. Solve it like a leadership issue: clarity, expectations, consequences.

When slowing down is actually the right move

Here’s the guardrail that keeps this post from being misused:

Slow down when the decision is truly hard to reverse (major capex, irreversible contract terms) or when safety/regulatory/security risk is real and immediate.

Everything else? Treat it as a two-way door. Try, learn, adjust, roll back. Most organizations waste months treating reversible choices like courtroom cases.

What leaders can do (without turning into the “just do it” cliché)

You don’t fix the complexity brake with pep talks. You fix it by changing what’s allowed in the room.

Start with this rule:

Risk only counts if it comes with a countermeasure.
If someone raises a risk, they also propose a mitigation or a test. If they can’t, it’s not a blocker yet, it’s a worry.

Then add a clock:

Timebox the debate. “We’ll discuss risks for 45 minutes. Then we choose: go, run a small test or kill it.”

Then solve the accountability problem in a healthy way:

Name one owner and protect them. Ownership is coordination, not blame. The owner’s job is to drive the next step and bring learning back. The leader’s job is to prevent ownership from turning into scapegoating.

If you want one sentence that changes the mood instantly, use this:

“If the experiment fails, I’ll own it publicly. You own the learning.”

Finally, enforce meeting hygiene:

Every meeting ends in one of three outcomes: decision, experiment or kill.
No fourth option called “great discussion.”

Two mini-templates your team can actually use

These aren’t fancy. That’s the point.

Template 1: The 2-Week Experiment Card

• Hypothesis: We believe that ____ will lead to ____.

• Smallest test (2 weeks): We will ____.

• Owner: ____.

• Success metric: We’ll measure ____.

• Stop / pivot rule: If ____ happens, we stop or change approach.

• Decision date: ____ (calendar invite sent).

Template 2: Risk → Countermeasure (one line each)

• Risk: ____

• Impact: ____

• Countermeasure / test: ____

• Owner + date: ____

If the countermeasure line stays blank, you don’t have a risk management discussion, you have a fear-sharing session.

Phrases that cut through “Yes, but…” without starting a fight

Keep these in your back pocket:

• “What’s the smallest testable version we can run in two weeks?”

• “Which assumption is blocking us? And how do we test it?”

• “Is this reversible? If yes, why aren’t we deciding today?”

• “Who owns this and what’s the next step by Friday?”

• “If we do nothing for six weeks, what does that cost us?”

• “What decision are we avoiding by debating these details?”

A modern version of the Dark Ages scene (you’ve seen this meeting)

Monday. Steering committee. A pilot is ready.

Someone says: “Before we run a pilot, we need an enterprise-wide governance model.” Then: “And a vendor bake-off.” Then: “And a complete data classification effort.” Then: “And training for every site.”

At that point, you’re not hearing diligence. You’re hearing a medieval carpenter building a career out of never cutting wood.

Here’s the clean move:

“What’s the smallest test that produces real evidence in two weeks?”
If nobody can answer, you’ve found the brake pedal.

And if the room suddenly can answer once you ask that question? Great. That means it was never truly complex. It was just emotionally expensive.

Getting Started (without overthinking it)

Pick one stuck initiative this week and run a simple reset:

Name one owner. Write “done” in one paragraph. List the top three risks (each with a mitigation or test). Timebox the debate. End with go/test/kill. If it’s “test,” create the 2-Week Experiment Card and schedule the review immediately.

That’s enough to change momentum without launching a new “program.”

Final Thoughts

Complexity isn’t the enemy. Reality is complex.

The enemy is complexity used as cover to avoid ownership, avoid conflict, avoid being evaluated or avoid the uncomfortable work of choosing.

Your job isn’t to stop questions. Your job is to make sure questions lead somewhere real: a decision, a test or an honest “no.”

And if someone keeps finding reasons not to build the table?
At some point, it’s not about wood. It’s about leadership.

Links (DIT)

• Customers don’t experience your effort. They experience waiting. (demystifyingindustrialtech.com)

• Escaping the Meeting-Tourism Trap. (demystifyingindustrialtech.com)

• Done > Perfect: Why people overdeliver and how leaders can break the cycle. (demystifyingindustrialtech.com)

• From “Permit A38” to Progress: cutting bureaucracy without losing control. (demystifyingindustrialtech.com)

• We still fear decisions, even when no one remembers why. (demystifyingindustrialtech.com)

Sources & further reading

• Dark Ages (Finstere Zeiten) is a German short film (2002), length listed as 12 minutes by FBW. (fbw-filmbewertung.com) - German

• Work aids - Dark Ages (Finstere Zeiten). (materialserver.filmwerk.de) - German

• ZEIT/dpa report on Gerd Knebel’s death (Jan 25, 2026). (DIE ZEIT) - German

• Amazon’s 2016 shareholder letter (one-way vs. two-way door decisions; decision velocity). (Amazon News) - English

• Premortem method (Gary Klein, HBR, 2007). (hbr.org) - English

Most leadership failures don’t begin with bad intentions or poor intelligence.
They begin with competence applied too automatically.

The “golden hammer” mindset describes what happens when a leader relies on an approach that has worked well before and keeps applying it, even as the nature of the problem changes. Abraham Maslow captured this tendency decades ago: when one tool dominates, everything starts to look like a nail.

This is not a flaw of weak leaders.
It is a predictable outcome of experience in positions of responsibility.

And that is exactly why it limits leadership.

This is not an argument against experience or decisive action, but for treating problem framing as a core leadership responsibility rather than a side effect.

Why this is more than a personal blind spot

Leadership is not primarily about solutions.
It is about problem framing.

Long before a decision is made, a leader has already answered a quieter, more consequential question:

What kind of situation am I in?

The golden hammer bypasses this step.
It replaces diagnosis with recognition: “I know this pattern.”

In stable environments, this works.
In changing environments, it quietly breaks judgment.

The danger is not choosing the wrong action.
The danger is never realizing that the problem itself was misunderstood.

What the Golden Hammer really changes

The golden hammer doesn’t just affect what leaders do.
It affects what they notice.

Over time, leaders begin to:

• privilege information that fits familiar explanations

• discount signals that don’t align with past success

• treat disagreement as resistance rather than insight

This is not willful ignorance. It is cognitive efficiency under pressure.

Research on decision-making shows that people responsible for outcomes favor coherent stories over incomplete ones. A clean narrative enables action. A messy reality delays it.

The golden hammer provides coherence.
But coherence is not the same as accuracy.

A concrete example (without hero myths)

Consider restructuring.

Reorganizations are legitimate tools. They can reduce friction, clarify responsibility and align incentives.

They are also attractive because they:

• are visible

• signal authority

• create the feeling of control

When results deteriorate, restructuring offers a simple explanation: “The structure was wrong.”

Yet many performance problems are not structural at their core. They arise from:

• unresolved trade-offs

• unclear decision ownership

• overload rather than misalignment

• erosion of focus or trust

A structural change cannot solve these issues on its own.
But the golden hammer makes it feel as though it can.

Movement replaces understanding.

The real leadership cost (often missed)

The deepest cost of the golden hammer is not failure.
It is premature closure.

Once a familiar solution is assumed:

• inquiry stops

• alternative interpretations disappear

• learning gives way to execution

Leadership shifts from sense-making to enforcement.

This is why experienced leaders sometimes struggle most in new contexts, not because they lack skill, but because their strongest skills narrow the field of vision.

How the Golden Hammer feels before it becomes visible

The golden hammer rarely announces itself as a mistake.
It usually shows up as relief.

There is a moment in many leadership discussions when tension drops too quickly. Agreement comes fast. The room feels aligned. Someone says, “This is clear,” and everyone nods. That moment often feels like progress.

In reality, it can be a warning sign.

Common early signals include:

• impatience with further questions

• irritation when alternative explanations are raised

• a strong urge to “move on”

• the quiet thought: “We’ve seen this before.”

None of these are wrong on their own.
But together, they often indicate that a familiar solution is being accepted before the problem has been fully understood.

The exact point where judgment slips

The golden hammer takes over at a very specific point:

When a solution creates emotional certainty before cognitive clarity exists.

At that point, the solution doesn’t just address the problem, it defines it.
From there on, evidence is filtered, discussion narrows and momentum replaces inquiry.

This is why the effect is so hard to catch.
It doesn’t feel like poor leadership. It feels like decisiveness.

When the Hammer is the right tool

This matters: the golden hammer is not always wrong.

In truly stable, well-understood situations:

• repetition creates reliability

• standard responses reduce noise

• speed matters more than learning

Organizations depend on this.

The problem begins when leaders fail to notice that the context has changed, while the organization continues to reward decisiveness, confidence and fast answers.

At that point, the golden hammer is no longer an individual bias. It becomes an organizational habit.

Experience vs. judgment

Experience is accumulated pattern recognition.
Judgment is knowing when patterns no longer apply.

The two are related, but not identical.

Good leadership requires holding them apart:

• using experience as input

• not allowing it to dictate the diagnosis

That separation is uncomfortable. It delays certainty.
But without it, experience turns into constraint.

What high-quality leadership looks like instead

Strong leaders do not abandon action.
They delay commitment, not movement.

They do three things consistently:

• They invest time in framing before fixing.
  Not endlessly, but deliberately.

• They allow competing explanations to coexist longer than feels efficient.
  Because false clarity is more dangerous than temporary ambiguity.

• They scale the size of their actions to the quality of their understanding.
  Big moves follow insight, not instinct.

This is not theory.
It is how leaders avoid locking organizations into the wrong path while still moving forward.

A common but costly misunderstanding

Leadership is often described as the ability to “have answers.”

In reality, leadership is the ability to know:

• when answers are reliable

• and when they are merely familiar

The golden hammer removes doubt.
Good leadership tolerates doubt long enough to learn.

A simple personal test

Before committing to a familiar response, experienced leaders can ask themselves one quiet question:

“Would this solution still make sense if this problem didn’t already have a familiar name?”

If the answer is unclear, the pause is doing its job.

This question does not block action.
It simply creates enough space for judgment to catch up with experience.

Getting started (without tools or frameworks)

This does not require new language or models.

Three disciplined behaviors are enough:

1. Name your default move.
   Every experienced leader has one. Acknowledge it openly.

2. Ask what would make that move inappropriate.
   If no one can answer, the discussion is already constrained.

3. Separate urgency from solution.
   Pressure may demand action. It rarely demands this specific action.

These habits do not slow leadership down.
They prevent momentum from replacing judgment.

Final thoughts

The golden hammer mindset persists because it feels responsible, decisive and efficient.

But leadership is not about applying strength.
It is about applying the right kind of strength to the situation at hand.

Sometimes the familiar tool is exactly right.
Other times, the most capable leaders pause, not because they are unsure, but because they understand that authority without diagnosis is just force.

That pause is not hesitation.
It is the discipline that turns experience into wisdom.

Further Reading

• Abraham Maslow: The psychology of science: a reconnaissance

• Gary A. Klein: Sources of Power: How People Make Decisions

• Donald A. Schon: The Reflective Practitioner: How Professionals Think In Action

• Daniel Kahneman: Thinking, Fast and Slow

• Karl E. Weick: Sensemaking in Organizations

Most teams don’t fail because they chose the “wrong agile framework”. They fail because they treat different kinds of work as if they were the same kind of work.

Cynefin1 gives you a simple way to name what you’re dealing with, so you can protect agility where it creates real value and avoid wasting it where execution is the real job.

If you’ve seen The Martian, you’ve already watched a Cynefin story.

Mark Watney survives on Mars by switching between different modes of action, depending on the kind of situation he’s in:

• When things are clear and repeatable, he follows procedures and executes carefully. No improvisation. Just discipline.

• When problems are hard but knowable, he relies on engineering judgment and careful analysis (sometimes with help from experts back on Earth).

• When things are uncertain, he runs small experiments, observes what happens and adapts based on what he learns.

• And when things suddenly go sideways, the first priority is stabilizing the situation, not debating process or running experiments.

That’s Cynefin in a nutshell: match your approach to the nature of the problem.

Most failures happen when people argue about what to do before agreeing on what kind of situation they’re actually in.

Most organizations try to run one mode for all four situations and that’s how agile gets blamed for problems it was never meant to solve.

Agile has become widely adopted and that’s a good thing.

It pulled product work away from “big plans, late surprises” and back toward users, feedback and learning. Many teams ship better software (and even better hardware) because of it.

The problem isn’t agile.

The problem is when “go agile” becomes the default answer, even when the work is mostly known and the real need is reliable execution.

That’s how you end up with agile fatigue: more meetings, more tickets, more ceremonies… and somehow less clarity.

The Cynefin framework helps you avoid that trap. It doesn’t replace agile. It helps you aim agile and it gives you permission to use other approaches when learning isn’t the bottleneck.

Before you argue about Scrum vs. Kanban vs. “our hybrid”, agree on what you’re dealing with: executing something known, designing something difficult, exploring something uncertain or stabilizing a mess.

This article is for product and engineering leaders working on:

• standard products and platforms

• customer-specific development

• software and hardware

The goal: after reading, you should be able to use Cynefin in real decisions, not just recognize the diagram.

Cynefin without the diagram

Cynefin distinguishes four domains based on how clear the relationship between cause and effect is.

• Clear – cause and effect are obvious

• Complicated – cause and effect exist, but require expertise

• Complex – cause and effect only become clear after experimentation

• Chaotic – there is no stable cause-effect relationship yet

The core idea is simple:

Different kinds of problems require different ways of deciding and managing.

Where organizations get hurt is when they apply the same logic everywhere, usually because it feels comforting.

The Lego metaphor (one toy, four worlds)

Lego2 is useful here because it strips away politics. It’s just a thing you’re trying to build.

1) Clear: Build the model from the box

You have instructions. If you follow them, you get the Millennium Falcon. If you don’t, you get a sad gray blob.

If something goes wrong, it’s usually execution, not discovery.

Typical signals:

• there is a known procedure

• quality can be checked against a specification

• mistakes are repeatable

Best approach:
Process, checklists, automation.

Agile value: limited here. Agile principles still help (visibility, collaboration), but discovery is unnecessary.

If you remember one thing: Standardize it and remove avoidable variation.

Mini-example (software): rolling out a known configuration change across environments.

Mini-example (hardware): assembling a proven module where tolerances and test steps are fixed.

Common mistake: treating routine delivery like a research problem. People debate “how” when the answer is “follow the steps”.

2) Complicated: Design a custom Lego machine

Now you want a Lego crane that lifts a specific load without tipping.

There’s no manual, but experts can design it. Analysis, simulation and review reduce risk.

Typical signals:

• experts disagree, but one can be right

• trade-offs can be explained

• analysis improves outcomes

Best approach:
Expert design, reviews, staged decisions.

Agile value: supportive. Agile helps with coordination and transparency, while expert design remains central.

If you remember one thing: Let experts design and make decisions explicit.

Mini-example (software): designing a permission model that won’t paint you into a corner.

Mini-example (hardware): thermal design for a device that must survive real-world heat.

Common mistake: confusing “hard” with “uncertain”. Complicated work can be tough and still be predictable with expertise.

3) Complex: Create a new Lego play experience

Now you’re not building a model. You’re trying to create fun.

You want kids to love it. You don’t know what will work until you try and kids won’t behave the way your slide deck expects.

Understanding emerges through experimentation.

Typical signals:

• users can’t fully articulate needs

• behavior surprises you

• early assumptions keep changing

Best approach:
Experiments, feedback, short learning cycles.

This is where agile shows its full strength.

If you remember one thing: Run small, safe-to-fail experiments to learn what’s true.

Mini-example (software): onboarding. Everyone has opinions. Only users’ behavior tells you what’s actually confusing.

Mini-example (hardware): ergonomics. A button location that looks perfect in CAD can be awkward in real hands.

Common mistake: asking for “final requirements” too early. In complex work, requirements are often the output of learning, not the input.

4) Chaotic: Lego explosion on the floor

Everything is breaking down. Pieces everywhere. Someone’s panicking. Maybe you are.

In chaos, you don’t run a workshop. You stabilize.

Best approach:
Decisive action, command, stabilization, then reflection.

Agile value: temporarily paused during chaos. Once stability is restored, agile practices help with learning and prevention.

If you remember one thing: Stabilize first, then learn.

Mini-example (software): a production outage with unknown cause.

Mini-example (hardware): a safety issue discovered in the field.

Common mistake: trying to “process” your way out of chaos while damage is still happening.

The domain most teams live in: Disorder

Cynefin is often shown with a fifth context in the center: disorder (sometimes called confusion).

That’s when people assume different domains at the same time:

• Sales treats the work as clear (“just deliver what we promised”)

• Engineering treats it as complicated (“we need design time, this has risks”)

• Product treats it as complex (“we need experiments, we don’t know what works yet”)

If you’ve ever sat in a meeting where everyone talks past each other, this is usually why.

What disorder looks like in real life

A customer asks for “a dashboard that improves decision-making”.

• Sales hears: “build dashboard A by date B”.

• Engineering hears: “unclear scope + integration risks”.

• Product hears: “we don’t know which decisions, for whom and why”.

Everyone is being reasonable (in their own domain).

Cynefin’s first practical use: force alignment on what kind of problem this is before discussing scope, estimates or commitments.

A simple question that resets the room:

“Are we executing something known, designing something hard-but-knowable or learning what ‘good’ even means?”

Why organizations misclassify problems

Misclassification is rarely a knowledge issue. It’s structural.

Common drivers:

• Planning pressure: leaders want predictability, so complexity gets simplified away

• Sales incentives: uncertainty doesn’t sell well

• Fear of accountability: calling work “complex” can hide indecision, calling it “clear” can hide risk

• Tool bias: teams squeeze problems into the method they already run

Cynefin doesn’t remove these forces, but it makes them visible. And visibility is the first step to better decisions.

Leadership looks different in each domain

This is one of the most overlooked parts of Cynefin.

Domain          Leadership Focus
------------------------------------------------------------
Clear           Enforce standards, reduce variation
Complicated     Enable experts, make informed decisions
Complex         Set direction, protect learning, remove fear
Chaotic         Act decisively, restore order

What makes this practical is the “feel” of getting it wrong:

• Complex led like clear → people hide bad news, learning slows down, you get polished updates and ugly surprises.

• Clear led like complex → endless discussion about obvious work and teams lose momentum.

• Complicated led like complex → decisions get postponed in the name of iteration and technical debt quietly piles up.

A quick gut-check for leaders:

“Do I need more control here… or more truth?”

In complex work, you usually need more truth.

What to measure (this is where teams accidentally break agile)

One reason agile turns into theater is that teams use the wrong success metrics.

Different domains require different signals.

• Clear: throughput, error rates, compliance

• Complicated: decision quality, rework, technical risk reduction

• Complex: learning velocity, hypothesis changes, decision improvements

• Chaotic: time to stabilization, damage contained

The important warning

Don’t mix these casually.

If you measure delivery output in complex discovery work, you’ll optimize for speed over learning.

That’s how you get:

• “We shipped something!” (nobody uses it)

• “We hit the sprint goal!” (the goal wasn’t the right goal)

• “Velocity went up!” (and so did the feature graveyard)

A healthier question in complex work:

“What did we learn that changed a decision”?

If the answer is “nothing”, you’re either not in complex work or you’re not doing the learning part.

Domains are not static (and that matters more than people think)

Good product work intentionally moves problems between domains.

A healthy pattern:

• start complex (discover value)

• move to complicated (design solutions)

• end clear (execute reliably)

Two failure modes show up all the time:

Failure mode 1: Staying complex forever

Teams keep “experimenting” because converging means making hard decisions.

You’ll hear:

• “We’re still validating”.

• “We need one more test”.

Sometimes that’s true. Often it’s fear.

Failure mode 2: Forcing clarity too early

Leaders demand firm plans when reality is still uncertain.

That doesn’t remove uncertainty. It just buries it.

A useful product leadership move is to say:

“This is complex for now. Our job is to make it complicated, then clear”.

That’s not anti-agile. That’s agile done with purpose.

Applying Cynefin to Standard Product Development

Software Products

Early stages are mostly complex: value, behavior, adoption.

Later stages mix domains:

• discovery remains complex (new segments, pricing, positioning)

• architecture and scaling are complicated

• operations and rollout become clear

Practical move: separate learning work from execution work.

A simple way:

• a learning lane (experiments, prototypes, discovery)

• a delivery lane (engineering execution)

If you blend them, both suffer.

Hardware Products

Hardware is often misunderstood as “non-agile”.

Reality:

• discovery and desirability are complex

• engineering trade-offs are complicated

• manufacturing execution is clear

Agility works best at interfaces:

• hardware–software integration

• user interaction

• real-world usage (where assumptions go to die)

If you want one rule of thumb:

Be agile where feedback is cheap. Be structured where changes are expensive.

Applying Cynefin to Customer-Specific Development

Customer work is where misclassification is most expensive, because promises get made early.

Truly complex customer work

Complex when:

• the customer problem is unclear

• success criteria evolve

• the solution must be discovered together

What to do:

• explicitly define a discovery phase

• time-box experiments

• agree on decision points (not feature lists)

Human wording that works:

“We can’t responsibly commit to the full solution yet. We can commit to reducing uncertainty fast and making better decisions”.

Complicated (but often mislabelled as complex)

Many customer projects are difficult but predictable.

They need:

• upfront clarification

• expert design

• structured delivery

Calling this agile doesn’t make it adaptive, it just avoids decisions.

A concrete example

Customer: “We need integration with our ERP”.

• If it’s a known interface and known data mapping → complicated (expert delivery)

• If the customer doesn’t know which processes matter or success is “less manual work somehow” → complex (co-discovery)

Same sentence. Completely different domain.

One more quick example:

• Customer: “We need a dashboard that improves decision-making”.

  • If the decisions, users and success signals are clear → complicated/clear (deliver to spec).

  • If nobody can define what “better decisions” means yet → complex (discover outcomes first).

The Highest-ROI move: split work by domain

Most real projects contain all domains.

Instead of choosing one method, split the work:

• Discovery (complex): experiments and learning goals

• Design (complicated): expert decisions and reviews

• Execution (clear): process and automation

This single step often removes months of friction because you stop treating everything like it has the same uncertainty level.

A 60-Minute Cynefin workshop you can actually run

This is simple, but it won’t be perfectly comfortable. That’s the point.

1. List major work items (10 min)

   • not tasks, real work items (“new onboarding”, “customer integration”, “new device form factor”)

2. Map each to a domain and justify placement (20 min)

   • require one sentence: “We think this is complex because…”

3. Agree on the approach per domain (15 min)

   • process vs. expertise vs. experiments vs. stabilization

4. Define success signals per domain (15 min)

   • especially for complex: “what would we learn that changes our decision?”

If people argue about classification, don’t shut it down. That argument is the value. It reveals disorder.

Common failure modes Cynefin helps prevent

• Agile unintentionally used to postpone decisions

• Detailed plans in complex uncertainty

• Treating everything as urgent chaos

• Measuring output where learning is needed

Agile doesn’t remove complexity, but Cynefin helps ensure agility is applied where it creates real value.

Getting started (without overthinking it)

• Add one slide to project kickoffs: Which domain are we in?

• Change language: delivery plan vs. learning plan

• Promise learning where certainty is impossible

• Adjust metrics to fit the domain

• Re-classify on a cadence (monthly is a good start) and immediately after any major surprise

Final thoughts

Cynefin doesn’t tell you what to do.

It helps you stop doing the wrong thing for the wrong kind of problem.

Used well, it gives leaders permission to:

• be predictable where they should

• be exploratory where they must

• and be decisive when it matters most

And sometimes, the most agile and professional statement in the room is:

“This isn’t complex. Let’s not pretend it is”.

That clarity alone can save months.

Further Reading

• Dave Snowden: the Cynefin framework (articles, talks and the original framing)

• Harvard Business Review: A Leader’s Framework for Decision Making (David J. Snowden & Mary E. Boone)

• Teresa Torres: Continuous Discovery Habits

• Marty Cagan: INSPIRED (product discovery) and EMPOWERED (product leadership)

• Eric Ries: The Lean Startup

I work for Santa.

Not in the “I wore a felt hat at the mall” way. I mean: I have an employee badge that only works if you tap it with a candy cane, I’ve sat through actual reindeer route-planning meetings and I’ve watched a grown man in red velvet calmly resolve a conflict between two toy designers who both thought their dinosaur needed more glitter.
(For the record, neither dinosaur needed more glitter.)
One of them needed fewer opinions.

So yes, this is a leadership piece.
No, there will not be a framework.

And no, I’m not saying you should run your team like a magical surveillance state (we’ll talk about The List later). I’m saying that if you strip away the folklore and look at the way Santa operates, you get a surprisingly solid blueprint for what modern leadership is supposed to look like: clear purpose, consistent values, real accountability and a culture where people can do great work without burning out or turning into jerks.
This alone eliminates about half of middle management.

Also: the snacks are elite.
The dental plan is… aspirational.
HR insists these two facts are unrelated.

Let me explain.

The North Pole has a mission people actually understand

Most organizations struggle to answer one simple question without a PowerPoint:

Why do we exist?

At the North Pole, nobody has that problem.
Mostly because Santa has a visible allergic reaction to PowerPoint.
Last time someone tried, the projector “mysteriously” froze. Forever.

Our mission is painfully clear: bring joy, deliver gifts, be kind, don’t miss Christmas Eve. In that order. Yes, this has been clarified. You can debate the ethics of a global gift monopoly, sure, but you can’t argue the mission is confusing.

That clarity matters because it makes decision-making fast. Also because arguing about priorities in December is considered a fire hazard. When you’re choosing between:

• investing in safer sleigh tech,

• adding a new line of plush dragons,

• or rewriting the cookie policy (again),

…the mission is the tie-breaker. It’s not “what makes the spreadsheet look pretty.” It’s “what helps us deliver joy well.”
Spreadsheets still exist. They are just not in charge.

Modern leadership starts with that kind of clarity. Not a poster. Not a slogan. A purpose your people can repeat without checking Slack.
Mostly because there is no Slack. There is a bell.
And you really don’t want to be the reason it rings twice.

Santa is consistent (which is rarer than you’d think)

Santa is the same person in the workshop, in a storm, in front of a camera or sitting with a nervous new elf who just glued their sleeve to a teddy bear.
That elf is doing fine now. Emotionally, I mean.
The teddy bear never fully recovered.

That consistency is a bigger deal than it sounds.
Especially to people who have worked literally anywhere else.

Because teams don’t just watch what leaders say, they watch what leaders tolerate, what they reward and what they do when they’re tired, stressed or under pressure.

Christmas Eve is pressure.
It is also very loud.
And smells faintly of ozone and panic.

And Santa doesn’t turn into a different person when the stakes go up.
Which is impressive for someone who hasn’t slept since mid-December.

The “Naughty or Nice” thing is… not what you think

Okay. We have to address it.

Yes, there’s a list. Yes, it’s checked twice. No, I can’t show you the dashboard.
Partly because it doesn’t exist. Partly because I like my job.
And partly because you wouldn’t believe the filter settings.

But here’s the part people miss: inside the organization, Santa doesn’t lead with fear. He leads with expectations.

The list isn’t a threat. It’s a standard. It’s the clearest form of “this is what good looks like” you’ll ever see.
Think less “villain monologue,” more “performance review, but shorter.”

Now, do I personally think the brand messaging could use a refresh? Absolutely. “Naughty” is a bit… 16th century.
There have been internal debates. They went nowhere.
Rebranding died somewhere between Legal and Tradition.

But the leadership lesson stands:

Good leaders make expectations explicit. Bad leaders let everyone guess, then punish them for guessing wrong.

He’s basically a Servant Leader (and it’s not just the beard)

There’s a leadership idea called servant leadership. The core notion is that a leader’s job is to serve the people doing the work, not the other way around.

Santa is that, in practice.

His entire role exists to support a massive effort carried by thousands of elves, plus a small but emotionally sensitive reindeer team. He clears obstacles. He protects the mission. He absorbs the heat when things go wrong.
Especially from Donner. Donner holds grudges.
Blitzen pretends not to, which is worse.

And here’s the part I didn’t appreciate until I’d worked elsewhere:

Santa never confuses “being in charge” with “being the point.”
This alone should disqualify at least three people you know.

That’s modern leadership in one sentence.

Psychological Safety: Yes, even in a place with candy canes for door handles

Psychological safety is when you can say,

“Hey… I think the doll’s eyes are upside down,”

without worrying you’ll be publicly roasted, frozen out or assigned to permanent stocking-stuffer duty.
Which is real and deeply boring work.
You wrap things for people who did nothing wrong.

Santa is exceptionally good at this.

When a junior elf flags an issue, Santa doesn’t punish the messenger. He says:

“Good catch. Let’s fix it.”
He does not say, “Why didn’t you catch this sooner?” which is leadership, actually.

That one habit prevents disasters and builds a culture where people speak up early, before the mistake becomes 600,000 upside-down-eyed dolls shipped worldwide.
This has never happened. Hypothetically.

A lot of leaders say they want honesty. Santa actually makes it safe.

He’s weirdly transparent for a guy who lives at the North Pole

One of the most underrated leadership skills is managing stakeholders without spinning them.

Santa does this with the entire planet.
Which is exhausting, even with magic.
Especially adults who insist they are “just asking questions.”

Whether you see NORAD tracking the sleigh as PR, tradition or a holiday miracle of customer support, the takeaway is the same:

Santa meets people where they are. He communicates in a way they trust. He makes the invisible visible.

Most leaders could improve morale by doing 5% of that.
Even 3% would help.

He protects the culture like it’s the only thing that actually matters (because it is)

Here’s a secret: the workshop runs on culture more than magic.
Magic helps, but culture survives budget cuts.

Culture is how you behave when nobody’s watching.
Which is surprisingly often. We have corners.

Santa reinforces the culture in small, consistent ways:

He credits teams, not himself.
He treats “kindness” as a performance expectation, not a poster.
He doesn’t let high performers be toxic. (Yes, even if they make excellent train sets.)
Especially if you remind everyone of this fact. Constantly.

And he never pretends curiosity is weakness.
He asks questions. Some of them are inconvenient.

The biggest misunderstanding about Santa’s leadership

All of this leads to a bigger misunderstanding…

People think Santa’s leadership is all about results: one night, impossible deadline, perfect delivery.

But the reality is the opposite.

The delivery is the output. The leadership is the system.

It’s the 11 months of training, planning, quality control, conflict resolution, morale management and making sure nobody loses their mind in late November.
December is already too late.

That’s the difference between luck and leadership.

Final thoughts from an elf with glitter in their hair

Santa’s leadership isn’t perfect. (Don’t get me started on the cookie crumbs in shared workspaces.)

Or the mugs that say “World’s Best Boss.” There are several.

But year after year, he pulls off something that most leaders only talk about.

He aligns people around a clear purpose.
He makes it safe to speak up.
He serves the mission by serving the team.
He holds standards without becoming a tyrant.
And he stays human, even when the operation is mythically huge.

Also: the man writes thank-you notes. Handwritten.
We suspect Mrs. Claus forces this. We do not ask questions.
We like our pensions.

Anyway. If you ever find yourself wondering what “good leadership” looks like, imagine this:

It’s 3:17 a.m. on December 24th. The sleigh is loaded. The weather is nasty.

A leader steps outside, looks at the team and says:

“We’ve got this. And we’re doing it together.”

That’s Santa.

Abstract

Product teams rarely fail because they lack ideas, talent or data. They fail because decisions about what to do next remain implicit, reversible or disconnected from real-world effects. Backlogs grow, priorities shift and outcomes are discussed long after decisions have already lost their meaning.

The Resonance Action Loop is a lightweight decision framework designed to address this gap. It helps teams decide how to act (not just what to prioritise) by explicitly linking evaluation, action and outcome. Instead of ranking work items, the framework forces a clear choice between learning, delivering or consciously not acting and makes every delivery decision accountable to an observable effect.

The result is not better prioritisation scores, but better decisions under real constraints.

The real problem with prioritisation

Most prioritisation methods focus on a deceptively simple question: What is more important? In practice, this leads to ranked backlogs, endless reordering and implicit commitments that nobody remembers making. Teams appear busy, yet struggle to explain why certain things were built or whether they made a difference.

What is missing is not analytical rigour, but decision clarity. Many product organisations confuse prioritisation with decision-making. Priorities are discussed, but actions are left vague. Learning happens accidentally. “No” is avoided. Outcomes are reviewed too late, if at all.

The Resonance Action Loop reframes the problem by asking a different question:

How will we act on this now and how will we know whether it worked?

This shift (from importance to action) is the foundation of the framework.

What The Resonance Action Loop is (and is not)

The Resonance Action Loop is a decision framework, not a scoring model. It does not calculate value, optimise portfolios or replace strategy. Instead, it structures judgment at the moment where teams usually struggle most: deciding what to do next under uncertainty and limited capacity.

The framework is intentionally lightweight (lightweight in structure, strict in consequences). It works in agile and non-agile environments, requires no tools and fits into existing planning and refinement rituals. At the same time, it is deliberately strict about outcomes: every meaningful decision must result in a clear action and, where appropriate, an explicit way to observe its effect.

What the framework does not do is generate ideas, define vision or remove organisational politics. It assumes that teams have real decision authority. Where that authority does not exist, the framework will expose the problem rather than hide it.

This article explains the framework and its underlying logic. For hands-on application and facilitation, complementary materials are available, including a training slide deck, a workshop guide and an evolving example library.

When the loop should be used

The Resonance Action Loop is not meant to be applied to every small decision. It is most effective when something is genuinely at stake. Teams should use the loop whenever an item competes for meaningful capacity, when there is disagreement about priority, when the expected effect is unclear or when saying “no” feels uncomfortable. These are precisely the situations where informal judgment tends to break down.

For routine, low-impact decisions, the framework can and should be skipped.

Decision authority as a prerequisite

Every application of the Resonance Action Loop requires a Decision Owner. This role is not about facilitation or consensus, but about accountability. The Decision Owner listens to the discussion, weighs the trade-offs and makes the final call once the evaluation is complete.

Disagreement is encouraged before the decision. After the decision, the call stands. Without this clarity, learning turns into delay, delivery becomes implicit and “no” becomes political. In practice, many failed prioritisation processes can be traced back to the absence of clear decision ownership.

The core idea: separating evaluation from action

The framework is built on a simple but often neglected insight: product decisions differ less by their abstract “value” than by the kind of effect they are meant to create and by how ready the organisation is to act on them.

For this reason, the Resonance Action Loop separates evaluation from action. Evaluation is about understanding what an item could achieve and how confident the team is about that assessment. Action is about deciding what to do next, given that understanding. Conflating the two leads to endless debate, separating them creates clarity.

Evaluating decisions through four shared questions

Every item (whether a feature, improvement, technical task or experiment) is evaluated using the same four questions, always in the same order.

First, the team clarifies the Intended Effect. Each decision must have one primary effect: improving Reliability by avoiding disappointment, creating Usage Lift by changing behaviour or adoption, strengthening Positioning by signalling what the product stands for or achieving Load Reduction by reducing friction for users or the team. If the team cannot agree on a single intended effect, the item is not ready for decision and should be parked.

Next, the team assesses Pull Strength by asking how painful it would be not to act. For user-facing work, this may be driven by unmet expectations or visible friction. For internal or technical work, pull reflects accumulated risk, inefficiency or cost of delay. Pull is about felt pressure, not certainty.

The third dimension is Evidence Level. This describes how well the assumed effect is supported: whether it is merely an assumption, plausibly observed or proven through data or real behaviour. Evidence level is not confidence or conviction, it is a statement about the strength of the underlying basis for the decision.

Finally, the team estimates Delivery Cost, including effort, risk and dependencies. Engineering input comes first and teams anchor their estimates around a shared understanding of what constitutes a “typical” delivery. Once delivery cost is discussed, the evaluation is considered locked (locked for this decision cycle, not forever) to prevent endless backtracking.

Examples:

You can find the decision resulting from the evaluation in the Example Library (in the download area at the end of the article).

From evaluation to action: the decisive moment

After evaluation, the team must make an explicit choice about action. The Resonance Action Loop allows exactly three outcomes: Learn, Deliver or Explicit No. There is no “later” and no “maybe”. Choosing an action is the decision.

This is where the framework differs most clearly from traditional prioritisation approaches.

Learning as a first-class decision

Choosing Learn means investing deliberately in reducing uncertainty rather than in producing output. Learning is the default when evidence is weak (unless the Decision Owner explicitly accepts the risk), when the effect is promising but unclear or when delivery cost is high relative to certainty.

To prevent learning from becoming a parking lot, every Learn decision must define a clear learning question, the smallest possible test, the kind of evidence sought and a concrete decision date. Learning always ends in a new decision. If learning does not increase evidence or pull, the default next step is to consciously stop pursuing the item.

This makes learning accountable without making it defensive.

Delivery as a commitment to effect

Choosing Deliver means committing to creating a specific effect. Delivery is appropriate when evidence is sufficient or when uncertainty is explicitly accepted by the Decision Owner.

Every delivery decision must define an Outcome Check. This consists of a simple expected outcome statement, a signal to observe and a time window for observation. The goal is not to set targets or prove success, but to establish a clear link between decision and observable reality.

After the observation window, the team reviews what happened. If the signal moved as expected, the decision is complete (operationally complete, not theoretically settled). If the signal is unclear or negative, the next step is either learning or stopping. Outcome signals indicate correlation, not proof. When causality is uncertain, learning is the appropriate response.

Delivery does not close the loop. Observation does.

Explicit No as a deliberate outcome

Choosing Explicit No means consciously deciding not to act. This decision always comes with a reason: not now, not worth it or wrong effect. Each reason includes a clear re-entry rule, ensuring that “no” is firm without being dogmatic.

By formalising “no” as an outcome, the framework reduces repeated debates, hidden commitments and political re-litigation.

Focus, trade-offs and political reality

To maintain coherence over time, teams define a Decision Focus at the start of a planning period. This focus guides capacity allocation without becoming a rigid goal. Most committed capacity should align with it, but exceptions are allowed when explicitly justified.

When two items both qualify for delivery, the framework resolves the tie by favouring alignment with the current focus, lower delivery cost or faster outcome feedback -without introducing additional scoring.

The framework also acknowledges political reality. Some work is mandated. Such items are marked as Forced Deliver (Forced Deliver does not imply endorsement, only acknowledgement) outside the loop. They still require an intended effect and an outcome check, but bypass learning discussions. This keeps the framework honest without pretending that all decisions are optional.

Closing the loop

An item exits the Resonance Action Loop when its delivery outcome is confirmed, when an explicit no is final or when the underlying problem no longer exists. Habitual re-triage without new information is avoided.

Used consistently, the loop creates a shared decision language that connects thinking, action and learning.

Limitations by design

The Resonance Action Loop does not generate ideas, replace discovery or eliminate politics. It requires real decision authority and disciplined moderation. Where these conditions are absent, the framework will feel uncomfortable and that discomfort is often diagnostic.

Conclusion

The Resonance Action Loop is not about ranking work.
It is about deciding how to act and taking responsibility for the effect.

By making uncertainty explicit, separating evaluation from action and tying delivery to observable outcomes, the framework turns prioritisation from an abstract debate into a concrete learning system. This is not prioritisation as ranking, but capacity allocation through explicit decisions.

A decision without an action and an outcome check is not a decision. It is a delay.

That is the standard the Resonance Action Loop enforces and the reason it works.

The following section provides calibration heuristics and worked examples. For facilitation-ready formats, additional practice material is available, including a dedicated training slide deck, a workshop guide and a curated example library.

Evaluating decisions: examples and ranges that actually help

The Resonance Action Loop deliberately avoids precise scoring.
Still, teams need shared reference points. The following ranges and examples are heuristics, not rules. Their purpose is alignment, not accuracy.

Intended Effect - with concrete examples

Each decision must have one primary intended effect.

Reliability

Avoiding disappointment and broken expectations

Typical examples

• Fixing login failures or data loss bugs

• Improving performance where users already complain

• Security, compliance, uptime, billing correctness

Typical smell

“Nobody complains yet, but this might break one day.”

→ Often not Reliability, but Load Reduction.

Usage Lift

Increasing meaningful usage or adoption

Typical examples

• Improving onboarding completion

• Reducing friction in a critical flow

• Making a key feature easier to discover

Non-examples

• Cosmetic UI changes without behavioural intent

• “This would be nice” improvements

Heuristic check

“Would this measurably change how often or how deeply users use the product?”

Positioning

Signalling what the product stands for

Typical examples

• Launching a flagship capability

• Supporting a strategic integration or platform bet

• Capabilities used in demos, sales narratives or announcements

Common mistake

Treating internal cleanup as Positioning because it feels important.

Positioning is outward-facing, even when internally motivated.

Load Reduction

Reducing friction, complexity or risk for users or the team

Typical examples

• Paying down recurring tech debt

• Removing manual operational steps

• Simplifying configuration or workflows

Heuristic

“Would this make future work or usage consistently cheaper?”

Pull Strength: ranges with examples (1-5)

Pull Strength answers:
How painful would it be if we don’t act?

Pull     Typical meaning      Example
--------------------------------------------------------
1        Barely noticeable    Minor UX polish
2        Mild irritation      Known workaround exists
3        Clear annoyance      Repeated support questions
4        Strong pain          Drop-offs, escalations
5        Acute / urgent       Revenue loss, trust damage

Internal work note
For tech or platform items, Pull reflects:

• accumulated risk

• repeated friction

• growing operational cost

Not “how much engineers want it”.

Evidence Level: what 0.5 / 1.0 / 1.5 actually mean

Evidence Level describes what the decision is based on, not how convinced someone feels.

Level      Meaning       Typical evidence
----------------------------------------------------
0.5        Assumption    Opinions, intuition
1.0        Observed      Logs, tickets, interviews
1.5        Proven        Experiments, real behaviour

Example

• “Users drop off here” → 1.0

• “We ran an A/B test and saw +8% completion” → 1.5

Important
Deliver with Evidence < 1.0 is allowed only with explicit risk acceptance.

Delivery Cost: anchoring the 1-5 range

Delivery Cost includes effort, risk and dependencies.

Each team defines its own anchor. A typical pattern:

Cost          Rough meaning
----------------------------------------
1             Trivial / config change
2             Small change, few days
3             Typical delivery effort
4             Multi-sprint, dependencies
5             Large, risky, cross-team

Rule of thumb
If teams argue about 2 vs 3, it’s probably a 3.
Precision here adds little value.

From evaluation to action - worked examples

Example 1: Login instability

• Intended Effect: Reliability

• Pull Strength: 5 (users locked out)

• Evidence Level: 1.5 (error logs, tickets)

• Delivery Cost: 2

→ Deliver

Outcome Check

• Expected outcome: “Fewer login failures.”

• Signal: error rate, support tickets

• Observation window: 1 week

Example 2: AI-powered insights idea

• Intended Effect: Positioning

• Pull Strength: 3

• Evidence Level: 0.5

• Delivery Cost: 5

→ Learn

Learning question

• “Do users actually trust and use AI insights?”

Smallest test

• Prototype + interviews

Example 3: Refactor legacy export pipeline

• Intended Effect: Load Reduction

• Pull Strength: 4 (frequent incidents)

• Evidence Level: 1.0

• Delivery Cost: 4

→ Deliver (often justified despite invisibility)

Example 4: Feature request from one large customer

• Intended Effect: Usage Lift

• Pull Strength: 2

• Evidence Level: 1.0

• Delivery Cost: 3

→ Explicit No (Not worth it)

Reason:

• High cost, limited systemic effect.

Learn vs Deliver: common boundary cases

Good candidates for Learn

• Pull ≥ 3, Evidence ≤ 0.5

• Delivery Cost ≥ 4 with unclear upside

• Strategic ideas without behavioural proof

Good candidates for Deliver

• Evidence ≥ 1.0 and Pull ≥ 3

• Reliability items with clear risk

• Load Reduction with recurring cost

Outcome Checks: realistic examples

Intended Effect     Expected outcome         Signal
-----------------------------------------------------------------
Reliability         Fewer failed actions     Error rate
Usage Lift          More completed flows     Funnel completion
Positioning         Feature used in demos    Sales feedback
Load Reduction      Less manual work         Ops time / incidents

Reminder
Outcome signals indicate correlation.
If causality is unclear → Learn, not debate.

Decision Focus: example application

Quarter focus: Reliability

• 65% capacity → bug fixes, performance

• 20% → necessary Load Reduction

• 15% → forced or exceptional items

A Usage Lift feature may still ship, but it must justify breaking focus.

Why ranges matter (and why they are loose)

The purpose of ranges is not optimisation.
It is shared intuition.

If two teams score differently but decide the same action, the framework worked.

Final takeaway

The Resonance Action Loop becomes usable not through formulas, but through examples that calibrate judgement.

Once teams internalise these ranges, the framework fades into the background—and decisions become clearer, faster and more honest.

Good frameworks disappear in use.

Supporting materials

To support adoption and consistent use, the Resonance Action Loop is accompanied by three practical resources: a training slide deck that introduces the framework and its decision logic, a workshop guide that provides a step-by-step structure for facilitation and group decision-making and an example library that documents real and worked-through decisions for calibration and reference. These materials are designed to complement the framework, not replace it.

The Resonance Action Loop Training

5.53MB ∙ PDF file

Download

Download

The Resonance Action Loop Workshop

259KB ∙ PDF file

Download

Download

The Resonance Action Loop Example Library

269KB ∙ PDF file

Download

Download

In Spider-Man 2, Peter Parker isn’t portrayed as slow, lazy or incapable.
He’s portrayed as overloaded.

He’s trying to live two lives at once. Student, friend, tenant, employee and Spider-Man. Every role matters. Every responsibility feels urgent. Nothing is trivial.

And yet, the outcome is predictable: missed commitments, late arrivals, strained relationships. Not because he doesn’t care, but because everything is active at the same time.

The film never frames this as a character flaw.
It’s a capacity problem.

Most of us recognize that feeling (minus the suit).

What this is about

That tension between effort and outcome is exactly what this article is about.

Full utilization1 means trying to keep people busy close to 100% of the time.

It sounds responsible.
It looks efficient in planning meetings.
It feels like control.

In many kinds of modern work, it quietly produces the opposite: long delays, missed commitments and a constant sense of urgency without real movement.

This isn’t about motivation or work ethic.
It’s about what happens when too much work is open at the same time.

Why this matters

Once work stops flowing smoothly, effort alone is no longer enough.

Organizations don’t succeed or fail on effort alone.
They succeed or fail on flow2.

On things like:

• how long it takes for work to reach the market

• whether dates and promises mean anything

• how fast the organization can respond when reality interrupts the plan

Somewhere between planning meetings and delivery dates, many organizations lose sight of something simple:

Customers don’t see your internal effort.
They experience waiting.

Time to market, response time, reliability - these aren’t separate problems.
They’re different expressions of how long work sits unfinished inside the system.

Yet many organizations quietly optimize for something else: making sure everyone is busy.

That’s where the tension begins.

A system can look full and still move slowly.
Sometimes because it’s full.

Where improvement efforts often miss the point

This is where many well-intentioned improvement programs quietly go wrong.

They look at activity, not time.

Most lead time isn’t spent on actual work.
It’s spent waiting.

Waiting for decisions.
Waiting for handoffs.
Waiting for capacity.
Waiting for “the right moment.”

From the customer’s perspective, these waiting and idle times are the product experience.

That’s why improving overall lead time rarely starts with making individual steps more efficient.
It starts with reducing how long work sits untouched in between.

Fewer open items.
Less parallel work.
Faster handoffs.

Not just faster execution.

You can perfect every step and still disappoint customers
if most of the time is lost between them.

A useful way to think about it (not a perfect one)

At this point, it helps to step back and look at the system as a whole.

There’s a simple relationship that shows up almost everywhere work moves through a system:

Lead Time3 = Work in Progress4 ÷ Throughput5

It’s known as Little’s Law6.
No ideology attached. Just math.

Most real work doesn’t move through neat production lines. Tasks aren’t identical. Conditions change while the work is underway.

So no, this isn’t a literal model of how people work day to day.

But as a thinking lens, it reveals something that’s easy to miss when everyone is busy:

The more unfinished work you allow into the system, the longer it takes for anything to reach the customer.

This is the part that often surprises people.

If throughput stays roughly the same, there are only two ways lead time can change:
you either finish work faster or you carry less unfinished work at the same time.

Most organizations instinctively focus on the first.
Little’s Law explains why the second is often more powerful.

Urgency doesn’t change that.
Pressure doesn’t either.

Little’s Law doesn’t tell you where time is lost.
It tells you why it accumulates.

A concrete example: embedded hardware and firmware

This can still sound abstract, so let’s make it tangible.

Take a fairly typical embedded product: a custom PCB, an enclosure, a few sensors, connectivity and the firmware to hold it all together. Nothing exotic. No moonshot technology.

From an approved idea to market launch, a realistic time to market for this kind of product is around 18 months.

Not because engineers are slow.
But because the work has to move through builds, tests, iterations, suppliers and external constraints.

When you look closely, those 18 months break down unevenly.

Actual working time: roughly 6 months
Designing hardware, writing firmware, bringing up boards, debugging, testing, fixing, integrating.

Waiting and idle time: roughly 12 months
Waiting for parts.
Waiting for build slots.
Waiting between EVT, DVT and PVT.
Waiting for test results, approvals, lab availability, supplier lead times and manufacturing readiness.

That imbalance is not unusual. In complex hardware–software development, a large share of total lead time is spent not working, but waiting.

Now look at what happens when you pull different improvement levers.

Improving efficiency

Assume you do everything right internally.

Better tools.
Cleaner architectures.
More reuse.
Fewer defects.

You manage to reduce actual working time by one full month (from 6 months down to 5).

That’s a real achievement.

But the customer-visible result is modest:

• Original time to market: 18 months

• After efficiency improvements: 17 months

Internally, it feels faster.
Externally, almost nothing changes.

Reducing waiting time

Now pull a different lever.

You reduce the time work spends sitting idle between steps:

• fewer parallel initiatives competing for the same labs and decision-makers

• clearer prioritization between hardware and firmware work

• faster decisions between builds

• earlier supplier and part choices to avoid blocked builds

None of this makes engineers work harder.
It simply reduces how long work waits to be picked up again.

If you cut waiting time by four months (from 12 down to 8) the picture changes dramatically:

• Original time to market: 18 months

• After reducing waiting: 14 months

Same teams.
Same skills.
Same effort.

But the market sees the difference immediately.

When waiting dominates lead time, efficiency improvements feel good internally,
but only waiting reduction shows up on the launch date.

You’ve probably seen this play out

Once you see this pattern, it’s hard to unsee.

A project that’s “almost done.”
A decision that just needs one more alignment.
A release that slips by another week (again).

Imagine a team that can realistically complete about ten meaningful outcomes per week.

With thirty items in progress, things feel manageable.

Then more work gets started.
Nothing dramatic. Just “one more priority.”

Soon there are sixty items in the system.

Quality doesn’t suddenly collapse.
People don’t stop caring.

But time to market stretches.
Customers wait longer.
Feedback arrives later.

The queue grows and so does frustration.

“But shouldn’t focus increase throughput?”

In theory, yes.

In practice, throughput in knowledge-heavy work is often capped by things that don’t show up on a plan or org chart:

• limited attention.

• coordination overhead.

• context switching.

• dependence on other people’s availability.

Once days are broken into fragments, adding more parallel work rarely speeds things up.
It usually slows them down.

That’s the quiet risk of loading the system: you’re betting on capacity that may never appear, while customers keep waiting.

Why it feels fine… until it doesn’t

For a while, high utilization feels productive.

Little’s Law explains why more open work leads to longer lead times.

What it doesn’t explain, on its own, is how suddenly things can fall apart.

That comes from variability7.

Real work is uneven by nature:

• some tasks are quick, others messy.

• work arrives in waves.

• priorities shift mid-stream.

When utilization is moderate, systems absorb that variability.
When utilization is high, there’s nowhere for it to go.

So it shows up as waiting.

“But some industries run at very high utilization”

They do (under very specific conditions).

High utilization works best when work is standardized, predictable and heavily buffered.

Airlines, call centers and capital-intensive operations build those buffers deliberately. Waiting is visible and often priced in.

Most modern organizational work doesn’t have those properties.

Here, waiting doesn’t look like a queue.
It looks like stalled projects, delayed releases and work that is “almost done” for weeks.

Applying the same utilization logic without the same buffers usually backfires.

The misunderstanding that won’t go away

“Idle time is waste.”

It sounds sensible.
It’s also misleading.

Slack8 isn’t about comfort or perks.
It’s what allows a system to stay stable when reality refuses to cooperate.

Remove it and variability turns directly into delay and delay is what customers feel.

What over-utilization looks like up close

You don’t need formulas to recognize it.

• everything is urgent

• simple tasks wait for “the right moment”

• planned work gets displaced by the latest escalation

• projects start easily and finish painfully

• people are busy, yet outcomes arrive late

These aren’t motivation problems.
They’re system signals.

What actually helps

Once you see the system, the response becomes clearer.

This isn’t about doing less.
It’s about doing fewer things at the same time.

In practice:

• limit what counts as active.

• finish before starting more.

• make queues visible.

• protect slack deliberately.

• pay attention to time, not just effort.

If everything is urgent, nothing flows and nothing reaches the customer quickly.

Getting started (without overthinking it)

Try this for two weeks.

1. List what’s actively in motion

2. Notice what’s actually moving

3. Pause the rest (explicitly)

4. Watch one signal: time to market (or time to completion)

If things start reaching customers faster, nothing magical happened.

You changed the shape of the system.

Final thoughts

Full utilization feels responsible.
In many kinds of work, it’s a slow-motion failure mode.

This isn’t an argument for lower ambition or excess capacity.
It’s an argument for respecting how work behaves under load.

Peter Parker didn’t become faster by trying harder.
He became faster by letting go of one life (temporarily) so the other could work.

Customers don’t experience your utilization.
They experience your waiting time9.

If your organization feels busy but slow, don’t ask people to push harder.

Ask something more uncomfortable:

What are we starting that we don’t need to start yet?

This doesn’t explain everything that slows organizations down, but it explains one of the most common and least discussed, ones.

Further Reading

• John D. C. Little - A Proof for the Queuing Formula L = λW

• Wallace J. Hopp & Mark L. Spearman - Factory Physics

• Donald G. Reinertsen - The Principles of Product Development Flow

• Eliyahu M. Goldratt - The Goal

• Taiichi Ohno - Toyota Production System

Glossary

In Minority Report (2002), a futuristic police unit stops crimes before they occur. Their results are nearly perfect. But public trust begins to erode. If no crimes happen, how can people be sure the system works? How do you justify the cost of something that prevents the invisible?

That’s the paradox of prevention.

Whether it’s crime, crisis or collapse - when things go right because someone acted early, the success is silent. And when we can’t see what was avoided, we start to question whether there was ever a threat at all.

This isn’t just science fiction. It’s how we often judge leadership, planning and risk.

The paradox of prevention.

Even if the crew of the Titanic had managed to bring her to New York despite the collision, some would still have complained about the delay.
- Thomas Rauch

This quote captures something deeply human: we tend to celebrate visible wins and overlook what was quietly prevented. It’s a bias that shapes how we judge leaders, teams, outcomes and even history.

This article takes a deeper look: Why do we overvalue what’s visible and undervalue what’s prevented? What psychological forces drive this? And how can we shift our perception to give prevention the credit it deserves?

Why it matters

Many of the most important achievements in leadership, risk management and everyday life are invisible.

• The crisis that didn’t spiral.

• The outage that never happened.

• The team that stayed calm when others would have panicked.

If we don’t learn to see these quiet wins, we risk rewarding recklessness and overlooking true foresight.

The Psychology behind it

Several well-documented cognitive biases explain why we underrate what’s prevented:

1. Outcome Bias

We tend to judge decisions by their results, not by the quality of the decision-making process. If a risky move pays off, we call it smart. If a cautious move avoids disaster, we call it lucky.

It’s like praising the driver who runs a red light and doesn’t crash and ignoring the one who stops safely.

Well-known work by Baron & Hershey (1988, Outcome Bias1 in Decision Evaluation) illustrates how people favor outcome over process, even in morally significant decisions.

2. Preparedness Paradox

When prevention works well, people believe the threat was exaggerated. This paradox shows up in public health, disaster planning and cybersecurity: success looks like overreaction.

• Flood defenses that seemed like overengineering, until the storm came and damage was minimal.

• A company invested heavily in routine patch management and zero-day monitoring and was later criticized for “overspending on threats that never materialized.” But nothing materialized precisely because they were ready.

• Y2K preparedness avoided major disruptions and was later criticized as “overblown.”

3. Survivorship Bias

We focus on the visible winners and forget the failures that were quietly avoided. A classic example: studying successful companies without analyzing the ones that failed due to poor risk management.

4. Availability Heuristic

We judge importance by what’s most noticeable. A major success story is easier to remember than a slow, stable year with no drama. Visibility beats subtlety.

5. Reward Structures

In many organizations, incentives are tied to visible outcomes: launches, sales, growth. There’s rarely a bonus for the risk you mitigated or the fire that never started.

Bazerman & Tenbrunsel’s behavioral‑ethics research shows that incentive and goal‑structures often push organizations to focus on visible results, sometimes at the expense of careful, ethically sound decisions. In many cases we end up rewarding success, not robustness.

How this plays out in practice

• A product manager cancels a feature that would have introduced serious complexity. No applause.

• A security lead fixes a vulnerability before it’s exploited. No headlines.

• A CEO maintains team morale during a downturn and avoids layoffs. No press release.

Prevention doesn’t feel like progress. But it often is the progress.

Additional real-world examples

• Healthcare: Vaccination campaigns that prevent outbreaks are often questioned because the crisis never comes.

• Infrastructure: Engineers who maintain bridges and prevent collapses are rarely featured in annual reports.

• IT & Cybersecurity: Quietly patching vulnerabilities and maintaining backups prevents chaos and earns silence.

• Manufacturing: A team in a mid-sized factory flagged an abnormal motor temperature. A preventive shutdown avoided a three-day outage, saving €250,000. The success was invisible. The failure would’ve been very public.

What to do differently

To rebalance our judgment and incentives, we need to:

1. Ask: What didn’t happen and why?

After every project or quarter, reflect not just on wins, but on disasters avoided.

2. Make the invisible visible

Talk about stability. Celebrate the calm. Publicly recognize teams that averted problems.

How to recognize quiet wins

• “You flagged this early - thanks.”

• “We avoided escalation - great judgment.”

• “This didn’t make noise - because you handled it well.”

• “Because of your calm prep, this stayed simple.”

3. Value process over luck

Highlight decisions that were made with care, even if the outcome was neutral. Encourage teams to document how they thought through risk, not just what they shipped.

4. Incentivize Risk Awareness

Reward teams who identify vulnerabilities early. Build a culture where flagging concerns is seen as a strength.

Measuring Prevention (without gaming it)

• Number of critical issues de-escalated early

• Volume of resolved “Almost Problems”

• Participation in risk workshops / pre-mortems

• Time to response on weak signals

• Clean audit results / zero critical escalations

Use Pre-Mortems2: As Gary Klein suggests, imagine a future failure and work backward to ask what might cause it. Then act early.

5. Develop a dual lens

Measure success in two ways:

• What moved forward?

• What didn’t go wrong and why?

Leadership Tip: Add a “Near Miss3” column to retrospectives. Ask: “Where did we actively avoid risk this week/month?”

Micro-Ritual: Friday 15 Minutes: each team member notes one silent success4 of the week.

The big misunderstanding

People often think leadership is about bold moves and big calls. But real leadership, especially in uncertainty, often means reducing noise, focusing attention and keeping the team on course.

That doesn’t make for dramatic headlines. But it’s often the reason you’re still afloat.

Misjudgment Case: The Challenger Disaster
Engineers at contractor Morton Thiokol warned NASA leadership about the risk of O‑ring failure in cold temperatures before the launch. Despite that (and previous missions showing signs of O‑ring erosion) the launch went ahead. The shuttle broke apart 73 seconds after liftoff. The tragedy exposed how a known, repeatedly documented danger can be dismissed, especially when past successes masked how real the risk actually was.

Getting started (without overthinking it)

Two simple habits can shift the culture:

1. In reviews, always ask: “What did we avoid?”

2. When recognizing people, say: “Thank you for keeping things from going off the rails.”

Also useful:

• Create “Almost Problems” logs5: Document risks identified and neutralized.

• Add a “Prevention Lens” to retrospectives: What didn’t escalate? What did we catch early?

• Include “silent success stories” in town halls or internal newsletters.

For the very precise among us

• “This is too theoretical.”
  Clarification: Prevention is hard to measure, but the article offers practical tools, examples and leadership prompts to make it actionable.

• “You can’t reward things that didn’t happen.”
  Clarification: True, we should reward the process that prevented harm, not the absence of a result. Clarity, foresight and calm under pressure matter.

• “Nice idea, but hard to apply.”
  Clarification: That’s why we suggest small shifts, like adding a prevention lens to reviews or logging almost-problems. Culture change starts with habit change.

• “Results still matter more than intentions.”
  Clarification: Absolutely, but robust processes prevent bad outcomes. Long-term health depends on resilience, not just performance.

• “This excuses mediocrity.”
  Clarification: Quite the opposite. It highlights high-quality, thoughtful work that often goes unseen. Quiet excellence deserves recognition.

Final Thoughts

We tend to overestimate what we can see and underestimate what we’ve been spared. But real progress is both:

• Building the right things

• And protecting them from the wrong outcomes

We judge more wisely when we recognize not only what is present, but what was prevented - allowing real progress to shine beyond the imperfections that remain.

Let’s give prevention the credit it deserves.

Further Reading & References

• Baron, J. & Hershey, J. (1988). “Outcome Bias in Decision Evaluation.”

• Kahneman, D. (2011). “Thinking, Fast and Slow”.

• Bazerman, M. & Tenbrunsel, A. (2011). “Ethical Breakdowns”

• Klein, G. (2007). “Performing a Project Premortem”

• “The Preparedness Paradox” Wikipedia

Glossary

Introduction: The Iron Man Problem

In The Avengers (2012), Tony Stark (Iron Man) is the genius inventor, charismatic leader, the “go-to guy” when things explode. He pulls off miracles, solves crises, gets the applause. On screen it’s thrilling.

But imagine if your organisation ran like that movie, except instead of safe exits and credits rolling, you face real-life absence, turnover, disruption. What happens when Stark is off mission… and no one else knows how to suit up? That’s the business risk of a hero-dependant system.

This isn’t about knocking high-performers. It’s about seeing that when everything depends on one person’s presence, decisions, knowledge and relationships, you don’t have a system. You have a bottleneck. The moment they’re unavailable, everything hangs.

Why this matters

Here’s why the “hero model” matters and why it’s risky:

• Organisations where one specialist or leader is the linchpin become fragile. When they’re unavailable, things stop. This is often described as a “single point of failure1”.

• In high-change, high-complexity environments (digital transformation, growth, disruption) speed matters. And speed often leads to relying on the one who can do it fastest, reinforcing hero dependency rather than building robustness.

• Many companies reward hero behaviour: the fast fix, the person who “saved the day”, rather than the person who built the process to prevent the day needing saving. That tilts the culture toward heroism, not team resilience.

• Hidden risk: the metrics often hide the dependency. Dashboards show outputs, not “how sustainable was the result if person X was unavailable?” So the vulnerability remains invisible until absence, turnover or crisis exposes it.

In short: The hero model looks like efficiency. It feels like strength. But what you’re really building is fragility with a nice veneer.

Where hero culture comes from and what the research says

Let’s dig into why organisations drift into hero culture. It’s not just “bad leadership” or “lazy teams”, there are rooted patterns and cognitive, structural forces at play.

Cognitive and social roots

• Humans prefer simple stories. We love clear protagonists, clear outcomes. We have a bias called the fundamental attribution error2, where we attribute success to individuals rather than context or systems. So when something went well, we say “X pulled through”, not “the system held up”.

• The “hero narrative” is deeply embedded in our culture (see myth-theory, heroism studies).

• Organisations amplify this: If someone always steps in, is visible, has results, they get praised and the pattern becomes normalised, even if it’s structurally unsafe.

Organisational and structural enablers

• Reward systems often emphasise individual performance over team process. For example, bonuses for “sold this deal” rather than “we built a process so this deal won’t need firefighting next time”.

• Visibility bias3: The hero crisis, the late-night fix, the urgent call,… these are visible. Meanwhile, the steady work of mentoring, documenting, cross-training is invisible and un-celebrated.

• Growth & complexity push organisations into hero mode: A start-up needs “heroes” to move fast and create new solutions. But if that model persists into scaled operations without process, you have a company built around its heroes rather than its systems.

• Silo and “tribal knowledge4” effects: One person holds unique knowledge, others cannot access it, knowledge hoards. A recent review found a correlation between hero-cultures5 and silo mentalities: “Hero-silos” where the hero keeps the knowledge to themselves, weakening cross-team collaboration.

Tribal knowledge (undocumented expertise held by one person) becomes a silent risk factor.

Empirical research findings

• A 2022 study in Frontiers in Psychology (Lisak et al.) found that teams with high interdependence rely less on heroic or directive leadership.

• A large-scale analysis of open-source projects (Agrawal et al., 2017) showed that while “hero developers” drive short-term speed, they reduce long-term resilience.

• And a 2023 systematic review (Molek et al.) found that hero cultures often correlate with weaker collaboration and knowledge sharing across teams

What we see: Hero culture is not about “bad people”, it’s about structural patterns, incentives, psychology. Acknowledging it is the first step to changing it.

How hero culture sneaks in

We’ve introduced the concept, now let’s observe how it actually takes root in organisations (often subtly).

• The “go-to person”: A specialist who knows everything, becomes the default.

• The “rescue mode”: When things go off track, the hero is tapped. Others see it as normal that only one person can fix things.

• The “knowledge moat”: Documentation may be poor, backups sparse, colleagues kept at arm’s length.

• The “reward loop”: Successful crisis handled by hero → praise, promotion → more crisis handled by hero → culture reinforces this pattern.

• The “growth trap”: As business scales, if you don’t build the next layer, the hero load increases, leaving no capacity for mentoring, hand-over, system building.

Example: A senior engineer is the only one who can deploy a critical platform. No documentation, automation or backups. He goes on leave. Ten people are stuck waiting. That is not expertise, that is exposure.

But the risks go further:

• Innovation slows when only one voice dominates. Others don’t experiment.

• Team morale drops when others feel “not needed” or ″just backup”.

• Burn-out risk for the hero who’s always called in. Knowledge hoarded, no rest.

• Culture signals: The message becomes “heroes save us”, not “we solve together”. That creates deeper dependency.

Knowledge silos6, when critical information stays locked inside one team or person, make this even worse.

Recognising the hidden bottlenecks

Hero culture isn’t always loud. Often it hides in silent dependencies. Here are fewer-noticed signals:

• One person manages critical customer or vendor relationships alone (no deputy).

• Key decisions always route through a single manager, others rarely decide.

• Knowledge lives in heads, not documented. Hand-over takes weeks.

• Audit trails show most contributions from one person, others are peripheral.

• Emergent “urgent fixes” dominate calendar, preventive work is rare.

• Metrics like “time to cover absence of key person” are long or undefined.

• When the hero is absent, there is no plan B. Projects stop.

If you have to ask who would step in when ‑X‑ is gone, you already have a single point of failure.

What leaders should actually do

We now move into the practical-action zone. These steps help you transition from hero-dependence to resilience7 while retaining high performers.

1. Audit your dependencies

• Asking “if person X disappeared tomorrow, what breaks?” is powerful.

• Map key processes, decisions, customer relationships, vendor links, documentation gaps.

• For each process: Who knows it? Who can step in? How long would ramp-up take?

• Use the concept of Single Point of Failure (SPOF) and list them.

2. Structure knowledge flow

• Introduce the “two-know rule8”: Every critical task must be understood by at least two people.

• Rotate “knowledge-sharing” sessions: Tiny regular slots where team-members present what they know, how they do it, what decisions they make, what dependencies exist.

• Make documentation part of the target (not optional).

• Encourage peer-reviews, shadowing9 and “teach-back10” formats, where someone explains what they’ve learned to confirm understanding.

3. Rotate roles and share responsibilities

• High-performers often stay in their lane because it’s efficient. But efficiency now = fragility later.

• Let them pick up a different role, mentor someone else, step back and let someone else lead for a period.

• Build “planned absence” drills: Let them step out for a week and test how well the team carries on.

• Pair juniors with seniors, shadowing or pairing helps knowledge move through real-world collaboration.

4. Recognise the right behaviours

• Shift recognition: Celebrate someone for enabling others, not just for delivering alone.

• Introduce metrics: “Number of processes covered by more than one person”, “Time to ramp up substitute for key role”, “Percentage of tasks where more than one person can answer questions”.

• Encourage culture of shared ownership: “team delivered” instead of “hero delivered”.

5. Redefine your own leadership role

• Ask yourself: “Where am I the bottleneck?” and “Where am I encouraging a hero rather than a system?”

• Delegate visibly: lead meetings, give others the chance to lead, hold back the rescue impulse.

• Make time for process, coaching, documentation. Yes it may feel slower, but slower building of resilience now means faster recovery later.

• Model failure, transparency: Show the team you expect fallibility and build accordingly.

6. Transform the system, not just the behaviours

• Review performance measurement: Are you rewarding crisis fixers or process builders? Are you encouraging teaching/training or just doing?

• Align incentives: Recognise mentors, knowledge distributors, team enablers.

• Review resource allocation: Does your high-performer have time to mentor, document and distribute? Or are they always firefighting?

• Embed continuous learning: High-reliability organisations11 emphasise learning from near-misses, not just hero rescues.

7. Introduce change management for culture

• Shift language: From “I need a hero” to “We build circuits that work without one”.

• Communicate: Let teams know the aim is not to push heroes out, but to build strength into the system.

• Pilot: Select one unit or process to apply this change. Then scale.

• Monitor: Track progression, gather stories of where resilience improved.

So what’s the better model? Try the Avengers 2.0

By Avengers: Endgame, Tony Stark is powerful, but the final victory isn’t his alone. The team is prepared, roles shift, capabilities overlap and several members can step in when needed. That transition mirrors a resilient organisation.

What does that look like in business terms?

• A team where knowledge is shared, decisions are distributed, relationships are cross-owned.

• One person’s absence doesn’t halt operations.

• High-performers aren’t isolated stars. They are multipliers12 and they raise others.

• The system is less about “who we rely on” and more “what we rely on”.

• You don’t need a cape. You just need good habits.

Additional dimensions & research insights

To make this article truly comprehensive, here are deeper aspects backed by research:

Relationship & network dependencies

• Hero often holds external relationships: one person may be the key link with a customer, vendor or regulatory body. Losing them means losing that bridge.

• Organisations with heavily centralised network links are more fragile.

Decision-making load and fatigue

• When decisions wait for the hero, there is decision-latency, overload and risk of poor decisions due to fatigue. Research in team dynamics shows that distributed decision-making and high inter-dependence reduce load.

Innovation and growth constraints

• A hero-centric team may solve current problems, but built for novelty? Not so good. The study of “hero projects” in software found that as size increased, reliance on heroes rose, but that may limit adaptability.

Burnout and retention issues

• Heroes often carry heavy cognitive, social and operational load. Without buffers, burnout risk rises. Recent studies link servant leadership, culture and burnout as significant factors.

Cultural and organisational culture effects

• A systemic review found that hero culture often correlates with silo thinking: hero silos => less cross-team knowledge sharing, more internal barriers.

• Organisational culture frameworks emphasise knowledge sharing and alignment as predictors of healthy performance.

Getting started without the perfect blueprint

You don’t have to overhaul everything overnight. Here are practical first steps, now with extra depth.

• Pick one high-risk process this quarter (if person X is unavailable, we’d know).

• Map the process: Who knows it? Who could step in? How long would ramp-up take? Who shares the relationship/customer?

• Implement the two-know rule: Identify second person, schedule shadowing, knowledge share session.

• Run a team workshop: “If person X were unavailable tomorrow: what happens?” Let candid answer live.

• Introduce one recognition shift: At next team meeting, thank someone for “making someone else able to do the work” rather than “solving it yourself”.

• After 90 days: Check how many processes now have >2 capable people. How long would it take if X were absent? What changed?

• Expand: Build dashboard with metrics: number of SPOFs identified, number of cross-trained people, number of processes with 2+ owners.

Final thoughts

If you walk away with one thought, let it be this: Great leadership isn’t about making someone irreplaceable. It’s about making things replaceable in the best way.

The next time you hear, “We couldn’t do this without X,” pause. Ask: “Why is that still true? What would change if X were unavailable tomorrow? Who else can step in? What would prevent us from being stuck?”

Resilient organisations don’t depend on heroes. They build habits, systems and networks. They prepare so when key people are out, the mission continues with no dramatic last-minute rescue.

Because if you have to depend on a guy in a suit to strap on the armour, you’re already building the wrong model. Build like the late-game Avengers instead.

Further reading

• Molek, N., de Jager J.E. & Pucelj, M.: Hero Culture and Silo Mentality: a Systematic Literature Review (2023)

• Weick, K & Sutcliffe K.: Managing the Unexpected - Resilient Performance in an Age of Uncertainty (2007)

• Agrawal A, Rahman A., Krishna R., Sobran A. & Menzies T.: We Don’t Need Another Hero? The Impact of “Heroes” on Software Development (2017)

• Lisak A, Harush R., Icekson T. & Harel S.: Team Interdependence as a Substitute for Empowering Leadership Contribution to Team Meaningfulness and Performance (2022)

• Project Management.com: 3 Tips for Avoiding the Single Point of Failure.

Glossary

Imagine you’re steering a boat through fog.
You can feel the hum of the engines, the chatter of the crew, the tension of moving without seeing.
That’s what many companies feel like today: fast, reactive, customer-driven… and directionless.

Being driven means something else is steering.

The illusion of being “customer-driven”

“Customer-driven” sounds virtuous: We listen. We respond. We care.
But in most organizations, it means you’re reacting, not understanding.

At first it feels good. Teams feel useful. Customers seem heard.
But slowly, exhaustion replaces direction.

Customer-driven1 teams:

• Chase every request that sounds urgent

• Rebuild roadmaps weekly

• Confuse motion with progress

They’re like captains who change course every time someone points at a new light on the horizon.
The result: a ship that’s always moving, but rarely arriving.

Being responsive isn’t the same as being relevant.

The customer-centric difference

Customer-centric2 teams still listen, but they listen differently.
They don’t treat feedback as orders, they treat it as data.
They listen for meaning, not volume.

They ask:

• What job is the customer trying to get done?

• What’s making that job harder than it should be?

• How can we solve it once, in a way that helps many others?

Customer-centricity starts where leadership stops reacting and starts asking better questions.

In Lean-Agile3 terms, that means seeing work through the Customer Value Stream4, the sequence of steps where value is actually experienced, not just produced.

Customer-driven teams follow waves.
Customer-centric teams steer by compass.

The request is noise. The job is signal.

Why this matters more than ever

In 2025, products are easy to copy. Understanding isn’t.
Switching costs are near zero and every customer carries a megaphone.

Research from McKinsey, Bain and Forrester shows a consistent pattern:
companies that lead in customer experience tend to grow significantly faster, retain customers longer and convert trust into measurable profitability.

McKinsey notes that CX leaders5 achieve more than double the revenue growth of laggards, while Bain’s work highlights that reducing customer effort is one of the most reliable ways to increase loyalty and reduce churn.

Forrester and others have found that a large share of new software features still fail to deliver measurable value within months of release not because teams don’t move fast enough, but because they solve the wrong problems.

Raw speed isn’t a moat. Clarity is what makes speed compound.

In an age where AI makes imitation effortless, understanding is the only true advantage left.

From noise to signal

Every customer message carries truth hidden in static.
The hard part isn’t hearing customers.
It’s filtering emotion, politics and pressure until you find the pattern underneath

The Noise → The Signal

• “Give us more notifications.” → “We’re missing critical changes until it’s too late.”

• “Make it more customizable.” →“We can’t align the tool with our specific process without extra work.”

• “We need a bigger dashboard on the shop floor.” → “Operators can’t immediately see when performance drops.”

• “Add AI assistant” → “We spend hours hunting for answers.”

• “Add live chat” → “We’re losing customers during waiting time.”

• “More dashboards” → “We don’t trust what we see.”

Customer-driven teams log the noise.
Customer-centric teams decode6 the signal.

They translate symptoms into causes and causes into design decisions.

Clarity never shouts. You have to listen differently to hear it.

In agile systems, this translation happens inside the Continuous Exploration7 cycle, where teams connect market signals with real-world observation before committing code or capacity.

The NASA pencil story: A lesson in signal over noise

One of the most famous examples of confusing noise with signal comes from the early days of the Space Race.

When NASA faced the problem of how astronauts could write in zero gravity, engineers began developing a high-tech “space pen”, pressurized ink cartridges, special materials and millions in R&D investment.

Meanwhile, the Soviet cosmonauts simply used a pencil.

The story (even if partly myth8) illustrates a deeper truth: when you mistake the symptom for the job, you overengineer the solution.
NASA’s “noise” was “We need to design a pen that works in space.”
The real “signal” was “We need a way for astronauts to record information in zero gravity.”

That single shift in framing is the essence of customer centricity.
Being customer-driven would mean building the pen.
Being customer-centric means asking why the pen is needed in the first place.

Solution pollution: when activity replaces understanding

Every organization suffers at some point from solution pollution, the buildup of ideas, features and initiatives launched before the problem is fully understood.
It feels productive: teams are shipping, backlogs are moving, customers are getting “something.”
But like environmental waste, every unvalidated solution leaves residue: complexity, confusion and cost.

Solution pollution happens when listening turns into compliance instead of curiosity.
You collect symptoms, not signals. You fill roadmaps, not gaps in understanding.

The antidote isn’t more prioritization, it’s better diagnosis.
Customer-centric teams clean the ecosystem by slowing down long enough to ask:

“Is this a real need or just a reaction?”

Because every feature built on noise adds friction to the system and clarity always starts with subtraction.

The Double Diamond: a compass for better decisions

The Double Diamond9, created by the UK Design Council, isn’t just a design model.
It’s a rhythm for making better decisions by separating understanding from solving.

Most teams collapse those two moments into one:
They hear a problem and immediately start building.
The Double Diamond forces a pause. It asks you to explore before you decide.

Problem Space

Discover: look wider before you narrow down

Talk to customers. Observe real behavior. Collect raw evidence, not opinions.
The goal isn’t to confirm what you think you know, it’s to find patterns.
Ask: Where are people struggling, improvising or compensating?

Define: frame the real problem

Group what you’ve learned.
Then write one clear statement that captures the essence of it.
For example: “Finance teams don’t need faster exports, they need fewer manual steps.”
This becomes your North Star for the next phase.

Solution Space

Develop: explore multiple ways to solve it

Don’t jump to your favorite idea.
Sketch, test and discard.
Look for approaches that solve the job, not just add a feature.
Invite cross-functional teams (engineering, support, customer success) to test small.

Deliver: make it real and measure the outcome

Build the simplest version that proves the solution works.
Then measure whether customer behavior changes in the intended direction:
shorter cycle times, fewer workarounds, higher confidence.
Iterate around evidence, not internal opinions.

Example: One SaaS team used this rhythm to clean up a chaotic backlog10.
Two weeks in Discover revealed that 80 % of requests traced back to four core jobs.
By Define, they had a focused roadmap and calmer planning sessions.

The Double Diamond isn’t about slowing down.
It’s about thinking in focus before acting in force.

Skip the first diamond and you’ll move quickly in the wrong direction.
Use both and you’ll finally steer with intent.

The Kano Model: not every request deserves a feature

Understanding customer needs isn’t just about collecting requests, it’s about recognizing which ones actually drive satisfaction.

That’s where the Kano Model helps: it separates what customers say they want from what truly delights or frustrates them.

Kano identifies five categories of customer expectations:

• Basic Needs (Must-be):
  The essentials customers rarely mention until they fail.
  When missing, they cause frustration. When present, they’re taken for granted.
  Example: data security, system reliability, invoice accuracy.

• Performance Needs (More-is-better):
  Directly correlated with satisfaction: the faster, easier or cheaper something gets, the happier the customer.
  Example: page load time, processing speed, time-to-close.

• Delighters (Exciters):
  Unexpected features that spark loyalty and differentiation, until they become expected tomorrow.
  Example: automatic anomaly detection, predictive alerts, zero-click setup.

• Indifferent Needs:
  Elements that neither add nor reduce satisfaction. Customers simply don’t care.
  Example: cosmetic interface tweaks that don’t change usability or redundant customization options.

• Reverse Needs:
  Features that actually reduce satisfaction when added or overemphasized.
  Example: overly complex automation, excessive notifications or mandatory personalization that feels intrusive.

Customer-driven teams often chase delighters reactively, trying to surprise, impress or please every request that sounds exciting.
Customer-centric teams use frameworks like Kano to distinguish between hygiene, performance and true innovation, ensuring that effort aligns with lasting value.

The goal isn’t to do everything customers ask for.
It’s to understand which needs sustain trust and which truly create delight.

A moment of realization

Picture a product team in a room covered with sticky notes.
Requests from customers, partners and sales everywhere.

The CEO looks at the board, then at the team.
A minute ago the room was buzzing. Now? Quiet!
He finally says:

“We’re making customers happy. But are we making them successful?”

That was the turning point.
They stopped chasing noise and started mapping customer jobs-to-be-done11.
Within months, the backlog was half the size and customer satisfaction went up.

They didn’t have to build more. They had to build right.

A real-world example

A mid-market fintech kept hearing the same request:

“Add more export formats.”

They almost shipped it until a customer success lead asked a simple question:

“Why do you need them?”

After 12 short interviews, the pattern was clear:

“We just want to close the books without late nights.”

Instead of adding export formats, the team built auto-reconciliation with anomaly detection.
Support tickets dropped 40 %, month-end close became 30 % faster and renewal rates rose by 12 points.

When teams start solving for progress instead of preference, they stop wasting effort and customers notice.

The economics of understanding

Understanding feels slow, but it’s the fastest path to results.
A wrong feature burns engineering time, marketing money and credibility all at once.
It also trains your teams to confuse urgency with importance.

Gartner estimates that 35% of development resources in B2B SaaS go to unused features.
That’s what empathy12 without clarity costs.

Solving the right problem once is cheaper than solving the wrong one three times.

Empathy isn’t soft. It’s capital discipline disguised as care.

The cultural resistance

Every company claims to value understanding until it slows delivery.

The usual blockers:

1. KPI addiction13: measuring output, not outcomes14.

2. Hero culture15: speed gets applause, insight doesn’t.

3. Political safety: saying “yes” feels easier than “not now.”

How to fix it:

• Redefine success: learning before launching.

• Reward insight, not just output.

• Let leaders model patience.
  A CEO who says “Let’s listen first” gives everyone permission to think.

Lean-Agile leadership calls this “Go See” or “Gemba”16 spending time where value is created and experienced, not just reported.
It’s empathy by design, not by chance.

But culture changes the same way trust does: through a thousand small, consistent signals.

From principle to practice: how to apply this

Big shifts rarely start with big programs.
They start with a single team asking a better question.

Customer-centricity isn’t a mindset you declare.
It’s a rhythm you practice.
Here are simple ways to start changing direction today.

1. Start every project with a “Problem Frame.”
   Before you design or code anything, answer three questions:

   • What customer job does this support?

   • What friction are we solving?

   • How will we know it worked?
     → Forces clarity before motion.

2. Run “Noise vs. Signal17” sessions.
   Once a month, take all customer requests.
   Write the literal words on one side (“Noise”), the real goal on the other (“Signal”).
   Patterns will jump out. Teams will start listening differently.

3. Create a simple “Customer Compass18” board.
   Three columns on a wall or digital board:

   • Top 3 customer jobs

   • Top 3 pain points

   • Top 3 experiments in progress
     When decisions get noisy, look up. That’s your compass.

4. Link metrics to real outcomes.
   Add to your dashboards:

   • Time-to-Value19

   • Customer Effort Score20

   • % of Roadmap tied to top-3 jobs
     These numbers keep you honest.

5. Ask better questions in meetings.
   Replace “When can we ship?” with:

   • “How do we know this solves the right problem?”

   • “What behavior should change if we’re right?”

   • “What evidence do we already have?”

6. Celebrate insight, not just delivery.
   At your next all-hands, don’t just celebrate launches.
   Celebrate learning moments.

“We discovered the real friction behind feature X and it changed our roadmap.”

Culture changes when curiosity gets applause.
That’s how momentum turns into direction.

Reflection for leaders

If you lead a team, ask yourself:

• Do we know our customers’ top three outcomes?

• Would our roadmap make sense to them or only to us?

• When did we last say “no” for a good reason?

• Are we steering by compass or chasing every wave?

These aren’t rhetorical questions.
They’re the start of a new kind of conversation inside your company.

If they feel uncomfortable, good.
That’s the beginning of clarity.

A note on nuance

While the distinction between customer-driven and customer-centric clarifies two opposing reflexes, the real world is rarely that binary. Mature organizations learn to balance both forces: responsiveness keeps them humble and fast, centricity keeps them coherent and focused. Listening without discipline creates noise, but discipline without listening breeds detachment. In Lean-Agile environments, these tensions play out daily, between exploration and delivery, learning and commitment, autonomy and alignment.

True customer centricity is not the absence of reactivity, it is the ability to react with intent. Leading organizations like Toyota, Amazon or Spotify illustrate this balance daily, they use continuous feedback loops to sense real-time shifts, yet steer through enduring customer principles that act as their compass. This integration happens where teams align discovery and delivery rhythms using customer outcomes, not opinions, as their shared north star.

In practice, this means designing systems that make doing the right thing (not the loud thing) the path of least resistance. The challenge isn’t choosing between being driven or centric, it’s learning to integrate both into one rhythm that adapts without losing direction.

Final thoughts

Customer-driven teams move fast, often in circles.
Customer-centric teams move deliberately and arrive.

The first listen to everything.
The second understand something.

The first react.
The second navigate.

Because the goal isn’t to move faster.
It’s to move truer.

Customer-centricity isn’t about saying yes more often.
It’s about seeing more clearly and steering with intent.
Because when you steer with intent, customers feel it and that’s what makes trust scale.

In Lean-Agile systems, customer centricity isn’t a department, it’s a decentralized reflex.
Everyone, from engineers to executives, learns to sense where value flows and where it stalls.

Further reading

• Harvard Business Review: “Know Your Customers’ Jobs to Be Done”

• UK Design Council: “What Is the Double Diamond?”

• Harvard Business Review: “The Value of Customer Experience, Quantified”

• McKinsey & Company: “Experience-Led Growth”

• Lance B. Coleman: The Customer-Driven Organization: Employing the Kano Model

Glossary

The bureaucracy trap or why “Permit A38” still feels familiar

Remember the scene from The Twelve Tasks of Asterix, where Asterix and Obelix are sent to get Permit A38, the mythical form that sends them through endless offices and counters until they lose their minds? It’s hilarious on screen. In real life, it’s just another Monday in many companies.

That scene wasn’t just comedy, it was prophecy. Every growing organization builds its own “The Place that Sends you Mad” processes that once brought order slowly mutate into obstacles. Rules designed to prevent chaos start to cause it.

Why this matters: bureaucracy kills speed (and energy)

There’s a simple truth most leaders learn the hard way: speed is a strategy, not just a delivery metric. The longer it takes to make a decision, the more likely it is to lose relevance or impact. In product development, that might mean being late to market. In operations, it could mean missed cost-saving opportunities. In customer experience, it means frustration.

But the damage goes deeper. Bureaucracy1 doesn’t just slow the system, it demoralizes the people in it. High-potential employees end up spending their time explaining their work instead of doing it. Meetings become about alignment rather than action. And instead of accountability, you get diffusion. Everyone’s consulted, but no one’s responsible.

According to Bain & Company, large organizations lose up to 30% of their productive capacity to what they call “organizational drag2”. That’s not inefficiency at the margins, it’s a full third of your firepower stuck in molasses.

The Mirage of the Perfect Process

At some point, every organization falls in love with the idea of the perfect process: one that catches every edge case, eliminates every risk and works for every scenario. It’s an appealing idea: order instead of chaos, certainty instead of surprises.

But in practice, chasing perfection leads to paralysis. Processes become bloated with approvals, exceptions and conditional logic. Teams spend more time updating each other than updating the customer. And the focus shifts from delivering outcomes to following procedures.

The irony is that most decisions aren’t that risky. Jeff Bezos famously distinguishes between one-way doors3 (hard to reverse, high stakes) and two-way doors (easy to undo, learn-as-you-go). Most internal decisions are two-way. They deserve speed, not ceremony.

Think like a highway, not a maze

Imagine your organization’s process landscape as a road network. In some companies, it’s a tangle of dead ends, detours and toll booths. But it doesn’t have to be.

Design your operations like a modern highway:

• Fast lane4: A streamlined path for the most common 80% of cases. Few steps, few approvals, minimal friction.

• Guardrail shoulder: An alternative route for exceptions, with basic criteria to ensure oversight without overkill.

• Toll booths (approvals): Only at true risk points. Not every intersection needs a traffic light.

This approach doesn’t just simplify, it builds resilience. By focusing effort where it matters, you reduce the mental load on employees and allow them to operate with more clarity and speed.

Design from the outside in: what does the customer feel?

One of the most powerful reframing questions any team can ask is: how does this process feel to the customer? Not how it’s documented. Not what the SLA says. But what it’s actually like to go through it.

That’s where Customer Effort Score (CES)5 comes in. Instead of asking “Did we delight the customer?”, it asks “How easy was this to get done?” Why? Because research consistently shows that ease (not delight) is what drives loyalty.

To align internal processes with external experience, apply three tests to every step:

1. Does it deliver value faster?

2. Does it prevent a real customer-facing issue?

3. Does it reduce the effort required by the customer or frontline employee?

If a step fails all three, it probably exists for internal comfort and should be reconsidered.

Tool 1: Value Stream Mapping (VSM)

Value Stream Mapping6 is a way to visualize the full journey from request to delivery, not as it should work, but as it actually does. It reveals two powerful truths:

1. Most of your lead time7 isn’t spent doing the work, it’s spent waiting.

2. The biggest opportunities for speed gains lie in the handoffs and idle time.

How to do it (on a whiteboard):

• Pick a concrete process (e.g., approving capital expenses over €10K).

• Map out each step from start to finish.

• Below each step, note:

  • How long the step usually takes

  • How often it gets stuck

  • Who’s involved

  • What the trigger is for moving to the next step

• Add up total active time vs. total elapsed time.

Real-world example: A manufacturing firm maps its spare parts procurement process and finds:

• 3 steps of actual work: request, validate, order (total 1.5 hours)

• 7 days of average waiting time due to unclear roles, email chains and batch approvals
  → Lead time reduction potential: over 90% just by adding ownership and daily approvals.

Tool 2: Service Blueprinting

Where VSM looks at flow, Service Blueprinting8 looks at experience. It maps what customers or users see (frontstage) against what happens behind the scenes (backstage).

How to do it:

• Draw a horizontal line: above it, customer actions; below it, internal steps.

• For each visible action (e.g., “Submit support request”), map the backend steps that enable or respond to it.

• Look for disconnects: where does internal complexity break the customer’s experience?

Real-world example: An industrial services provider maps their “field technician dispatch” process. Customers see a 3-day delay after ticket submission. Blueprinting reveals the cause: dispatchers wait for job codes from finance. Finance only processes requests twice per week. A simple daily batch fix reduces wait time from 3 days to 1.

Tool 3: Flow Metrics and Little’s Law

You don’t need to be a genius to understand flow. Just this one formula:

Lead Time = Work in Progress (WIP)9 ÷ Throughput10

What that means:

• If a team has 40 items in progress and completes 10 per week → Lead time is 4 weeks.

• Reduce WIP to 20 → Lead time drops to 2 weeks.

And you didn’t hire anyone new. That’s the power of limiting how much work is in flight.

Real-world example: A technical documentation team tracks 24 manuals in editing and averages 6 completions per week. Lead time = 4 weeks. They implement a WIP limit of 12. Output stays stable, but lead time drops to 2 weeks. Review fatigue also improves (fewer context switches).

Tool 4: Cost of Delay (CoD)

Cost of Delay (CoD)11 helps you prioritize which process to fix first. The formula is simple:

Value lost per week ÷ Effort to simplify

Example 1:

• An internal pricing approval delays 2 quotes per day.

• Each delayed quote reduces win probability by 15%, average margin per deal is €3,000.

• Estimated value loss: €900 per day → ~€18,000/month.

• A one-time simplification effort of 40 hours (~€3,200 cost).

• → CoD ratio: 5.6:1 → High priority.

Example 2:

• Monthly vendor onboarding delays indirect procurement by 7 days.

• Cost of delayed equipment = €250/day.

• 10 projects per month affected → €17,500/month lost.

• Process can be simplified with two rule changes and one data integration.

• Implementation cost: €5,000.

• → CoD ratio: 3.5:1 → Also high, but lower impact per euro than pricing process.

These examples make the value of simplification visible to finance, not just operations.

How to simplify (without breaking things)

You don’t need consultants or massive programs to reduce complexity: just a clear, disciplined loop that any team can run.

The Lean Simplification Loop (10 Steps)

1. Start with purpose
   Ask: What outcome or risk does this process protect? If the answer’s unclear, cut it. Simplify anything that doesn’t protect real customer value or business risk.

2. Define the 80% path
   Design a short, clean route for common cases. Handle exceptions with light guardrails, not committees. Use Value Stream Mapping (VSM) to visualize how work flows and Service Blueprinting to link internal steps with the customer experience. These tools reveal delays, rework and steps that serve no one but internal comfort.

3. Involve the doers
   Talk to the people who live the process. Ask: What slows you down? What’s useful? What would you delete tomorrow? Their insights are the fastest way to find friction and fix it.

4. Use customer value as your compass
   Every step should help the customer get results faster, more reliably or with less effort. If not, simplify or remove it. Research shows that reducing Customer Effort (CES) drives loyalty more than trying to “delight.”

5. Trust before control
   Push decisions down. Assign one clear owner per step, with decision SLAs (e.g., “respond within 48h”). Save approval chains for high-stakes, one-way-door decisions. Fewer gatekeepers → faster flow → fewer mistakes.

6. Eliminate & simplify with ECRS
   Apply the ECRS framework to every step:

   • Eliminate: Can we cut it?

   • Combine: Can we merge steps?

   • Rearrange: Could the order be better?

   • Simplify: Can we reduce effort?

7. Pilot the new path
   Run a lean version with a small team. Measure impact on lead time, flow efficiency and CES. Keep changes that work. Only reintroduce complexity if risk or quality issues appear.

8. Measure what matters
   Focus on real flow metrics:

   • Lead time (request to delivery)

   • Flow efficiency (work ÷ total time)

   • Decision latency (avg. time to “yes/no”)

   • CES (user effort)

   Ignore vanity metrics like email volume or form completions. Use Cost of Delay to prioritize.

   And cap Work in Progress (WIP), because Little’s Law guarantees: when WIP drops, lead time does too.

9. Make learning a habit
   Simplification isn’t a one-time fix. Hold quarterly “kill a stupid rule” reviews. Start small and scale only what works. Celebrate deletions as real wins, because every rule you remove signals trust and clarity.

10. Scale & sustain
    If the pilot works, document it in a one-page process charter. Share it. Use a shared Kanban board or spreadsheet to track lead time and decision SLAs. Keep the loop going: simplify → measure → learn → scale.

Timing: One simplification loop fits easily in one quarter:

• 2 weeks for mapping

• 2 weeks for redesign

• 4 weeks for piloting

• 2 weeks for evaluation

Team: 4–6 people (process owner, frontline doer, customer-facing role, compliance or risk). No external consultants needed.

What Lean Is Not

• Not chaos, it’s clarity about what matters.

• Not “faster approvals”, it’s fewer approvals.

• Not a one-time cleanse, complexity always grows back. Plan to prune.

The 30-Day Pilot: no slide decks required

Week / Action

1. Choose a process everyone complains about. Clarify what it’s supposed to do.

2. Map it. Use VSM and Blueprinting with the actual people running it. Count steps and waits.

3. Redesign the 80% path. Cut waste. Assign ownership. Add WIP caps and decision SLAs.

4. Test the lean version. Track lead time, CES, error rates. Only reintroduce complexity if risk increases.

Create a One-Page Process Charter

• Purpose: Customer outcome or risk the process protects.

• Owner: Name, role, decision SLA (e.g., 48h).

• 80% Path: 3–5 clear steps.

• Exception Path: Criteria, guardrails, escalation.

• WIP Limit: Max items in progress.

• Metrics: Lead time, handoffs, decision latency, flow efficiency, CES.

• Risk Tiers: Low/Medium/High with thresholds and matching controls.

Final thoughts: simplification is a leadership act

Simplification isn’t about chaos. It’s about clarity. About knowing what matters and having the guts to cut what doesn’t.

Every unnecessary rule you remove sends a message to your team: We trust you to think. That’s how energy returns. That’s how speed becomes a habit. That’s how innovation scales.

Further Reading

• Bain & Company, Organizational Drag

• M. Dixon & K. Freeman & N. Toman, Stop Trying to Delight Your Customers (Harvard Business Review)

• M. Rother & J. Shook, Learning to See

• Bitner & Ostrom & Morgan, Service Blueprinting: A Practical Technique for Service Innovation

• D. Reinertsen, Principles of Product Development Flow

• G. Hamel & M. Zanini, Humanocracy: Creating Organizations as Amazing as the People Inside Them

Glossary

Meeting tourism isn’t a vibe or a meme. It’s a system problem. Calendars fill, decisions slow and people mistake presence for progress.

Hollywood captured this perfectly in the cult film Office Space (1999). In one famous scene, the main character Peter Gibbons sits through an endless sequence of boss check-ins and manager updates, each demanding explanations about trivial “TPS reports.” The point is clear: being in meetings doesn’t equal doing meaningful work. It’s the perfect metaphor for what happens when organizations confuse attendance with progress.

The data highlights the problem:

• Professionals spend on average ~11 hours per week in meetings

• Around 35 % of meetings are considered a waste of time

• In distributed software teams, people spend ~7h 45m in planned + ~8h 54m in unplanned meetings each week

• 77 % of employees say meetings often end with scheduling yet another meeting

This article goes deeper: why we drift into too many meetings, how to design meetings that actually work and how to reset the culture without drama.

Why we drift into too many meetings (and stay there)

It’s not laziness. It’s incentives, psychology and defaults.

1. FOMO1 & Impression Management
   People join to “stay in the loop,” signal commitment or avoid political risk. If everyone’s there, nobody can be blamed later. That’s safety, not impact.

2. Urgency Theater
   Booking a meeting feels like progress (a quick dopamine hit). The mere urgency effect nudges us toward what’s immediate over what’s important. We end up solving calendar problems, not business problems.

3. Status via attendance
   Some cultures equate invites with importance. Declining looks like disengagement. So leaders invite “just in case” and people accept to be seen.

4. Risk diffusion
   When ownership is fuzzy, we pull more people into the room to spread accountability. More attendees ≠ more clarity; often the opposite.

5. Remote/hybrid overcompensation
   To replace hallway chats, we schedule recurring syncs. Without strong async2 habits, meetings become the default communication channel.

6. Default settings & inertia
   Calendar tools auto propose 30/60 minutes, recurring forever and invite whole groups. If your system defaults to more, you’ll get more of the wrong thing.

7. Back to Back Fatigue3
   Continuous context switching spikes stress and tanks focus. When people are depleted, they drag topics to another meeting instead of deciding now.

What “effective” vs. “efficient” meetings really mean

• Effectiveness = Did we produce the outcome? (Decision made, risk retired, plan aligned, trust built)

• Efficiency = Did we spend the minimum necessary time and people to get that outcome?

You need both. A fast meeting that decides the wrong thing isn’t efficient. A thoughtful meeting with the wrong crowd isn’t effective.

A practical decision tree: do we even need a meeting?

Before you click “Send”, walk the topic through this filter:

A. Is there a decision we must make synchronously?

• Yes → Consider a Decision Review4 (small, pre read, clear decision rule)

• No → Go to B

B. Do we need real time debate to reach shared understanding? (e.g. major trade offs, design workshop)

• Yes → Time box a Working Session with a facilitator and pre work

• No → Go to C

C. Is the goal status/updates or info broadcast?

• Yes → Use async: written update, dashboard, 3–5 minute video or a living doc

• No → Go to D

D. Is this primarily relationship/trust building? (1:1s, skip levels)

• Yes → Keep, but short and intentional

• No → Cancel or replace with async

If a meeting survives A–D, give it an expiration date. Every recurring invite dies unless re justified.

The “6 P Meeting Ops” framework

Treat meetings like a production process. Six checkpoints keep quality high:

1. Purpose
   State the outcome in one line: “Decide X,” “Align on Y,” “Unblock Z” If you can’t write this, you don’t need a meeting.

2. Product (what leaves the room)
   Decision, owner, deadline. A doc change, a prioritized list, a risk acceptance. Define the artifact.

3. People
   Invite only those who add or take value. Name a DRI5 (Directly Responsible Individual) for the outcome. Everyone else? Optional or informed via notes
   And remember Jeff Bezos’s Two Pizza Rule6 : if two pizzas can’t feed the group, the meeting is too big. Smaller groups move faster and make clearer decisions.

4. Prep
   Choose one approach: either distribute pre-reads 24–48h in advance and expect preparation (use a 1–2 page narrative or a decision brief - see template below, mark sections to skim vs. study) or start with 5 minutes of silent reading so everyone is on the same page, but never mix the two. No reading afterwards during the meeting.

5. Process

   1. Agenda written as questions (not topics)

   2. Decision rule clear upfront (e.g. DRI decides after input; consent vs. consensus; one way vs. two way door)

   3. Roles: Facilitator, Scribe, Timekeeper

   4. Time boxes (25 or 50 minutes)

   5. Parking lot for off topic items

6. Post
   Within one hour: send the one pager - What, Who, When - plus the decision record link

Six meeting types that actually earn their keep

1. Decision Review (30–50 min, ≤6 people)
   When: There’s a clear owner and a real decision
   Prep: 2 page decision brief (context, options, trade offs, recommended choice)
   Output: Decision, risks, follow ups, comms plan

2. Working Session / Design Jam (50–80 min, 4–8 people)
   When: You need live iteration on a complex artifact
   Prep: Draft artifact + constraints
   Output: Updated artifact and next owner

3. Retrospective (45–60 min, team)
   When: Improve how the team works
   Prep: Silent brainstorm of what to start/stop/continue
   Output: 1–3 concrete experiments with owners

4. 1:1 (25–45 min)
   When: Coaching, context, well being, performance
   Output: Agreements, feedback, growth steps

5. Risk/Incident huddle (15–30 min)
   When: Something broke; time matters
   Process: Leader states objective, constraints, decision rule; scribe captures actions in real time

6. Big Room Planning / All Hands (60–120 min, large group)
   When: Organization wide alignment is needed (strategy, planning, key announcements)
   Prep: Clear agenda, pre shared materials, focus on alignment not detail solving
   Output: Shared understanding, documented goals, visible commitments

Agile and Scrum Meetings in Context

• Sprint Planning → mix of Decision Review and Working Session: decide what to deliver, plan how.

• Daily Scrum → a short Risk/Incident Huddle: quick sync to surface blockers and adjust for the day.

• Sprint Review / System Demo → a form of Big Room Alignment: stakeholders see progress, give feedback, decisions are captured.

• Retrospective → already covered as a standalone meeting type.

• PI Planning (SAFe) → an extended Big Room Planning format, multi team, typically two days.

Everything else? Default to async

Culture change: how to move from “tourism” to outcomes

1) Change the defaults (systems beat slogans)

• Set calendar defaults to 25/50 minutes, not 30/60

• Turn recurring off by default; add end dates

• Add a meeting cost banner (Outlook/Google add ins) so people see the price tag before sending

2) Leader behaviors (what you do > what you say)

• Decline politely when you don’t add/take value and explain why

• Require pre reads and send back decks that arrive late

• Start on time, end early, publish decisions fast

3) Normalize async

• Weekly written updates (template below) replace status calls

• Short looms for demos; comments in doc replace “quick sync?” pings

• Office hours for drop in questions (protects maker time)

4) Governance without bureaucracy

• Zero Based Calendar7 every quarter: all recurring invites expire unless re approved

• Meeting SLAs8 : no agenda as questions + pre reads? Auto decline

• Decision Log: all decisions captured in one place, searchable

5) Psychological Safety
Invite dissent. Ask the quietest voice first. Reward people who kill their own meetings.

6) Measure what matters

• Meeting load (hours/person/week)

• Decision latency9 (request → decision)

• Attendee count and optional ratio

• Outcome rate (% of meetings with a decision/action by EOD)

• Focus time ratio (≥2h blocks on calendars)

• Sentiment (1–5 usefulness pulse in the recap form)

7) Handling redundant meetings you don’t own
Sometimes the hardest meetings to cut are the ones you didn’t create. If the organizer clings to them, try this:

• Ask for clarity: “What decision or outcome do we expect here?”

• Offer alternatives: Suggest sharing async updates or merging with another forum

• Decline with context: Explain how you’ll stay informed (reading notes, async comments) without attending

• Build allies: If several participants feel the same, approach the organizer as a group

• Escalate gently: If it’s a systemic issue, raise it in a retrospective or team health check, not as personal criticism but as a productivity blocker

30 Day Playbook (minimal drama, maximum signal)

Week 1: X-Ray your calendar

• Export last 8 weeks. Sort by series. Flag: no agenda, no decision, >8 attendees, recurring with no end date

• Kill or merge the bottom 25% this week

Week 2: Flip to async

• Replace status meetings with a Friday Update doc or 3 minute video (template below)

• Introduce office hours for leads

Week 3: Install the 6 P Guardrails

• Publish your meeting policy (one page)

• Add a decision brief template

• Train 10% of managers in facilitation and decision rules (consent vs. consensus; DRI)

Week 4: No meeting blocks + review

• Protect two 2 hour focus blocks per person per week

• Run a quick pulse: Which meeting should we kill next?

• Publish before/after: meeting hours, decisions made, focus time gains

Templates you can copy/paste

You can find all the templates with examples in a single document at the end of this article (“Practical Tips for Effective & Efficient Meetings - Full Templates Pack”).

1) Decision Brief (≤2 pages)

• Purpose: Decide on ___ by ___

• Context: What’s true, what’s changed

• Options: A/B/C with trade offs

• Recommendation: ___ because ___

• Risks / Reversibility: One way or two way door?

• Stakeholders: Who’s impacted / consulted

• Decision Rule: DRI decides after input | consent | consensus

• Pre reads: links

• Meeting ask: Specific questions to resolve

2) Question based agenda (example)

1. What choice are we making today?

2. What evidence would change our mind?

3. What’s the smallest test to de risk this?

4. What would make this fail?

5. What do we stop doing if we say yes?

3) Weekly written update (async)

• Top 3 outcomes this week

• Risks/asks (what you need from whom)

• Metrics (one line)

• Next week’s focus

• Shout outs (reinforce collaboration without another call)

4) Polite decline script

Thanks for the invite. Looks like I’m not essential for the decision/product here. I’ll skip to protect focus time but I’m happy to comment async on the doc and will read the recap.

5) Meeting recap (send within 1 hour)

• Decision(s): …

• Actions (What/Who/When): …

• Risks/assumptions: …

• Notes & links: …

• Usefulness (1–5): … (quick pulse)

Micro practices that punch above their weight

• Default to 50/25 minute slots; protect a 10 minute buffer

• Cap group size (≤6 for decisions; ≤8 for workshops)

• Start with silence: 5 minutes to re read the brief and write questions

• Use a round robin for input; facilitator last

• Put names on decisions (DRI) and dates on actions

• Record short loom summaries instead of “recap calls”

Biggest myths (and the reality)

• Myth: “More people = better decisions.”
  Reality: After a small threshold, each extra attendee adds cost and social friction with little signal. Use consult → decide. Remember: two pizzas should feed the whole group

• Myth: “We need a meeting to show we care.”
  Reality: Care shows up as clarity and responsiveness, often faster async

• Myth: “Shorter meetings are rushed.”
  Reality: Timeboxes focus minds. Use pre work and question agendas; end early when done

Further reading & tools (for your policy page)

• A. Whillans & D. Feldman & D. Wisniewski, The Psychology Behind Meeting Overload (2021)

• Microsoft Human Factors Lab, Research Proves Your Brain Needs Breaks (2021)

• B. Laker & V. Pereira & P. Budhwar & A. Malik, The Surprising Impact of Meeting-Free Days (2022)

• Steven G. Rogelberg, How to Create the Perfect Meeting Agenda (2020)

• Michael Mankins & Jenny Davis-Peccoud, Decision-focused meetings (2011)

• The GitLab Handbook, The complete guide to asynchronous and non-linear working (2021)

• M. Sheikh, The Amazon 6-Pager: Guide, Templates & Tips (2024)

• HBR Editors, Estimate the Cost of a Meeting with This Calculator (2016)

(Tip: add 3–5 of these links into your internal wiki, plus your own templates above. Make it the “Meeting Ops” home.)

Final Thoughts

Escaping meeting tourism isn’t about forbidding meetings. It’s about earning the meeting. When the default is async, ownership is explicit and the few meetings you keep are designed for decisions, calendars stop being a museum of invitations and start being a map of progress.

Bonus: Practical tips for effective & efficient meetings - all templates with examples (PDF)

• Decision Brief (≤2 pages)

• Question-Based Agenda

• Weekly Written Update (async)

• Polite Decline Script

• Meeting Recap (send within 1 hour)

Practical Tips For Effective & Efficient Meetings Full Templates Pack

262KB ∙ PDF file

Download

Download

Use it. Share it. Embed it in your team’s workflow. That’s how meetings get shorter, clearer and more productive.

Glossary

Remember the movie Whiplash? A young jazz drummer drives himself to the edge of collapse, chasing flawless performance under a merciless teacher. It is an exaggerated Hollywood metaphor rather than a typical classroom, but it shows the trap clearly: when perfection becomes the goal, progress and even personal growth stops.

That reminded me of a phrase an ex colleague often used: “Progress over perfection.” At first it sounded reasonable. Who would argue against moving forward instead of polishing forever? But the more I thought about it the more it bothered me. Progress does not automatically equal value nor does it mean something is truly done. The phrase is vague, a bit like saying “Just make it better.” Progress can still leave big gaps: unresolved risks, unfinished compliance steps or ignored stakeholder needs. And in high stakes or legally regulated areas, mistaking “progress” for “completion” can even be dangerous.

On the other hand, perfection feels safe. But safety isn’t speed. And without speed even the best ideas stall.

This tension between the false safety of unnecessary perfection and the emptiness of meaningless progress is at the heart of this article. It explores a common leadership paradox: smart, motivated people who keep polishing, expanding or testing long after a task is “done.” It looks like commitment. It is often avoidance. In the following sections, we discuss why this topic is important and what research says about why this happens and how to help people escape this trap.

Why this matters

Perfectionism doesn’t just cost time. It blocks learning and slows innovation. Shipping creates feedback, alignment and real progress. Endless polishing creates delay. Whether you run a marketing team, a consulting project, a software program or an operations initiative, your role isn’t to make everyone “faster.” It’s to make them fast where speed is safe and flawless where perfection is truly required.

Leader’s lens: Treat perfectionism as a systemic issue (norms, incentives, risk framing) not a purely individual flaw.

What research tells us about perfectionism

Researchers consistently distinguish two faces of perfectionism:

• Perfectionistic strivings1 → setting high goals, striving for excellence. Can be positive when paired with clarity and support.

• Perfectionistic concerns2 → fear of mistakes, fear of judgment, self‑criticism. Drives stress, burnout, procrastination and unnecessary overwork.

Large scale reviews show: strivings correlate slightly with higher performance; concerns correlate with longer hours, stress and lower well being. In plain English: ambition helps, anxiety hurts.

Non linear reality: In complex work, more perfectionism isn’t always better. After a point returns can reverse as attention shifts from outcomes to impression management.

Why people overfulfill (across different contexts)

Think of overfulfillment as the cousin of procrastination dressed in a suit.

• Fear of judgment: “If I add more nobody can say I didn’t try.”

• Ambiguous finish line: Without a clear definition of “done”, people move the bar themselves.

• Comfort in craft: Polishing feels safer than facing feedback.

• Cultural norms: In “tight” contexts rough drafts look sloppy; in “looser” ones early sharing is pragmatic.

• History and incentives: If early shipping was punished last time sanding the edges forever feels rational.

• Remote/hybrid friction: Asynchronous comms slow feedback and increase “pre polish” to avoid misinterpretation.

Examples (general):

• A marketing team asked for a 5 slide pitch deck delivers 40 slides of appendices. Decision fatigue, no decision.

• A software team and product management delays release to “add just one more feature” missing real user feedback.

• A consultant rewrites a report repeatedly while the client still waits for actionable recommendations.

• A remote employee spends extra hours making a document “bulletproof” anticipating fewer chances to clarify later.

The psychology behind it

Perfectionistic concerns are tightly linked to procrastination: overpolishing delays evaluation. The mind trades the pain of possible critique for the comfort of extra effort. That comfort is expensive.

Spotting the pattern

• Work expands late in the cycle without a new requirement.

• Extra tests or sections appear without a risk based trigger.

• Team members hesitate to show version 0.53 drafts.

The Mental Model: Two zones, one brain

Divide work into two zones:

• Learning Zone (low risk) → Good enough, fast. Share v0.5 drafts, run quick pilots, expose assumptions early.

• High Stakes Zone (high risk) → 100% compliance. Legal, safety, finance or regulatory deliverables. Perfection isn’t optional.

Calibration ritual (2 minutes)

• Is this reversible? If yes → Learning Zone.

• What’s the worst credible downside? If high → High Stakes Zone.

• What is the cost of one more week? If high → ship sooner.

What to watch for (red flags of overfulfillment)

• Gold plating4: Adding unasked for features or sections that delay delivery.

• Silent polishing: Extra testing or editing without risk based rationale.

• Scope creep via quality: Spec unchanged, internal bar quietly rises.

• Volume as virtue: Far more material than requested.

Quantitative signals

• Lead time rising while scope stays flat.

• Review cycles per deliverable >2 by default.

• After hours work up, outcome metrics flat.

• Backlog aging (old items linger untouched).

How to lead people out of the “Perfection Trap”

Evidence informed moves you can start tomorrow:

1) Define “done” up-front

Use a one pager Definition of Done (DoD)5:

• Purpose (one sentence)

• Acceptance criterias (max 3)

• Non goals (what’s out of scope)

• Required artifacts

• Stop rule (“We stop when …”)

You can find a One-Pager Template for a Definition of Done (DoD) with examples in the end of this article.

2) Separate speed from safety

Use two way6 vs. one way7 doors:

• Two way (reversible) → bias for speed.

• One way (irreversible/high cost) → slow down, apply full checklist.

3) Put risk on the table

Add a 3 box impact/probability screen to planning. Low impact → ship and learn. High impact (legal, safety, finance) → 100% compliance.

4) Install a gold plating kill switch

For extras, ask: Who asked? Which outcome moves now? What’s the cost of delay8? Vague answers → backlog.

5) Normalize version 0.5 (especially remote)

Schedule v0.5 reviews. Reward early sharing. Make rough work safe.

6) Embrace Iteration and MVPs

Adopt an iterative and incremental mindset: deliver in small slices that create value fast. An MVP9 (minimum viable product) is not a half baked product; it is the smallest useful version that tests assumptions and generates feedback. In marketing this might be a landing page before a full campaign; in consulting it might be a 2 page outline before a 50 page report; in product development it might be a basic feature shipped to a pilot customer. Each iteration should answer a question, reduce uncertainty and inform the next step.

7) Build “Psychological Safety”

Psychological safety is a team climate where people feel safe to speak up, admit errors and share rough ideas without punishment. This debriefs focus on learning, not blame. Script: What was the goal? What changed in the numbers? What did we learn? What’s next and what do we stop?

8) Teach Satisficing

Satisficing means choosing an option that is “good enough” to meet the need instead of chasing the absolute best. Set explicit thresholds tied to outcomes (adoption, cycle time, error rate). “Perfect” isn’t a metric; “<2% defects” is.

9) Limit “Work in Progress” (WIP)

Cap parallel work (WIP10). Shorter queues reduce waiting and the urge to polish endlessly.

Where leaders accidentally reward perfectionism

• Praising volume over impact (“Impressive deck” vs. “This cut lead time by 12%”).

• Ambiguous asks (“Can you polish this?” → infinite scope).

• Slow feedback (encourages polishing while waiting).

• One checklist for everything (prototype vs. final deliverable).

• Leader modeling: Only showing perfect work teaches teams that rough drafts are unsafe.

Leader self check (quick audit)

• Do I share v0.5 myself?

• Do my asks specify length, scope, decision needed?

• Do I green light extras without an owner or metric?

When perfection is non-negotiable

Perfection isn’t always the enemy. In certain domains it’s essential:

• Healthcare and medicine: surgical procedures, drug safety.

• Aviation and aerospace: flight critical systems.

• Legal and finance: compliance and regulatory reporting.

• Safety critical engineering: emergency systems.

The art is context sensitivity: knowing when “done is better than perfect” and when “perfect or nothing” applies.

Possible critiques of this view (and how to respond)

• “You’re lowering standards.” → Not if you clearly mark High Stakes work. The point is differentiated standards, not lower ones.

• “You’ll demotivate high achievers.” → Keep strivings high; reduce concerns by making feedback faster and safer. Ambition stays, anxiety drops.

• “Culture eats process.” → True. That’s why leaders must translate expectations across tight/loose contexts and model v0.5 themselves.

• “Metrics miss the craft.” → Use metrics to spot signals, not to replace judgment. Pair numbers with narrative reviews.

Getting started (without overthinking it)

This week

• Define “done” visibly for one live task.

• Label open items “two way” or “one way door.”

• Add a stop rule to each deliverable.

This month

• 10 minute risk screen in planning.

• WIP limits on the team board.

• Run a premortem for one high stakes project.

This quarter

• Different checklists for prototypes vs. final deliverables.

• Ask managers to request v0.5 artifacts.

• Track lead time, review cycles, cost of delay and discuss monthly.

Final thoughts

“Done” isn’t sloppy. It’s purposeful. Be fast where speed creates value. Be uncompromising where human safety, compliance or fiduciary duty are on the line. Teams don’t need more pressure. They need clearer bars and the safety to stop when they’ve reached them.

Think back to Whiplash: the student’s obsession with flawless performance delivered a dramatic finale, but also left behind exhaustion and fear. In business the real masterpiece is not endless polish but the rhythm of iteration, learning and knowing when to stop.

Bonus: Definition of Done (DoD) One-Pager Template (PDF)

• Purpose (one sentence)

• Acceptance criterias (max 3)

• Non goals (what’s out of scope)

• Required artifacts

• Stop rule (“We stop when …”)

Definition Of Done One Pager Template V11

68.8KB ∙ PDF file

Download

Download

Use it. Print it. Share it. That’s how behavior changes.

Further Reading

• Aishwarya Bellam, Thomas Curran (2025): Perfectionism and Work Performance: A Meta Analysis

• Hewitt, P. L., Flett, G. L., Turnbull-Donovan, W., & Mikail, S. F. (1991). The Multidimensional Perfectionism Scale: Reliability, validity, and psychometric properties in psychiatric samples.

• Amy Edmondson: Psychological Safety and Learning Behavior in Work Teams

• Herbert Simon: Satisficing and bounded rationality

• Don Reinertsen: The Principles of Product Development Flow

• Jeff Bezos: Two way vs. One way door decision framework

Originally published on LinkedIn on 10.09.2025.

The parable

You´ve likely heard the story: five monkeys in a cage, a ladder and a banana. Each time a monkey climbs, the group gets sprayed with cold water. Soon, the monkeys police each other. Over time, every original monkey is replaced. None of the newcomers has ever experienced the cold water but, yet still, no one touches the banana. "That´s just how things are done here".

The truth behind the tale

As a literal experiment, this story never happened. Its roots trace back to a 1960s study by psychologist G.R. Stephenson, who used pairs of rhesus monkeys and air blasts, not bananas or ladders. Later retellings reshaped it into today´s parable. The fable survives because it illustrates something real: organizations often inherit behaviors and fears long after the original cause has vanished.

Why fear lingers in modern companies

1. Losses loom larger than gains. Humans overweight losses compared to equivalent gains (loss aversion1). In corporate contexts, "don´t get it wrong" often trumps "let´s try something bold".

2. The status quo feels safer. Faced with multiple options, people disproportionately pick the "do nothing" path (status quo bias2). That bias silently slows innovation.

3. Organizations remember even when people forget. Practices and norms outlive the people who created them. This "organizational memory3" ensures that outdated rules persist, even if the original risk is gone.

4. Small deviations become normal. Teams sometimes bend rules under pressure. If no crisis follows, those deviations harden into accepted practice, a process sociologists call "the normalization of deviance4".

5. Silence protects careers. Research on employee "voice5" shows how people self-censor in hierarchies. The risk of being wrong often outweighs the reward of speaking up. How often have you heard people say after a meeting: "I had the same thought, but I didn´t want to be the one to say it".

The cost of silence (and the upside of safety)

• Team learning rises with psychological safety6. Harvard research shows that teams where members feel safe to take interpersonal risks learn faster and perform better.

• Google confirmed it at scale. In "Project Aristotle", the single strongest predictor of team effectiveness was psychological safety (more than individual talent or experience).

• Error-friendly cultures outperform. Studies of "error management7" show that treating mistakes as learning opportunities leads to higher adaptability, better performance and less stress.

How fear plays out in everyday meetings

A product review. A bold idea appears on slide 12.

Someone recalls a failed attempt years ago (none of the current team was involved). Another warns about "optics".

No one asks: "What would have to be true for this to work?" The idea dies quietly.

What was missing? Not data or talent, but a design for safety, candor and learning.

Ten plays for leaders to unlearn inherited fear

1. Classify decisions as reversible vs. irreversible. Most are reversible ("two-way doors8"). Treat them with speed and lightweight process.

2. Decide at ~70% information. Replace "prove it first" with "learn it fast".

3. Run premortems9. Ask: "It´s six months later and we failed, what happened?" This surfaces risks early.

4. Make postmortems10 blameless and mandatory. Focus on learning, not blame.

5. Teach error management. Practice handling mistakes constructively in simulations.

6. Create stop-the-line rights. Borrow from Toyota: anyone can halt work when quality or safety is at risk.

7. Measure psychological safety. Use short pulse surveys and discuss results openly.

8. Change meeting contracts. Begin with: "Dissent is contribution". Actively thank the first person who challenges the group.

9. Challenge the status quo. Ask: "Why now?" and "What would we learn?"

10. Archive decisions with reasons. Ensure future teams inherit context, not just cautious habits.

But how do you know if these plays are making a difference? Culture shifts are subtle and leaders often wonder whether progress is real or just wishful thinking.

How to know it´s working

Culture change doesn´t happen overnight. But there are signs that fear is losing its grip:

• Decisions happen faster. Topics don´t circle endlessly in meetings; more "two-way doors" get tried quickly.

• More voices are heard. You notice contributions from quieter team members and not just the usual few.

• Experiments increase. Small pilots and tests become normal instead of rare exceptions.

• Postmortems feel lighter. People focus on what was learned, not who was at fault.

• Retention improves. Talented employees stay because they feel safe to grow and take risks.

If you start to see these patterns, it´s evidence that fear is no longer steering decisions, learning is.

Responsible use of the monkey story

The "monkeys and bananas" tale is a myth, but a useful metaphor. The real research did demonstrate how avoidance behaviors can spread socially, though under very different conditions. When retelling the fable, it´s wise to clarify its symbolic role and then pivot to evidence-backed practices.

Try this this week

• Label one upcoming choice a "two-way door" and make it quickly.

• Run a 20-minute premortem on your next project.

• Pilot a blameless postmortem on any recent incident.

• Add one pulse item to your retro: "On this team, it´s safe to take smart risks".

Bonus: Kill a Stupid Rule

I´ve personally had very positive experiences with a simple but powerful exercise: "Kill a Stupid Rule".

The method is described in Lisa Bodell´s book Kill the Company and is as straightforward as it is effective: Gather your team and ask one question:

"If you could kill one rule, process or guideline that slows us down or frustrates you, what would it be?"

At first, people hesitate. But once the first example is voiced (like a reporting routine no one reads or an approval step that adds no value) the floodgates open. Within minutes, the whiteboard fills with unnecessary rules, outdated practices, and "we´ve always done it this way" habits.

The magic lies in what happens next:

• Teams feel relief that they can finally voice frustrations without fear.

• Leaders discover hidden obstacles that were quietly draining energy.

• By removing or simplifying just a handful of rules, the team gains a sense of empowerment and speed.

How to run the exercise

1. Set the stage. Clarify that the goal is not to criticize individuals but to identify outdated, frustrating or pointless rules and processes.

2. Ask the core question. Write it on a flipchart or whiteboard: "If you could kill one rule, process or guideline that slows us down or frustrates you, what would it be?"

3. Collect ideas. Give everyone sticky notes or use a digital board. Let people write down as many "rules" as they can think of (quietly at first, then share with the group).

4. Discuss and cluster. Group similar ideas together (e.g., "too many reports", "pointless approval steps", "ineffective metings").

5. Evaluate with the matrix. Draw a 2×2 grid (see below): X-axis: Impact if the rule were removed (low → high), Y-axis: Ease of implementation (hard → easy). Place the rules in the grid. Focus first on the "Gold Rules" in the top-right corner (easy to remove, big effect).

6. Act on quick wins. Choose 1–3 rules to kill or simplify immediately. The faster you show results, the more credibility the exercise gains.

7. Review and repeat. Revisit the list after a few months. Some rules may be gone, others may have emerged.

I´ve seen this exercise shift the mood of an entire group. Suddenly, people realize: many of the "cold showers" we fear are not real, they´re inherited, outdated or self-imposed.

"Kill a Stupid Rule" works because it´s practical, fast and collective. Instead of vague calls to "be innovative", it asks: What´s one thing we can stop doing tomorrow that makes us better?

Closing thought

Cultures don´t change by slogans like "be brave". They change when leaders redesign how decisions get made, how mistakes get handled and how voices get heard. Do that and the invisible cold shower loses its power.

Further Reading

• G.R. Stephenson (1967), Cultural Acquisition of a Specific Learned Response Among Rhesus Monkeys

• Kahneman & Tversky, Prospect Theory (1979)

• Amy Edmondson, Psychological Safety and Learning Behavior in Work Teams (1999)

• Google´s Project Aristotle (2016)

• Diane Vaughan, The Challenger Launch Decision (1996)

• Michael Frese & N. Keith, Action errors, error management, and learning in organizations (2015)

Let’s start in the real world

Everyone saw the iceberg. The problem was: the slow down was too late. The Titanic didn’t sink because of bad luck, it sank because known risks were ignored, warnings went unheeded and there were no real processes to deal with crisis. In OT environments, it’s often the same: we know the risks, we see the signs, but we’re missing structure.

Picture this: It’s a regular Thursday morning at a high-speed bottling plant in southern Germany. Production is humming. Operators monitor multiple lines. Everything runs like clockwork until someone schedules a firmware update to the PLC1 that controls Line 3’s conveyor system. The update is approved informally and applied during a shift handover, assuming it won’t interfere with production.

Within 30 seconds, bottles start piling up and falling over. The line jams. A sensor fails to react. The entire cell halts. Operators respond quickly, but the issue isn’t immediately clear. There’s no detailed change log. No formal rollback strategy. No incident response plan tailored to this scenario. Downtime ticks on, with every minute costing thousands.

Now rewind the story, but imagine it in a typical IT context. A software patch is applied to a CRM2 server. Users can’t log in. But IT has a structured response:

• The issue is logged.

• An incident is opened.

• A change record links to the patch.

• A rollback plan exists.

• The team meets later to analyze what went wrong and how to prevent it.

Same logic, different world. This article explores why OT (Operational Technology) needs its own approach and how to borrow the best of ITIL3 without forcing a square peg into a round hole.

Why It Matters

In IT, a failed change might mean frustrated users. In OT, it could mean production losses, safety risks or regulatory violations.

OT systems run:

• Manufacturing lines

• Water treatment facilities

• Power generation

• Railway signals

• Building automation systems

And unlike IT, these systems were not designed with frequent change or rapid incident response in mind. Many still run legacy hardware or software not touched in over a decade.

But change is coming:

• Digital transformation is connecting OT systems to networks and clouds.

• Cyberattacks on OT environments are rising sharply.

• New compliance and safety standards demand structured operations.

You can’t wing it anymore. Even if your OT team isn’t big, you still need a playbook.

ITIL in a nutshell (for comparison)

ITIL (Information Technology Infrastructure Library) is the de-facto standard in IT for managing services, systems and processes. It defines:

A. Incident Management

• Restore normal service as quickly as possible.

• Log, prioritize, escalate, resolve and close.

• Examples: Server crash, user login failure, application error.

B. Change Management (now Change Enablement in ITIL 4)

• Ensure that changes are assessed, approved and implemented with minimal disruption.

• Risk assessment, CAB4 meetings, rollback plans.

C. Problem Management

• Identify and remove the root cause of recurring incidents.

• Conduct root cause analysis, track known errors.

It also introduces:

• Defined roles (e.g., Incident Manager, Change Manager)

• Workflows supported by ITSM tools (like ServiceNow or Jira)

• Focus on service quality, risk reduction and continuous improvement

The OT World: What's different? (simplified)

OT doesn’t lack discipline. But it has different priorities, constraints and historical context.

Key Differences:

Story Example: An IT team deploys weekly updates to improve user experience. In a paper mill, even rebooting a PLC may require halting production, draining tanks and safety clearance.

Frameworks that help in OT

Let’s look at the major frameworks and how they support structured incident, change and problem processes in OT environments.

A. IEC 62443 (especially part 2-1)

This is the leading global standard for OT cybersecurity and operational governance. Think of it as the OT equivalent of ISO/IEC 27001, but with safety and reliability front and center.

What it offers:

• Requirements for a Cybersecurity Management System (CSMS)

• Guidance on secure system design, integration, maintenance

• Maturity models for assessing process consistency

How it maps to ITIL-style processes:

• Change Management:

  • Documented change process

  • Impact and risk assessment required

  • Mandatory testing and rollback

• Incident Management:

  • Incident response plans

  • Defined escalation paths

  • Role-specific responsibilities (e.g. integrator, asset owner)

• Problem Management:

  • Root cause analysis as part of continuous improvement

  • Structured documentation of learnings

Use Case Example: A machine builder wants to update SCADA software at a client site. Under IEC 62443, they must submit a documented change request including:

• Purpose

• Risk assessment

• Test results

• Backup strategy

• Rollback plan

• Communication with all involved parties

B. NIST SP 800-82 Rev. 3 + NIST Cybersecurity Framework (CSF)

SP 800-82 is a U.S. publication, but globally respected. It applies the NIST CSF to OT systems.

Core functions:

• Identify: Asset inventory, roles, data flows

• Protect: Access control, maintenance, data integrity

• Detect: Anomalies, log monitoring

• Respond: Contain, analyze, report incidents

• Recover: Plans to restore systems and learn

How it aligns with ITIL-style logic:

• Clear steps for incident response and containment

• Encourages planning around configuration changes

• Emphasizes feedback loops for process improvement

Example: An oil pipeline control center detects odd valve behavior. Following NIST:

• Detect abnormal behavior (via logs or operators)

• Trigger incident response

• Isolate affected segment

• Notify stakeholders

• Analyze root cause

• Update system rules and training

C. ISO/IEC 27001 (with OT integration)

While not OT-specific, ISO 27001 can support security governance in OT, especially in regulated industries (e.g. pharma, energy).

• Supports structured risk management

• Can be combined with IEC 62443 for certification

Detailed comparison: OT vs. ITIL processes

Challenges in Bridging IT and OT

1. Language Barrier

   • IT talks services, SLAs, apps

   • OT talks loops, sensors, safety interlocks

2. Tooling Gap

   • IT has mature platforms; OT often lacks centralized tooling

3. Change Aversion in OT

   • Not cultural laziness, but safety-first thinking

4. Incident Visibility

   • Many OT incidents (e.g. unplanned stops) aren’t logged as such

5. Problem Follow-up

   • “We fixed it” often replaces “we understood why it happened”

Getting started (without overengineering it)

Starting structured OT processes doesn’t mean implementing ITIL overnight. It means building lightweight, useful habits that create clarity and reduce risk.

A. Build a simple Asset Inventory

• List your key control systems, their location, owner and purpose

• Track firmware/software versions

• Include critical dependencies (e.g. power, cooling, network links)

Why? You can’t manage changes or respond to incidents if you don’t know what you have.

B. Define roles and responsibilities (lightweight RACI)

Create a one-page matrix answering:

• Who approves a change?

• Who can execute it?

• Who needs to be informed?

• Who leads during an incident?

Tip: Keep it visual and post it near operator stations or control rooms.

C. Create a basic change checklist

Use paper, Excel or digital form. For each planned change:

• What is being changed?

• Why is it needed?

• What is the expected impact?

• Who tested it, where and when?

• What’s the rollback plan?

• When will it happen?

• Who approved it?

Bonus: Add a checkbox: “Will this impact safety, quality or regulatory compliance?”

D. Establish a simple Incident Response Playbook

For example:

1. Detection: Alarm, operator report, unusual behavior

2. Containment: Isolate the system if possible (e.g. unplug network cable)

3. Notification: Call pre-defined contacts

4. Documentation: What happened? When? What was done?

5. Recovery: Apply fix, validate functionality

6. Review: Document learnings

Deliverable: Print this as a laminated card and mount near SCADA workstations.

E. Introduce "Lessons Learned" Rituals

After any incident or failed change:

• Host a 20-minute team huddle

• Ask: What happened? Why? What can we improve?

• Write it down, even in a shared Word file or notebook

Cultural tip: Celebrate the fact that you reviewed, not that it was perfect.

F. Train using real incidents

Once a month, review a real event:

• Was it handled well?

• What would we do differently?

• Are our procedures clear?

Benefit: Makes documentation practical, not bureaucratic.

G. Build from the bottom up

Don’t wait for enterprise software. Use what you have:

• Excel or Google Sheets for tracking

• Printed forms for incident logs

• Shared folders for documentation

Once habits form, you can layer better tools later (e.g. asset management platforms, change tracking systems).

Why it’s more critical than ever to formalize OT processes (with verified data)

1. Rising Cyber Threats in OT amid IT/OT convergence

OT systems no longer run in isolation, they’re increasingly connected to IT and cloud environments. According to ITPro, ransomware and wiper malware incidents in OT environments rose sharply from 32% in 2023 to 56% in 2024. This trend reflects the growing vulnerability as barriers between OT and IT vanish.

Additionally, the 2025 Security Navigator Report noted a 39% increase in cyberattacks targeting OT systems between 2023 and 2024.

2. Critical infrastructure under fire

A Semperis survey, cited by Infosecurity Magazine, found that 62% of water and electricity operators in the US and UK were targeted by cyberattacks in the past year. Of those, 80% were attacked multiple times, 59% experienced operational disruption and 54% suffered permanent data or system damage.

3. Legacy OT Systems heighten risk

These environments often rely on decades-old hardware and software lacking patching, encryption or modern security controls, not designed for today's connected cybersecurity reality.

4. Regulatory pressure and need for resilience

Governance expectations now include proactive security and process documentation. In the EU, this pressure is mounting through directives like NIS 2 (Network and Information Security Directive) and the Cyber Resilience Act (CRA).

• NIS 2 requires operators of essential and important entities to establish structured cybersecurity risk management, incident reporting and governance processes, including for OT systems.

• CRA mandates secure-by-design principles and lifecycle cybersecurity controls for connected devices and industrial products placed on the EU market.

In the U.S., the EPA reports that as of late 2024, 97 drinking water systems serving 26.6 million people have critical or high-risk vulnerabilities, raising the bar for OT resilience planning.

5. Reputational and Business Continuity costs

It's no longer just downtime, it’s trust, safety and financial fallout. And the stakes are only rising, as seen in recent utility and critical infrastructure breaches.

6. Building resilience through process discipline

Structured processes (change control, incident response, root-cause reviews) become resilience enablers. Organizations that manage without them risk repeating mistakes.

Summary table: Why process maturity in OT is non-negotiable today

Final Thoughts

You don’t need to force ITIL into OT. But you can (and should) build a process culture that reflects the same ideas:

• Plan before you change.

• React quickly and safely when things go wrong.

• Learn and improve after every event.

Frameworks like IEC 62443 and NIST SP 800-82 give you guidance adapted to the realities of OT, where systems are physical, risks are real and failure isn't just an error message.

Start small. Be pragmatic. Involve your people. And over time, bring structure to the chaos without getting in the way of the work.

What else should be considered? (important additions)

To round out the picture, here are additional key areas that make your OT process model robust and future-proof:

A. OT-Specific roles and responsibilities

While ITIL has clearly defined roles, OT environments often operate with lean teams. Still, clarity is critical.

Typical OT Roles:

• Asset Owner - Responsible for lifecycle decisions and approvals

• Control System Engineer - Designs and maintains the automation logic

• Maintenance Lead - Manages availability and response to technical failures

• OT Security Lead - Aligns security controls with process needs

• System Integrator - Executes changes across multiple systems or vendors

Why this matters: Clear roles avoid confusion in high-pressure situations and improve coordination with IT.

B. Change testing and validation in OT

Unlike IT, OT systems can rarely be duplicated for test environments. That doesn’t mean testing is optional.

Options in OT:

• Simulation mode: Some controllers offer a virtual run-through

• Offline testing: Use spare hardware or cloned PLCs

• Shadowing: Monitor a proposed change in read-only mode first

• Digital Twin: Advanced but effective for complex plants

Goal: Always validate logic and side-effects before deploying to production.

C. Cross-functional integration

Change or incident processes in OT don’t happen in isolation. They must align with:

• Production planning: To schedule changes without disrupting OEE

• Quality assurance: To validate product integrity post-change

• Health & Safety: To ensure safe work procedures during interventions

Tip: Involve these functions early in your templates or workflows.

D. OT-specific KPIs and metrics

If you can’t measure it, you can’t improve it. But classic IT metrics often miss the mark in OT.

Useful OT Metrics:

• Change Success Rate (CSR) - % of changes without rollback or incident

• Mean Time to Repair (MTTR) - Average recovery time from incidents

• Unplanned Downtime per Line/Asset - Tracks stability over time

• Recurring Incident Rate - Helps identify weak spots in root cause work

Use: Simple Excel dashboards can suffice at first.

E. Tools and practical workarounds

Not every OT environment has a ServiceNow license. But you don’t need one to get started.

Practical Tools:

• Excel/SharePoint: Use structured templates with dropdowns

• Paper-based logs: Still useful in field operations

• Shift logs: Expand them to capture incidents and changes

• Low-code apps: Use tools like Microsoft Power Apps for forms

Key is consistency, not sophistication.

F. Maturity Model for OT process adoption

Where are you today and where do you want to be?

Advice: Aim for Level 3 before considering software or certification.

A note for Experts: What this article is and isn’t

This article is not a blueprint for compliance or a substitute for deep technical security architecture. It’s a practical guide for OT leaders, plant managers and technical decision-makers who need to bring more structure into environments where safety, reliability and legacy constraints shape reality.

Yes, every plant is different. Yes, not all IEC 62443 parts apply equally to every sector. And yes, ITIL wasn’t made for PLCs or real-time loops. But the core message stands: in modern OT environments, lack of structured processes is no longer defensible. Not operationally, not legally and not in front of your customers.

The goal here is clarity, not completeness. The analogies are deliberate simplifications, because a well-run shopfloor needs clear thinking more than it needs buzzword fluency.

If you're already operating at Maturity Level 4+, this article probably isn’t for you. But if you're somewhere between tribal knowledge and Excel sheets, this might just help get the next conversation started.

Further reading & resources

• IEC 62443 Overview (Wikipedia)
  General introduction to the standard series, structure and terminology.

• Understanding IEC 62443 (IEC Blog)
  Official blog explaining the scope and applications of the standard.

• NIST SP 800-82 Rev. 3 (Final Guide)
  The latest NIST guide to securing OT systems, aligned with CSF.

• ITIL Overview (Wikipedia)

  General introduction to ITIL and it’s processes

What if programs talk to programs?

In The Matrix Reloaded, Neo discovers something unsettling: the real conversations aren’t between people. The Oracle, the Merovingian, Agent Smith, they are programs talking to programs, plotting and scheming in ways humans can’t follow.

Now ask yourself:
When you scroll through your feed tonight, how sure are you that you are reading humans and not scripts talking to scripts?

That’s the essence of the Dead Internet Theory: the suspicion that the web is no longer driven mainly by people, but by bots, algorithms and AI, endlessly talking to each other while we just hear the echo.

From human forum to scripted stage

Think of the internet as a café.

• 2005: Messy but alive. Forums full of rants and long threads, Blogs linking to strange corners of the web, YouTube full of shaky home videos. Imperfect, unpredictable and human.

• 2025: Still noisy, but uncanny. The same phrases repeat. Comments look copy-pasted. Laughter sounds synthetic. Half the crowd are mannequins, nodding, clapping or arguing on cue.

That’s what “dead” feels like: full of activity, but thinner in authenticity.

Why should people with authority care?

This isn’t philosophy. Its about trust in digital signals: the numbers and voices you rely on for decisions.

• Are those glowing reviews genuine or is it a click farm?

• Does a spike in likes mean traction or scripts gaming the feed?

• When a hashtag trends, is it a public opinion or a machine-made echo chamber?

If half the signals are synthetic, strategies risk being built on illusions.

How fake is the Internet really?

Key numbers

• 49,6% of web traffic (Imperva, 2023) comes from bots (nearly half of everything online is automated).

• 9–15% of X (Twitter) accounts (Varol et al., 2017) were bots and they amplified missinformation disproportionately.

• Generative AI flood (2025, arXiv:2502.00007): researchers argue that feeds are increasingly dominated by AI-generated, engagement-optimized content… cheap, repetitive and less authentic. Exact percentages are not yet available.

• “Crisis of perception” (OCAD University, 2025): even if humans still post in large numbers, the uncertainty itself (“is this real or synthetic?”) erodes trust and makes the internet feel hollow.

So no, the internet isn’t literally dead. But it is noisier, faker and harder to trust.

The feedback loop we should talk about

Here’s the deeper risk: the shift from Input → AI → Output to AI → Output → AI.

• Today: AI is trained mostly on human input: text, images, conversations.

• Tomorrow: AI will train more and more on its own output.

• Result: A feedback loop. Content becomes blurier, repetitive, less tied to reality.

It’s like photocopying a photocopy. Each iteration loses detail. Eventually you end up with noise that only resembles reality.

This is the nightmare version of the Dead Internet: not just bots filling space, but bots teaching bots to sound human, while humans quietly step aside.

Everyday signs of the Synthetic Web

• Your analytics dashboard spikes with 10.000 clicks overnight, but half are scrapers, another chunk spam-bots.

• Comment sections filled with “So true!” and “Thanks for sharing!”. Polished, lifeless, probably scripted (or prescripted one-click statements).

• News feeds dominated by weird AI memes (Shrimp Jesus, endless “Amen” spam).

This is what happens when programs clap for programs.

The biggest missunderstanding

• Myth: The internet has been fully taken over by AI, the humans are gone.

• Reality: Humans are still everywhere, but their voices are diluted in the machine chorus.

Think haunted house, not corpse: still alive but crowded with ghosts.

How to stay sane in a Synthetic Web

• Don’t trust raw metrics. High engagement doesn’t always mean real people.

• Spot bot patterns: repetitive phrasing, no nuance, machine-like timing.

• Prefer smaller, human-first spaces: moderated forums, niche newsletters, Discord groups.

• Value human messiness: typos, personal anecdotes, weird tangents (things bots still struggle to fake).

• Push for transparency: clear AI-content labels and bot disclosures.

Quick Toolkit

Three questions to ask yourself

1. How much of what I read today came from real people?

2. Which of my online spaces still feel genuinly human?

3. Am I producing for humans or feeding algorithms?

Four Bot tells

1. Repetitive, overly polished phrasing

2. No real-world detail

3. Identical posting rhythm

4. No follow-up, no curiosity

Two things you can do this month

1. Audit your feeds and traffic. Look for patterns that don’t make sense.

2. Support and share human voices: blogs, indie creators, communities.

Back to the Matrix

The Dead Internet Theory resonates because it feels like The Matrix: programs talking while humans just overhear.

But unlike Neo, we don’t face a predetermined fate. We still have a choice:

• Take the blue pill: keep scrolling, let manequins fill your feed, accept synthetic chatter as normal.

• Take the red pill: seek out authenticity, amplify real voices, keep the café alive with messy, unpredictable human energy.

The internet isn’t dead. But if AI keeps training mainly on AI, its soul could fade faster than we expect.

A nuanced closing thought

It’s worth stressing: the Dead Internet Theory is not a proven fact. Much of the internet is still undeniably human, from open-source developers to niche Discord servers to messy debates on Reddit. The statistics on bots and AI content don’t mean people are gone. They mean the line between human and machine is blurrier, and perception matters as much as reality.

What fascinates me most is how this plays out not just on a macro scale, but in daily life. E-mail threads are already drifting into AI-to-AI exchanges, smart reply suggesting one templated phrase, the recipient’s client answering with another. Among teenagers, the same pattern shows up in messaging: AI-generated suggestions are accepted with a single tap because speed and parallel conversations matter more than originality. Eight friends can sit around one table, each glued to a screen, their chats reduced to quickfire machine-authored snippets. The chance for real conversation is there, but often left unused.

That, to me, is why the Dead Internet Theory is such a compelling metaphor. Whether you see it as conspiracy, critique or warning, it forces us to ask: What counts as authentic? What doesn’t? And how much of our digital life are we willing to hand over to scripts that speak for us? Or is it completely fine and we just have to live with it?

Discussion starter

When you scroll, do you still feel the human pulse or mostly machine chatter?

Further Reading

• Imperva (2023): Bad Bot Report

• Varol et al. (2017): Online Human-Bot Interactions

• Rzemieniak & Sułkowski (2025): The Dead Internet Theory: A Survey on Artificial Interactions

• OCAD University (2024): Between the Self and Signal: The Dead Internet & a Crisis of Perception

• The Guardian (2024): Where does the line between person and bot begin?

Top Gun for Industrial Systems

Remember the final mission in Top Gun: Maverick? Maverick and his team fly through a narrow canyon at breakneck speed, dodging missiles and anti-aircraft fire. Every movement is life or death. There’s no time to call HQ and wait for instructions. The pilots must make split-second decisions based on what they see and feel right there in the cockpit.

But while the edge team flies the mission, command plays a vital role. They're tracking radar, assessing threats, rerouting flight paths and coordinating extraction. The mission depends on both: real-time action at the edge and strategic oversight in the background.

Smart factories work the same way. Your production line (like Maverick’s jet) needs to react instantly. Shut off a valve. Adjust a torque. Catch a defect. But at the same time, your cloud systems are watching across shifts and sites, optimizing for efficiency, spotting trends and fine-tuning the plan.

Just like in the movie, the magic happens when both worlds, edge and cloud, work together.

So: Should you process data right at the machine? Or send everything to the cloud? Or both?

Let’s break it down.

Why this isn’t just a tech decision

Where data gets processed isn’t just a question for IT teams. It directly impacts your response time, operating costs, system resilience and cyber risk. In production, milliseconds matter. If a problem isn’t caught in time, you risk scrap, downtime, or worse.

Typical trade-offs:

• Too much data in the wrong place creates network congestion, inflates cloud storage costs and slows down response times.

• Too little logic at the edge means you're vulnerable to disconnection and miss real-time insight.

• Full cloud reliance introduces latency, dependency and single points of failure.

• Unsecured endpoints or loose connections turn into open doors for attackers. Every sensor and gateway is a potential risk, unless designed with security in mind.

The goal? Match each task to the right computing layer using modular, interoperable building blocks with built-in security.

The three places data can live

1. Edge: Right there at the machine

Edge computing means processing happens near the data source, on a PLC (programmable logic controller), IPC (industrial PC), or smart gateway. These are essentially the local “nervous systems” of a machine. Modern edge nodes can host containerized services1 (small, self-contained apps) run local AI models and communicate securely with upstream systems.

Example: A motor overheats. The edge device kicks on a cooling fan, logs the event and sends an alert upstream. All within milliseconds.

Use it for:

• Fast machine control and safety interlocks

• Visual inspection and rejection logic

• Operator dashboards

• First-level anomaly detection and filtering

• Executing AI models close to the process

2. Cloud: The strategic HQ

Cloud systems are the strategic layer. They aggregate, store and analyze data across sites. Ideal for dashboards, AI training and remote diagnostics.

Cloud comes in multiple forms:

• Public Cloud (shared): affordable, quick to scale, but shared infrastructure.

• Virtual Private Cloud (VPC): a private space in a public cloud. Better isolation, still scalable.

• Private Cloud: fully dedicated, often used in regulated environments.

• Hybrid Cloud: combines cloud with on-prem assets for flexible strategies.

Example: After 3 months of data collection, the cloud identifies early wear in machine bearings and sends updated maintenance rules to the edge.

Use it for:

• KPI dashboards

• Predictive analytics

• Asset onboarding

• Model training and orchestration2

• Identity and certificate management

3. Hybrid: The best of both worlds

Hybrid setups combine the local speed and autonomy of edge with the scalability and oversight of cloud. But they only work if interfaces are standardized and security is integrated.

Example: Edge detects a pressure spike and reacts locally. Later, the cloud correlates this with humidity across plants and refines AI rules.

Use hybrid for:

• Coordinated AI model updates

• Shared metrics across factories

• Secure, governed data sharing

• Transparent and maintainable control logic

What this looks like on the Shop Floor

Edge: Flow meters adjust fill levels in real time. Misaligned caps? A vision system catches and diverts them.

Cloud: Logs from all lines flow into dashboards. You notice one line uses 8% more CO₂… time to optimize settings.

Hybrid: A new AI model, trained centrally, is pushed to all edge devices. Reject rates drop by 12%. Machines are managed remotely but operate independently. All updates are secure and authenticated.

How to decide what goes where

• Emergency stop: Edge

• KPI reporting: Cloud

• Visual anomaly detection: Edge/Hybrid

• On-line operator interfaces: Edge

• AI model training: Cloud

• AI inference: Edge or Hybrid

Ask yourself:

• What happens if the connection drops?

• How time-critical is the task?

• Who needs to access the data?

• What security/privacy rules apply?

• Can devices self-register securely?

• Is centralized lifecycle management possible?

Common pitfalls (and how to avoid them)

• Thinking edge is optional. Even small gains in local intelligence reduce risk and cost.

• Sending raw data to cloud. It’s noisy, expensive and unnecessary.

• Building bespoke solutions. Start with modular, standards-based components.

• Skipping orchestration. Orchestration means managing devices, apps and updates centrally. Don’t leave edge devices unmanaged.

• Neglecting security. Secure boot3, signed updates, zero trust4 (i.e., every device must authenticate every time). This isn’t optional anymore.

Getting started (without a Five-Year Plan)

1. Start with a real problem: waste, downtime, quality.

2. Check what data already exists.

3. Add local intelligence where every second counts.

4. Connect only what’s needed, securely and modularly.

5. Describe your assets in ways machines can understand (semantic models5).

6. Enable remote updates, monitoring and rule deployment (ideally through a central platform that lets you manage fleets of devices securely, push configuration changes, deploy containerized workloads and roll out updates across many sites with minimal manual effort).

7. Bake security into every layer, not just the perimeter.

8. Prove success in one cell, then scale it.

The role of AI and why architecture matters

• AI needs data and clean, structured data at that.

• Train in the cloud, but execute at the edge.

• Use learning loops: edge detects, cloud analyzes, model evolves.

• Federated learning6: machines train models locally and only share the result (not raw data) saving bandwidth and improving privacy.

• Edge AI orchestration: With containerized AI runtimes, the edge becomes a dynamic platform that updates itself.

• AI and security: AI can also monitor for anomalies, detect cyber threats and adapt defenses, if it has trustworthy, real-time data.

Your AI roadmap is only as good as your architecture. If your edge and cloud aren’t ready, your models won’t deliver.

What might change tomorrow?

Technology evolves and so will the balance between edge, cloud and hybrid. Here’s what could shift in the next few years:

• AI models will shrink and specialize
  Expect more compact, task-specific models running at the edge, even on low-power devices. This means faster reactions, lower latency and greater privacy.

• Self-managing systems will become standard
  Devices will self-discover, auto-register and update automatically. No manual setup, no Excel lists. Ideally, this is supported by a central platform that handles device onboarding, identity management, remote monitoring and fleet-wide updates securely and efficiently.

• Cyberattacks will move closer to the machine
  As edge devices gain power, they also become targets. Security will need to shift left. Treating endpoints like critical infrastructure.

• Federated learning will mature
  Devices will train models locally and share only the learnings. Privacy stays intact, bandwidth stays low and systems get smarter together.

• Cloud will shift toward control, not just storage
  Think of the cloud less as a database, more as a control tower orchestrating fleets of devices, AI logic and updates in near real time.

• Low-code/No-code will reach the shopfloor
  Even complex logic or model deployment will happen via graphical interfaces. No Python, no scripting, just reusable building blocks.

For experts: What we didn’t say (but you know)

This guide is meant to give clarity, not cover every edge case. But if you're deep in the trenches, here are a few things we simplified:

• Edge vs. Cloud isn’t binary. There’s also fog computing, distributed cloud and hybrid edge tiers. We kept it clean for readability.

• Containers at the edge aren’t push-button. You’ll need hardened runtimes, real-time capability and orchestration that plays nice with industrial hardware.

• AI inference isn’t just about latency. Model size, data sensitivity, power budgets and bandwidth all matter.

• Federated learning sounds great, but adoption is early. Industrial examples exist, but it's still a frontier, not a norm.

• Zero Trust spans more than certificates. Think: micro-segmentation, behavior-based policies and secure credential rotation.

• Semantic modeling isn’t plug-and-play. Agreeing on what "status", "speed", or "temperature" mean across vendors is half the battle.

Want to talk architecture, orchestration, or protocol stacks? Let’s connect no slides needed.

Final Thoughts

There’s no universal answer. But there is a golden rule: let each layer play to its strengths.

• Edge = fast, local, independent.

• Cloud = strategic, analytical, scalable.

• Hybrid = real-world resilience and adaptability.

Build with AI in mind. Design for security. Start where it hurts.

The smarter your system is about where it thinks, the smarter your team can be about how it acts.

Further Reading & Resources

• Development Guideline for Open Edge Computing (OI4)

• Technical Solution Design Principles (OI4)

• Industrial IoT & Edge Computing – Overview (Hilscher)

• Edge Gateways with Container Management (Hilscher)

• MDPI Review: Cloud, Edge and Hybrid Architectures in IoT (mdpi.com)