Category: Corporate Culture

An ancient taxonomy for very modern dysfunction

The original seven deadly sins endure because they describe human failure modes, not theology. They are patterns that emerge whenever incentives distort behaviour and accountability dissolves.

That makes them an uncomfortably precise model for corporate culture.

Below, each sin is paired with its mirrored virtue. Not as moral advice, but as a design contrast. Each virtue is simply what the system would need to reward for the sin to disappear.

1. Greed

Cross charging and the internal market delusion

Greed in corporates rarely looks like personal enrichment. It shows up as local optimisation disguised as financial discipline.

Internal cross charging institutionalises greed. Teams hoard budget, defend cost centres, and monetise cooperation. Helping another team becomes a financial decision rather than a professional one. Architects meter advice. Engineers decline fixes. Everything becomes “out of scope”.

This is not cost control. It is value destruction with an accounting veneer.

Greed teaches teams to protect their slice even when the whole organisation bleeds.

Mirrored virtue: Shared ownership
Healthy organisations fund outcomes, not silos. Collaboration is free, expected, and rewarded because the system optimises for the whole, not the ledger lines.

2. Sloth

Meetings for the sake of meetings

Sloth is not laziness. It is avoidance of meaningful effort.

Corporate sloth manifests as calendar saturation. Meetings replace thinking. Updates replace decisions. Presence replaces contribution. People attend endlessly, speak little, challenge nothing, and leave exhausted without progress.

Meetings exist because it took weeks to get diaries aligned, not because there is something worth deciding. The act of meeting becomes the work.

Sloth hides behind busyness. It feels productive. It is not.

Mirrored virtue: Deliberate action
Effective organisations value decisions over updates, thinking over attendance, and written clarity over spoken noise. If a meeting does not change reality, it does not exist.

3. Pride

Management layers, titles, and the cult of oversight

Pride is excess self importance. In corporates, it shows up as hierarchy inflation.

Delivery leads, program managers, project managers, analysts, coordinators, change managers, portfolio managers all orbit a shrinking core of people who actually build anything. Each layer convinced it adds “strategic oversight”.

Pride insists that work cannot possibly happen without supervision, reporting, and escalation. It cannot imagine professionals being trusted to do their jobs.

The irony is brutal. The more layers added to improve control, the less anyone understands what is actually happening.

Mirrored virtue: Humility of structure
Strong organisations minimise layers, push authority to where the work happens, and accept that clarity comes from proximity, not titles.

4. Envy

Framework worship and the copy paste enterprise

Envy is not wanting improvement. It is wanting what others appear to have without understanding why it works.

Corporates envy Silicon Valley velocity, startup agility, and tech company mystique. Instead of building capability, they buy frameworks. SAFe, COBIT, RACI, operating models, maturity assessments imported wholesale.

Envy produces imitation without comprehension. Complexity without context. Process without purpose.

The result is ceremonial agility and industrial scale theatre.

Mirrored virtue: Understanding before adoption
Mature organisations design systems that fit their reality. They learn principles, not rituals, and build capability instead of borrowing ceremony.

5. Wrath

Governance as punishment

Wrath appears when control mechanisms are built around fear instead of trust.

Security teams break collaboration tools. Risk teams ban sharing. Compliance teams weaponise policy. Every incident triggers another control, another gate, another form.

This is not risk management. It is organisational anger made structural. Someone, somewhere, once did something wrong, and now everyone must suffer forever.

Wrath creates brittle systems. People route around controls. Shadow IT explodes. Governance responds with more wrath.

Mirrored virtue: Proportionate trust
Healthy governance enables safe speed. Controls are designed to reduce risk without destroying flow, and professionals are trusted unless proven otherwise.

6. Gluttony

Eating capability instead of growing it

Gluttony is not hunger. It is excess consumption that weakens instead of strengthens.

In corporates, gluttony shows up as relentless outsourcing. Vendors, consultants, systems integrators, and partners are consumed in volume, not to transfer skill, but to avoid building it.

The organisation keeps eating, but nothing nourishes it.

Thinking is outsourced. Delivery is outsourced. Architecture is outsourced. Even accountability is outsourced. Knowledge never settles. Capability never compounds. Over time, the inside hollows out and is replaced with contracts.

This is why heavily outsourced organisations become immobile. They have consumed so much external help that they have digested their own ability to act.

Mirrored virtue: Capability compounding
Resilient organisations keep critical skills close, use vendors tactically, and ensure every engagement leaves them stronger than before.

7. Lust

Performative alignment and the desire to be seen agreeing

Lust is misdirected desire. In corporates, it is the desire for approval, visibility, and promotion.

Clear thinkers are dangerous. Dissent is risky. Agreement is safe. So people align early, loudly, and often. They repeat talking points. They echo leaders. They perform belief.

This is how organisations achieve unanimous support for terrible ideas and express shock when they fail.

Lust for approval kills truth long before failure is visible.

Mirrored virtue: Intellectual honesty
High performing cultures reward clear thinking, respectful dissent, and truth over harmony. Disagreement is treated as signal, not threat.

Conclusion

Design determines behaviour

These sins are not accidents. They are the predictable outcome of systems that reward the wrong things.

Greed replaces collaboration. Sloth replaces thinking. Pride replaces accountability. Envy replaces understanding. Wrath replaces trust. Gluttony replaces capability. Lust replaces truth.

The virtues are not inspirational slogans. They are design choices. When systems reward the virtues, the sins wither on their own.

Most organisations never change the system. Then they act surprised when nothing improves.

Or: How Organisations Confuse Accountability with Paperwork

1. They optimise for defensibility, not outcomes

COBIT and RACI exist to answer one question extremely well: “Can we prove someone was responsible?” They are almost entirely indifferent to the harder question: “Did anything improve?”

Both frameworks reward traceability over truth. If an initiative fails, the organisation can point to a process, a role, a sign off, or a control and say “we followed the framework.” That is not governance. That is legal cover.

Good systems reduce the need for defence. COBIT and RACI exist because the system is already broken.

2. They assume work is static, predictable, and decomposable

RACI assumes you can clearly define who is Responsible, Accountable, Consulted, and Informed before meaningful work begins. COBIT assumes risks can be identified, controlled, and monitored as stable artefacts.

Neither assumption survives contact with real software, real customers, or real uncertainty.

In discovery heavy work, responsibility moves. Accountability shifts. Knowledge evolves. Frameworks that freeze responsibility early guarantee misalignment later.

3. They separate authority from knowledge

RACI diagrams almost always assign accountability to the least informed person in the room. COBIT governance structures almost always sit furthest from the code, the customer, and the failure modes.

This produces a predictable outcome. Decisions are made by people who cannot observe the system they govern.

When authority is disconnected from understanding, frameworks rush in to fill the gap. They do not fix the gap. They institutionalise it.

4. They create the illusion of clarity while hiding real ambiguity

RACI charts look precise. COBIT process models look rigorous. In reality, they mask unresolved questions.

Who actually decides when trade offs collide?
Who absorbs risk when controls conflict with delivery?
Who intervenes when accountability exists only on paper?

The framework answers none of these. It just makes the ambiguity harder to challenge.

5. They punish the people closest to the work

When something goes wrong under COBIT or RACI, the investigation rarely asks whether the system design was flawed. It asks whether the process was followed.

Engineers and delivery teams become risk vectors to be controlled, audited, and constrained. Leadership becomes abstracted, protected, and insulated.

Any framework that consistently burdens the most knowledgeable people while shielding the least informed is organisationally corrosive.

6. They scale paperwork faster than capability

As organisations grow, COBIT and RACI scale linearly in documents and exponentially in overhead. Every new initiative requires more matrices, more controls, more sign offs, more evidence.

What does not scale at the same rate is judgement, context, or engineering maturity.

This is how large organisations become simultaneously slow, expensive, and fragile while insisting they are “well governed.”

7. They turn conversations into artefacts

Healthy organisations resolve ambiguity through dialogue. COBIT and RACI replace dialogue with documentation.

Decisions are no longer debated, they are recorded. Disagreements are not resolved, they are escalated. Learning is replaced with compliance.

Once everything becomes an artefact, people stop thinking out loud. They start writing defensively.

8. They reward performative alignment

RACI charts encourage head nodding consensus. COBIT governance forums encourage “alignment” without challenge.

Disagreeing with a framework feels like disagreeing with governance itself. That is why bad ideas survive so long inside “well governed” organisations.

When alignment is valued more than truth, frameworks become tools for social control, not organisational effectiveness.

9. They are irresistible to consultants for all the wrong reasons

Both COBIT and RACI are abstract, adaptable, and never truly complete. This makes them perfect consulting substrates.

There is always another maturity assessment to run, another operating model to refine, another RACI to “clean up.” None of this guarantees better systems. All of it guarantees billable hours.

Frameworks that create permanent demand for interpretation should trigger suspicion, not trust.

10. They mistake control for competence

The most dangerous belief underpinning COBIT and RACI is this. If we define enough roles and controls, competence will emerge.

It never does.

Competence comes from practice, feedback, ownership, and proximity to consequences. Control frameworks can only constrain incompetence. They cannot create excellence.

Organisations that rely on COBIT and RACI are not well governed. They are afraid to trust people who know what they’re doing.

Closing thought

COBIT and RACI are not neutral tools. They encode a worldview where mistrust is rational, ambiguity is dangerous, and paperwork is safer than judgement.

If your organisation needs them to function, the problem is not missing frameworks. The problem is missing understanding.

The irony is brutal. The more you govern through abstraction, the less governable the system becomes.

In One Flew Over the Cuckoo’s Nest, the story is set inside a psychiatric institution run not for healing, but for control. The ward is orderly, predictable, and calm on the surface. Patients follow rigid routines. Group therapy sessions exist, but nothing meaningful ever changes. Any behaviour that challenges the system is treated as dangerous. Non conformity is labelled dysfunction. Over time, the patients lose confidence in their own judgment and begin to police themselves.

The most disturbing part of the film is not the cruelty. It is the learned helplessness. The patients eventually cannot imagine life outside the ward. Even when escape is technically possible, the institution has already done its work. It has removed their ability to think independently.

Agile and SAFe followed the same arc.

What started as a rebellion against heavyweight, bureaucratic delivery models quietly became an institution of its own. Ceremonies replaced thinking. Compliance replaced judgment. And teams learned that it was safer to follow the routine than to ask whether the routine still made sense.

The tragedy is not inefficiency. The tragedy is that agile lobotomised teams.

Red carpet treatment for the Trojan Horse

Agile and SAFe turned out to be a Trojan horse.

We welcomed it willingly. We embraced the principles, the philosophy, the promise of empowered teams, faster feedback, and less bureaucracy. Compared to the heavyweight processes that came before, agile felt humane, pragmatic, even rebellious.

The danger was never the principles on the outside, but the machinery hiding inside them.

Once agile crossed the drawbridge, it did not stay small. It unpacked ceremonies, roles, artefacts, certifications, governance layers, and an entire industry dedicated to telling us we were “doing it wrong”. The principles were quietly replaced with rituals. Judgment was replaced with compliance. Thinking was replaced with process adherence.

By the time teams realised what had happened, the gates were already closed.

Questioning the system became heresy. Removing ceremonies was labelled risky. And any failure was blamed not on the model itself, but on insufficient belief, insufficient coaching, or insufficient adoption.

The Trojan horse did not destroy delivery overnight. It did something far more effective. It convinced teams that this was what good looked like.

1. The Lobotomy: How Agile Stopped Teams Thinking

After years inside the agile ward, many teams can no longer imagine how work would happen if you removed the rituals.

Take away the stand ups, sprint planning, refinement, retrospectives, PI planning, demos, and governance layers and there is genuine anxiety. Silence. Confusion.

So they ask the question the institution has trained them to ask:

“If not agile, then what?”

This is the wrong question.

It is the question of someone who has been conditioned to follow a routine, not to reason about outcomes.

The correct question is the one the institution discourages:

How do we ship product better?

Shipping product is the equivalent of leaving the ward. It means ideas becoming working software in the hands of users. It means learning from production, not from meetings. It means optimising for flow, safety, and speed, not for audit friendliness or ritual compliance.

When teams ask “if not agile then what?”, what they are really saying is that the process has become their operating system. Remove it and they no longer know how to think about work.

That is institutionalisation.

Agile did not just add overhead. It replaced judgment with ritual. Over time, the rituals stopped being a means to an end and became the end itself.

2. Enter the Ward: Sit With the Team

In the film, escape does not begin with policy reform. It begins with someone walking the floor and seeing the reality.

Do the same.

Sit with the team. Watch how work actually moves. Ignore Jira. Ignore reports. Ignore governance decks. Follow a single piece of work from idea to production and observe how often it stops moving.

Then ask the questions institutions avoid.

What constraints are slowing you down? Which of these are real, and which exist simply because nobody has challenged them? Can they be engineered out rather than managed around?

What tools are missing, broken, or imposed? Tooling friction compounds just like technical debt, yet most organisations pretend it is neutral.

Can the team make decisions without escalation? If every meaningful decision requires permission, speed is impossible regardless of how many ceremonies you run.

Do they understand the business they operate in? Not the project. The business. Revenue, costs, clients, regulation. Teams without context optimise locally and damage the whole system.

If something goes wrong, will testing catch it? Or will a customer discover it first? Testing is not about quality. It is about moving fast without fear.

Do they have real observability? When production breaks, can they see it immediately, understand it, and fix it without a war room? If not, your deployment frequency is capped.

Is the team composition correct for the task? Many teams are full of supervisors and coordinators, but short on people actually building, testing, and operating the system. This is organisational sedation masquerading as structure.

3. Hand the Keys Back to the Patients

In the film, control is maintained by denying agency. Agile does the same, just with nicer language.

To escape, you have to reverse that.

Once you have completed a deep review of constraints, stop prescribing solutions. Ask the team, and each functional area within it, to propose how they will ship product going forward.

Not how they will comply. How they will ship.

Their proposal should explain how work is shaped, how it flows, how it is tested, how it is deployed, and how failure is detected and handled.

Your job is not to standardise this across the organisation. Standardisation is how institutions defend themselves. Your job is to ensure the approach is coherent, safe, and aligned to outcomes.

Make one thing explicit: the change must be evolutionary. Big bang transformations are just another form of institutional violence. They create fear, surface compliance, and quiet sabotage.

Tell the team this clearly: we will adjust every four months based on what we learn. Nothing is permanent. Nothing is sacred.

That sentence removes fear. It replaces performative alignment with honest experimentation.

4. Nurse Ratched and the Tyranny of Order

In One Flew Over the Cuckoo’s Nest, Nurse Ratched is not a monster because she is cruel. She is a monster because she is calm, procedural, and unwaveringly committed to order.

Everything is justified as being “for the good of the patients”. Every routine is defended as necessary. Any challenge to the system is reframed as dangerous, immature, or non compliant. Agile organisations create their own Nurse Ratcheds.

They are not villains. They are process enforcers who value predictability over progress, rules over reasoning, and compliance over outcomes. Their job is to maintain the routine, not to question whether the routine still makes sense. This is how waste becomes untouchable.

Meetings exist because they exist. Governance forums approve nothing but consume hours. Status packs are produced laboriously, yet are often inconsistent, contradict the previous updates and almost everyone ignores them.

Large packs are the medication of corporate life. They sedate leadership into feeling they are informed, while quietly masking the death of meaningful delivery speed.

When teams question these rituals, they are told they “don’t understand agile”, that the process is “there for a reason”, or that removing it would be “risky”. This is exactly how institutions protect themselves.

Ask the team to keep notes throughout the cycle. Not complaints. Observations.

Which meetings create decisions?
Which artefacts actually change outcomes?
Which processes exist purely to maintain a sense of control? Do not punish this honesty. Reward it.

In institutions, silence is mistaken for alignment. In reality, silence is usually learned helplessness.

5. Break the Illusion of Safety

Now do what the institution fears most. Change the frame.

Tell the team to imagine they are running a business competing directly with another company. The client can leave at any time. There is no captive demand. No internal protection. No tolerance for excuses.

Would you still design your delivery system this way?

This framing does what frameworks never can. It reconnects work to reality.

Then say the sentence most teams have never heard:

We can change anything.

Agile did not free teams. It taught them where the invisible fences were and how not to touch them.

6. The Agile Industrial Complex

The Agile Industrial Complex is not an accident. It is a business model.

An entire economy of certifications, consultants, coaches, assessors, and tooling vendors depends on agile never actually working. If teams could ship software simply, safely, and frequently, the market for transformation would evaporate overnight. So instead, complexity is engineered, branded, and sold back to organisations as maturity.

SAFe is not complex because software is complex. Software has always been complex. SAFe is complex because simplicity does not justify billable hours. It does not sustain multi year roadmaps, certification pyramids, or armies of “change agents”. You cannot build a consulting empire on a two page set of principles and a competent engineering team.

Every failure is reframed as insufficient adoption. Every slowdown is treated as a coaching problem. When delivery stalls, the answer is never fewer roles, fewer ceremonies, or better engineers. The answer is always another workshop, another assessment, another layer of governance.

In the Agile Industrial Complex, teams are the product, leadership fear is the demand signal, and shipping software is incidental. The system is not broken. It is working exactly as designed.

7. “But It Works for Mature Teams”

This is the most common defence of agile and SAFe: “It works for mature teams.” That argument collapses under its own weight.

Any framework that only works for teams that already know what they are doing is, by definition, not doing any real work. High performing, experienced teams will succeed under almost any set of constraints. They will route around bad process, ignore pointless ceremonies, and quietly do what needs to be done despite the framework, not because of it.

The real test of a framework is not whether it gets out of the way of excellent teams. It is whether it elevates average teams, supports inexperienced teams, and provides a clear path for those who do not yet know how to ship product safely and effectively.

At an enterprise level, this matters even more. Most organisations are not made up entirely of elite teams. They are made up of mixed capability, uneven experience, and varying levels of leadership maturity. A framework that burdens the least skilled with ceremony, process overhead, and compliance tasks while claiming success when senior teams quietly ignore it is next to useless.

Frameworks should not punish teams for being inexperienced. They should reduce cognitive load, provide guardrails, and make the right thing easier to do than the wrong thing. They should teach judgment, not replace it with ritual. They should pave a path forward, not demand belief before results.

If a framework only works once teams are already mature, then the framework is not a solution. Frameworks should provide predictability, not predictable failure.

8. Choose the Escape Routes That Actually Work

From the constraints, waste, and proposals, you will have a list of potential changes. Do not treat them equally.

Rank each item on three dimensions.

How hard is it to change?

How much risk is there that it will go wrong?

How long will it roughly take?

This is not about precision. It is about judgment.

Target high yield, low risk, short duration changes first. These become oxygen. They free time, reduce friction, and rebuild belief.

The team needs to win early. Momentum matters more than theoretical optimisation.

Do not start with high risk, long duration changes. That is where transformation programmes go to die quietly, buried under good intentions and governance.

9. The Escape Is Not Chaos. It Is Sanity.

This is not anti process. It is anti fiction: stop performing work and start doing it.

You will still have structure. You will still have rules. But they will emerge from reality rather than being imposed to preserve the institution.

Agile and SAFe failed because they engineered defensibility, not delivery. They created a system that protects itself while starving teams of the conditions required to move fast and safely.

The alternative is not another framework.

The alternative is leadership willing to walk into the ward, unlock the doors, remove constraints, and accept that control and outcomes are not the same thing.

Stop asking what replaces agile. Start asking how you ship better products, faster. That is the real escape.

Or: How We Turned Software Development Into Ticket Farming and Ceremonial Theatre

1. Introduction

Agile started as a rebellion against heavyweight process. It was meant to free teams from Gantt charts, upfront certainty theatre, and waterfall failure modes. Somewhere along the way, Agile became exactly what it claimed to replace: a sprawling, defensible process designed to protect organisations from accountability rather than deliver software.

Worse, every attempt to fix Agile has made it more complex, more rigid, and more ceremonial.

2. Agile’s Fatal Mutation: From Values to Frameworks

The Agile Manifesto was never a methodology. It was a set of values. But values do not sell consulting hours, certifications, or operating models. Frameworks do.

So Agile was industrialised.

We now have a flourishing ecosystem of Agile frameworks, each promising to scale agility while quietly suffocating it. SAFe is the most egregious example, but not the only one. These frameworks are so complex that they require diagrams that look like subway maps and multi day training courses just to explain the roles.

When a process designed to reduce complexity requires a full time role just to administer it, something has gone badly wrong.

Framework proliferation map showing how Agile spawned more governance than it replaced.

3. The Absurdity of Sprints

Few terms expose Agile’s intellectual dishonesty better than sprint.

A sprint is supposedly about speed, adaptability, and urgency. Yet in Agile practice, it is a fixed two week time box, planned in advance, estimated upfront, and reviewed retrospectively. There is nothing sprint like about it.

Calling a two week planning cycle a sprint is like calling a commuter train a race car.

Agile claims to embrace change, yet its core execution model actively resists it. Once work is committed to a sprint, change becomes scope creep rather than reality. The language is agile; the behaviour is rigid.

The sprint paradox showing fixed time boxes masquerading as agility.

4. SAFe™ and the Industrialisation of Complexity (2026 Reality Check)

If SAFe™ was already bloated, the 2026 updates pushed it into full blown institutional absurdity.

The framework did not simplify. It did not converge. It did not correct course. It expanded. More roles. More layers. More artefacts. More synchronisation points. Every release claims to “reduce cognitive load” while aggressively increasing it.

SAFe™ in 2026 is no longer a delivery framework. It is a consulting extraction model.

4.1 Complexity Is the Product

The defining feature of modern SAFe™ is not agility. It is deliberate complexity.

The framework is now:

• Too large for leadership to understand
• Too abstract for engineers to respect
• Too entrenched to remove once adopted

This is not accidental design failure. This is commercial optimisation.

SAFe™ is engineered to require:

• Continuous certification
• Ongoing retraining
• Specialist roles that only external consultants can interpret
• Diagrammatic sprawl that requires facilitation just to explain

If a framework needs paid interpreters to function, it is not a framework. It is a revenue stream.

4.2 Predatory Economics and Executive Ignorance

The 2026 SAFe™ model preys on a structural weakness in large organisations: technical illiteracy at the top.

Executives who do not understand software delivery are uniquely vulnerable to frameworks that look sophisticated, sound authoritative, and promise control. SAFe™ exploits this perfectly.

It sells:

• Alignment instead of speed
• Governance instead of ownership
• Artefacts instead of outcomes
• Process instead of production

Large consultancies thrive here. They do not fix delivery. They prolong transformation. Every new SAFe™ revision conveniently creates new problems that only certified experts can solve.

This is not transformation. It is dependency creation.

4.3 Safety Theatre for Leadership

SAFe™ does not optimise for delivery. It optimises for defensibility.

When delivery fails, leaders can say:

• We followed the framework
• We invested in training
• We implemented best practice
• We had alignment

Responsibility dissolves into ceremony.

SAFe™ provides political cover. It allows leadership to appear decisive without being accountable. Failure becomes systemic, not personal. That is its real value proposition.

4.4 Role Inflation as a Symptom of Collapse

The 2026 updates doubled down on role inflation:

• More architects to manage architectural drift
• More product roles to manage backlog confusion
• More portfolio layers to manage coordination failure
• More councils to manage decision paralysis

Each new role exists to compensate for the damage caused by the previous role.

This is not scale. This is organisational recursion.

4.5 Why SAFe™ Cannot Be Fixed

SAFe™ cannot be simplified without destroying its economic model.

If it were reduced to:

• Small autonomous domain teams
• Clear end to end ownership
• Direct paths to production
• Continuous deployment

There would be nothing left to certify. Nothing left to consult. Nothing left to sell.

So complexity grows. Terminology mutates. Diagrams expand. Billable hours increase.

This is not a failure of SAFe™.

This is SAFe™ working exactly as designed.

SAFe complexity diagram illustrating role and process sprawl

5. Alignment Is a Poor Substitute for Velocity

Agile frameworks obsess over alignment. Align the teams. Align the backlogs. Align the ceremonies. Align the planning cycles.

Alignment feels productive, but it is not speed.

True velocity comes from segregation and autonomy, not synchronisation. Teams that own domains end to end move faster than teams that are perfectly aligned but constantly waiting on one another.

Alignment optimises for consensus. Autonomy optimises for outcomes.

In practice, Agile alignment produces shared delays, shared dependencies, and shared excuses. Velocity dies quietly while everyone agrees on why.

6. Agile as a Ticket Collection System

Modern Agile organisations are not delivery machines. They are ticket processing plants.

Engineers spend an extraordinary amount of time creating tickets, grooming tickets, estimating tickets, updating ticket status, and explaining why tickets moved or did not move.

This is administrative work wrapped in the language of delivery.

Burn down charts are the pinnacle of this illusion. They show activity, not value. They measure compliance with a plan, not impact in production. They exist to reassure stakeholders, not users.

The ticket lifecycle showing how work multiplies without increasing value.

7. Burn Down Charts Are a Waste of Time

Burn down charts answer exactly one unimportant question: are we progressing against the plan we made two weeks ago?

They tell you nothing about whether the software is useful, whether users are happier, whether the system is more stable, or whether deployment is easier or safer.

They are historical artefacts, not decision tools. By the time a burn down chart reveals a problem, it is already too late to matter.

8. Engineer the Path to Production, Not a Defensible Process

Agile made a critical mistake: it focused on process before engineering.

Real agility comes from automated testing, trunk based development, feature flags, observability, continuous integration, and continuous deployment.

You do not become agile by following a defensible process. You become agile by engineering a path to production that is boring, repeatable, and safe.

A release pipeline beats a retrospective every time.

9. Continuous Deployment Is What Agile Pretends to Be

If agility means responding quickly to change, then continuous deployment is agility in its purest form.

No sprints
No ceremonies
No artificial planning cycles

Just small changes, shipped frequently, with fast feedback.

Continuous deployment forces discipline where it matters: in code quality, test coverage, and system design. It removes the need for most Agile theatre because progress is visible in production, not on a board.

Infographic placeholder (JPEG):
Sprints versus continuous deployment showing time boxed delivery versus continuous flow.

10. Domains Beat Ceremonies

The most effective organisations do not scale Agile. They decouple themselves.

They organise around business domains, not backlogs. Teams own problems end to end. Dependencies are minimised by design, not managed through meetings.

This reduces coordination overhead, alignment ceremonies, and cross team negotiation, while increasing accountability, speed, quality, and ownership.

No framework can substitute for this.

11. Conclusion: Agile Isn’t Dead, But It Should Be

Agile failed not because its original ideas were wrong, but because organisations turned values into process and flexibility into dogma.

What remains today is ceremony without speed, alignment without autonomy, measurement without meaning, and process without production.

Agile did not make organisations adaptive. It made them defensible.

Real agility lives in engineering, autonomy, and production reality. Everything else is theatre.

1. Estimation Fails Exactly Where It Is Demanded Most

Estimation is most aggressively demanded in workstreams with the highest discovery, the highest uncertainty, and the highest intellectual property density. This is not an accident. The more uncomfortable the terrain, the more organisations reach for the false comfort of numbers. In these environments, estimation is not just wrong, it is structurally impossible. You are being asked to predict learning that has not yet occurred, risks that have not yet surfaced, and constraints that do not yet exist. This is not planning. It is numerology.

High discovery work is, by definition, about finding the problem while solving it. High IP work is about creating something that did not exist before. Estimation assumes a known path. Discovery assumes there is no path. These two ideas are incompatible.

2. Chess Is the Simplest Proof That Estimation Is Nonsense

Try estimating how long a game of chess will take. You cannot. The number of possible games exceeds any tractable search space. Two players, same rules, same board, radically different outcomes every time. You can window the opening because it is memorised. You can vaguely reason about the endgame because the state space has collapsed. The middle game, where real thinking happens, is unknowable until it is played.

Planning a game of chess in advance takes longer than actually playing it. To plan properly, you would need to analyse millions of branches that will never occur. This is exactly what technology programmes do when they insist on detailed delivery plans upfront. Months are spent modelling futures that reality will immediately invalidate.

The more time you spend estimating, the less time you spend learning. Learning is the only thing that reduces uncertainty.

3. Windows, Not Dates. Risk, Not False Precision

Dates create the illusion of certainty. Windows acknowledge reality. In high discovery work, the only honest outputs are windows, complexity signals, and risk indicators. Anything else is theatre.

No estimates should exist until the work is at least thirty percent complete. Before that point, you do not understand the shape of the problem, the resistance in the system, or the real integration costs. Early estimates are not conservative. They are random. Worse, they anchor expectations that will later be enforced as if they were commitments.

A window communicates intent without lying. A risk indicator communicates maturity without false confidence. This is not weakness. It is professional integrity.

4. A Proper Plan Is an Oxymoron

There is no such thing as a proper plan in technology. All plans are improper. Some are merely less wrong than others. Technology shifts underneath you. Dependencies move. Assumptions expire. What was optimal yesterday becomes harmful tomorrow.

Plans are snapshots of ignorance taken at a moment in time. Treating them as commitments rather than hypotheses is how organisations accumulate failure. The correct posture is not adherence to plan, but continuous replanning based on what you have learned since the last decision.

If your plan cannot survive daily contact with reality, it is not a plan. It is a liability.

5. Technology Planning Is Organisational Self Harm

Heavy investment in technology planning is a form of self harm. It is indulgent, expensive, and emotionally motivated. Its primary purpose is not delivery, but the calming of executive nerves through the illusion of control.

Planning artefacts grow precisely when control is lowest and risk is highest. Roadmaps thicken. Gantt charts multiply. Governance forums expand. None of this reduces uncertainty. It simply diverts energy away from learning and into defending a narrative.

This is the lie at the heart of technology planning. Control is low. Risk is high. Pretending otherwise does not make it safer. It makes it slower and more fragile.

Accept your reality. Put your energy into conquering the truth, not defending a lie. Every hour spent polishing a plan that reality will invalidate is an hour stolen from building, testing, integrating, and learning. Planning feels productive. Learning actually is.

6. Everyone Has a Plan Until Reality Hits

“Everyone has a plan until they get punched in the face.” — Mike Tyson. Technology workstreams deliver that punch early, repeatedly, and without mercy.

Technology workstreams are not a single surprise. They are a sustained confrontation with reality. Legacy systems hit first. Data quality follows. Performance collapses under real load. Security assumptions evaporate. Users behave nothing like your models. Every one of these moments is a correction. None of them appear on the plan.

This is why planning confidence collapses so quickly once real work begins. Technology does not negotiate. It does not respect roadmaps. It reveals itself incrementally and relentlessly, one constraint at a time. The job is not to defend the plan after reality intrudes. The job is to stay standing and adapt faster than the next constraint reveals itself.

7. Interdependencies Are the Real Enemy

Most delivery failure is not caused by individual team performance. It is caused by interdependencies between teams, systems, environments, and decision makers. Estimation does not solve this. It hides it.

The only real remedy for interdependencies is to break them. Mocks, stubs, contracts, simulators, and fake services exist so that teams can move independently while reality catches up later. Waiting for another team to be ready is not coordination. It is organisational paralysis.

If your critical path depends on another team, your plan is already broken. Break the dependency or accept the delay. There is no third option.

8. Chase a Path to Production Relentlessly

You must chase a path to production from day one. Avoid the big reveal. Big reveals are how trust dies. They create a long silence followed by a single high risk moment where reality finally gets a vote.

Technology must deliver production value early, even if that value is small, partial, or hidden behind flags. The goal is not feature completeness. The goal is proving that the system can breathe in production conditions. Latency, security, deployment friction, data quality, and operational pain surface only when real traffic exists.

Delivery anxiety is a real force. You can only hold back the dams for so long. If value does not flow early, pressure builds, shortcuts appear, and quality becomes negotiable. Early production exposure releases pressure safely and continuously.

9. Shipping Dates to Exco Is Choosing Vanity Over Your Team

When you ship a date to an exco in a high discovery, high IP environment, you are not being accountable. You are choosing vanity over your team. You are signalling confidence you do not possess in order to look in control.

Ask yourself what you are really expecting your team to do. Do you expect them to ship rubbish into production on that date to protect the narrative? Do you expect them to quietly disagree but say nothing, pretending they accepted your made up certainty? When the date slips, will you say something “unforeseen” happened?

Of course it was unforeseen. That is the nature of high IP work. Calling it unforeseen does not make it exceptional. It makes the original date dishonest.

Dates force teams into impossible ethical corners. Either degrade quality, lie about progress, or absorb blame for a fiction they did not create. All three outcomes burn trust. None of them improve delivery.

Do not burn trust by shipping a date. Instead, ship a risk pack.

A proper risk pack shows what you are in for. It shows that you understand the terrain, the uncertainty, and the commercial exposure. It shows a credible route to delivering production value early, not a promise of completeness later. It demonstrates that the work can be made commercially viable through staged value, controlled exposure, and fast learning.

What exco actually needs is confidence that you are focused on delivery, speed, quality, and risk, not that you can guess the future. Dates satisfy anxiety. Risk packs build trust.

10. No Estimates and the Discipline of Reality

Woody Zuill’s No Estimates work is often misunderstood as anti planning. It is not. It is anti fiction. The core idea is simple. Focus on delivering small, valuable, production ready slices and use actual throughput as your only credible signal.

When teams stop estimating and start finishing, predictability emerges as a side effect. Not because the future became knowable, but because feedback loops became short. Work items are refined until they are small enough to complete safely. Risk is exposed immediately, not deferred behind optimistic forecasts.

No Estimates is not about refusing to answer questions. It is about refusing to lie. When asked how long something will take, the honest answer in high discovery work is what we have learned so far, what remains uncertain, and what we will try next.

11. Technology Change Is War

All technology change is a war. There is always an opponent, even if you pretend there is not. Legacy systems resist you. Data surprises you. Performance collapses under load. Users behave in ways your models never predicted. Every move reveals a counter move.

War is painful. It is humbling. You are always wrong, just in different ways over time. The only winning strategy is speed, decisiveness, and daily engagement. Monthly steerco updates are irrelevant. By the time you present the slide, the battlefield has already shifted.

If you are not all in, every day, close to the work, give it to someone else to run. This is not a governance problem. It is a leadership problem.

12. Relentless Adaptation Beats Perfect Prediction

The strongest teams do not pretend they are right. They constantly declare what did not work and what they are going to change next. This is not failure. This is competence made visible.

Never give up quality to meet a date. Dates recover. Quality debt compounds. Once trust in the system is gone, no timeline will save you. The goal is not to look predictable. The goal is to be effective in an environment that refuses to be predictable.

Stop estimating the unknowable. Shorten the feedback loop. Break dependencies. Chase production early. Declare learning openly. Move, counter move, and stay in the fight.

That is the only plan that works.

Email trees are not an accident. They are the predictable outcome of organisations repeatedly using the wrong tool for the wrong job. Despite decades of evidence, email is still treated as a collaboration platform rather than what it actually is: a slow, lossy message delivery system. The result is wasted time, fragmented thinking, and an extraordinary amount of invisible labour.

1. The One Finger Typist Problem

Few things better capture the absurdity of corporate communication than watching someone sit at their desk, hammering out a long, verbose email with one finger, addressed to a colleague sitting directly behind them. Sentence after sentence is typed, retyped, and expanded, often explaining context that could have been resolved in thirty seconds of spoken conversation or a short chat message.

This behaviour feels productive because it looks like work. In reality, it is delay disguised as diligence. Email encourages over explanation, defers feedback, and removes the natural corrective pressure of real time interaction. The longer the email, the higher the probability that it should never have been an email in the first place.

Email trees are born right here.

2. The Five Sentence Rule

One of the simplest and most effective countermeasures to email abuse is the five sentence rule, popularised at https://five.sentenc.es/.

The rule is brutally simple:

If you cannot state your request clearly in five sentences or fewer, do not use email.

This rule forces clarity. It requires the sender to decide what actually matters, what action is required, and who truly needs to be involved. Long narratives, exploratory thinking, and collaborative problem solving do not belong in email. They belong in conversations, shared documents, or collaborative spaces where context is visible to everyone.

Five sentences is not restrictive. It is generous. Anything longer is usually a sign of unresolved thinking being offloaded onto the reader.

A particularly effective tactic is adding the five sentence rule to your email signature as a subtle hint rather than a mandate. Something as simple as:

“Emails over five sentences probably belong in a conversation.”

quietly resets expectations without confrontation. Over time, it changes behaviour.

3. TL;DR as a Discipline, Not a Courtesy

When longer messages are unavoidable, the TL;DR is mandatory.

A TL;DR at the top of a message is not about politeness. It is about respect for attention. It allows the reader to understand intent immediately and decide how deeply to engage. More importantly, it exposes weak thinking. If the message cannot be summarised in two or three lines, the sender has not yet done the work.

There is also power in replying with TL;DR only. This is not rude. It is corrective. Over time, teams learn to lead with outcomes instead of narratives.

4. Actively Prohibiting Email Discussions

High performing organisations do not merely suggest better communication practices. They explicitly prohibit using email for discussion.

Email is appropriate for formal communication, external messaging, approvals, and record keeping. It is fundamentally unsuitable for debate, iteration, brainstorming, or back and forth problem solving. When those activities are forced into email, context fragments, accountability blurs, and decisions disappear into inbox archaeology.

Leaders must say this out loud. If they do not, email becomes the default because it is familiar, not because it is effective. The cost shows up as wasted time, repeated conversations, and decisions that have to be re made because nobody can find them.

This is not inefficiency at the margin. It is systemic waste.

5. Chat Alternatives and the Governance Reality

Tools like WhatsApp and Slack demonstrate how quickly collaboration improves when friction is removed. Questions get answered in minutes instead of days. Context remains visible. Decisions emerge naturally rather than being negotiated across parallel threads.

But speed without governance is dangerous.

WhatsApp, in particular, is unsuitable for corporate collaboration beyond informal coordination. It lives on personal devices, has no enterprise grade exit controls, and should never be used for client data, financial information, or regulated discussions. When people leave, the information leaves with them.

Slack and similar platforms are more appropriate but still require discipline. Access must be revoked immediately when people exit. Sensitive topics must be explicitly prohibited. Channels must be structured and purposeful. Without governance, chat platforms simply accelerate bad habits instead of fixing them.

Collaboration tools amplify behaviour. They do not correct it.

6. Why Microsoft Teams Is So Painful in Practice

Microsoft Teams is often positioned as the answer to email overload. In practice, many organisations experience it as email with more surface area and more ways to get lost.

From a user experience perspective, Teams is cognitively heavy. Chats, channels, meetings, files, and tabs overlap in ways that are not intuitive. Users frequently do not know where a conversation should live, which thread is authoritative, or where the final decision was made. Finding information often requires training rather than intuition.

Corporate security controls frequently make things worse. In the name of risk management, organisations disable clipboard functionality, block attachments, restrict downloads, and partially or fully blank screen sharing. Each control might be defensible in isolation. Together, they break the channel. What remains is a collaboration tool that cannot collaborate.

Support burden is another hidden cost. Teams is resource intensive on client machines, sensitive to network quality, and prone to inconsistent behaviour across updates. Crashes, dropped calls, audio desynchronisation, and failed screen sharing are common enough to be normalised. Supporting Teams at scale consumes significant IT capacity simply to keep it usable.

Teams does not fail because it lacks features. It fails because complexity combined with controls erodes trust. When people do not trust a collaboration tool to work reliably, they retreat to the one thing they know will always deliver a message.

Email.

And with it, the email trees return.

7. Intentional Communication Design

The solution to email trees is not another tool rollout. It is intentional communication design.

Set clear rules about where different kinds of communication belong. Enforce brevity. Separate discussion from record keeping. Choose collaboration tools deliberately and govern them properly. Train people not just how to use tools, but when not to.

Email will always exist. The mistake is allowing it to pretend to be something it is not.

Collaboration is not about sending messages. It is about shared understanding. Email trees destroy that.

1. The Dead Giveaway Is the Meeting Itself

There is a reliable early warning signal that corporate herding is about to occur: the meeting invite.

No meaningful agenda. No pre reading. No shared intellectual property. No framing of the problem. Just a vague title, an hour blocked out, and a distribution list that looks like someone ran out of courage before removing names.

When a room is “full of anyone and everyone we could think to invite”, it is not because the problem is complex. It is because nobody has done the work required to understand it and consider who can make a meaningful contribution.

Meeting are not the place where thinking happens, they are the place thinking is avoided.

2. Herding Disguised as Collaboration

The stated intent is always noble. “We want alignment.” “We want buy in.” “We want everyone’s input.” In practice, this is herding behaviour dressed up as inclusivity.

Thirty people arrive with different mental models, incentives, and levels of context. Nobody owns the problem. Nobody has written anything down. Discussion ricochets between anecdotes, opinions, and status updates. Action items are vague. The same meeting is scheduled again.

Eventually, exhaustion replaces analysis. A senior person proposes something, not because it is correct, but because the room needs relief. The solution is accepted by attrition.

This is not decision making. It is social fatigue.

3. Why the Lack of Preparation Matters

The absence of upfront material is not accidental. It is structural.

Writing forces clarity. Writing exposes gaps. Writing makes assumptions visible and therefore debatable. Meetings without pre work allow people to appear engaged without taking intellectual risk.

No agenda usually means no problem statement.
No shared document usually means no ownership.
No proposal usually means no thinking has occurred.

When nothing is written down, nothing can be wrong. That is precisely why this pattern persists.

4. The Intentional Alternative

Contrast this with an intentional design session.

Half a dozen deliberately chosen engineers. Front end. Backend. Data. Cyber. SRE. Platform. UX Designers. The people whose job it is to understand constraints, not just opinions.

They arrive having already thought. They draw. They argue. They model failure modes. They leave with something concrete: an architecture sketch, a proposal, a set of tradeoffs that can be scrutinised.

This is not about excluding people. It is about respecting expertise and time.

5. Buy In Is Still Not a Design Input

Herding meetings are often justified as necessary to “bring people along”. This is backwards.

You do not earn buy in by asking everyone what they think before you have a proposal. You earn buy in by presenting a clear, well reasoned solution that people can react to. A proposal invites critique. A meeting without substance invites politics.

If your process requires pre emptive consensus before thinking is allowed, you are guaranteeing weak outcomes.

6. What Meetings Are Actually For (And What They Are Not)

Most organisations misuse meetings because they have never been explicit about their purpose.

A meeting is not a thinking tool. It is not a design tool. It is not a substitute for preparation. Meetings that are there purely for updates can easily be replaced by a Whatsapp group. When meetings are used in such frivolous ways, they become expensive amplifiers of confusion and they signal to staff: “We don’t care what you spend your time on; as long as you’re busy!”.

Meetings are for review, decision making, and coordination. They are not for first contact with a problem. If nobody has written anything down beforehand, the meeting has already failed.

The Diary Excuse Is a Dead End

When you ask attendees what the agenda is, or what ideas they are bringing, you will often hear the same response:

“This is just the first meeting we could get in everyone’s diary.”

This is the tell.

What this really means is that nothing has been done for weeks while people waited for senior availability. Thinking has been deferred upward. Responsibility has been paused until titles are present.

The implicit belief is that problems are solved by proximity to senior people, not by effort or clarity. So instead of doing groundwork, people wait. And wait. And then book a meeting.

If you then ask what they are doing for the rest of the day, the answer is almost always:

“I’m back to back all day.”

Busy, but inert. This is how organisations confuse calendar saturation with productivity.

What Meetings Are For

Meetings work when they operate on artifacts, not opinions.

A good meeting typically does one of three things:

1. Reviews a written proposal or design and challenges assumptions.
2. Makes an explicit decision between clearly defined options.
3. Coordinates execution once direction is already set.

In all three cases, the thinking has happened before people enter the room. The meeting exists to compress feedback loops, not to discover reality in real time.

This is why effective meetings feel short, sometimes uncomfortable, and often decisive.

What Meetings Are Not For

Meetings should not be used to:

• Define the problem for the first time
• Gather raw, unstructured ideas from large groups
• Wait for senior people to think on behalf of others
• Achieve emotional comfort through alignment
• Signal progress in the absence of substance

If the primary output of a meeting is “we need another meeting”, then the meeting was theatre, not work.

Large, agenda-less meetings are especially dangerous because they allow people to avoid accountability while appearing busy.

A Simple Time Discipline Most Companies Ignore

As a rule, everyone in a company except perhaps the executive committee should not spend more than half their time in meetings.

If your calendar is wall to wall, you are not collaborating. You are unavailable for actual work.

Most meetings do not require a meeting at all. They can be replaced with:

• A short written update
• A WhatsApp message/group
• A document with comments enabled

If something does not require real-time debate or a decision, synchronous time is wasteful.

A Rule That Actually Works

The rule is straightforward:

If the problem cannot be clearly explained in writing, it is not ready for a meeting. If there is no agenda, no shared document, and no explicit decision to be made, decline the meeting.

This does not slow organisations down. It speeds them up by forcing clarity upstream and reserving collective time for moments where it actually adds value.

Meetings should multiply the value of thinking, not replace it.

How to Maximise the Value of a Meeting

If you are going to run a meeting, it must do more than transmit information.

Update meetings are the worst offenders. Too often they degrade into a series of polite, head nodding monologues where everyone speaks, nobody listens, and nothing changes. Information is broadcast, not interrogated. Learning is optional. Growth is absent. If you must have an update meeting, introduce a provocateur.

This is someone whose explicit role is to challenge what is being presented. To ask why, not just what. To surface assumptions. To probe tradeoffs. To turn updates into teaching moments and discussion into shared understanding. The provocateur is not there to be disruptive. They are there to prevent intellectual complacency. A valuable update meeting should:

• Expand understanding, not just awareness
• Encourage explanation, not recitation
• Invite challenge, not passive agreement
• Leave people thinking differently than when they arrived

If updates cannot withstand questioning, they are not updates. They are status theatre. If a meeting does not create thought expansion or skill growth, it is not worth the collective time it consumes. And if no one in the room is prepared to challenge, question, or learn, the most efficient option is simple:

Cancel the meeting.

My Personal Rule

My default response to meetings is no. Not because I dislike collaboration, but because I respect thinking and time is more finite that money. If there is no written problem statement, no agenda, and no evidence of prior effort, I will decline and ask for groundwork instead. I am happy to review a document, challenge a proposal, or make a decision, but I will not attend a meeting whose purpose is to discover the problem in real time or wait for senior people to think on behalf of others. Proof of life comes first. Meetings come second.

7. Workshops as a Substitute for Thinking

One of the more subtle failure modes is the meeting that rebrands itself as a workshop.

The word is used to imply progress, creativity, and action. In reality, most so called workshops are just longer meetings with worse discipline.

A workshop is not defined by sticky notes, breakout rooms, or facilitators. It is defined by who did the thinking beforehand.

When a Workshop Is Legitimate

A workshop earns the name only when all of the following are true:

• A clearly written problem statement has been shared in advance
• Constraints and non negotiables are explicit
• One or more proposed approaches already exist
• Participants have been selected for expertise, not representation
• The expected output of the session is clearly defined

If none of this exists, the session is not a workshop. It is a brainstorming meeting.

What Workshops Are Actually For

Workshops are useful when you need to:

• Stress test an existing proposal
• Explore tradeoffs between known options
• Resolve specific disagreements
• Make irreversible decisions with high confidence

They are effective when the space of ideas has already been narrowed and the goal is depth, not breadth.

What Workshops Are Commonly Used For Instead

In weaker organisations, workshops are used to:

• Avoid writing anything down
• Create the illusion of momentum
• Distribute accountability across a large group
• Replace thinking with facilitation
• Manufacture buy in without substance

Calling this a workshop does not make it productive. It just makes it harder to decline.

A Simple Test

If a “workshop” can be attended cold, without pre reading, it is not a workshop.

If nobody would fail the session by arriving unprepared, it is not a workshop.

If the output is another workshop, it is not work.

Workshops should deepen thinking, not substitute for it.

8. Why I Don’t Attend These Meetings

I actively discourage this pattern by not attending these meetings. This is not disengagement. It is a signal.

I will not invest my time in a room where nobody has invested theirs beforehand. I am not there to help people discover the problem in real time. That work is cheap individually and expensive collectively.

Before hauling thirty people into a Teams call or a boardroom, do the groundwork. Write down:

• What the actual problem is
• Why it matters
• What makes it hard
• What ideas have already been considered
• Where you are stuck

I do not need perfection. I need proof of life.

9. Proof of Life as a Professional Standard

A proof of life can be a short document. A rough PRFAQ. A few diagrams. Bullet points are fine. Wrong answers are fine. Unfinished thinking is fine.

What is not fine is outsourcing thinking to a meeting.

When there is written material, I can engage deeply. I can challenge assumptions. I can add value. Without it, the meeting is just a time sink with better catering.

10. What Actually Blocks This Behaviour

The resistance to doing pre work is rarely about time. It is about exposure.

Writing makes you visible. It makes your thinking criticisable. Meetings spread responsibility thin enough that nobody feels individually accountable.

Herding is safer for status and feelings. Design is safer for outcomes. Do you care about status or outcomes?

Organisations that optimise for protecting people’s status and feelings, will drift toward herding. Organisations that optimise for solving problems will force design.

Organisations that cannot tolerate early disagreement end up with late stage failure. Organisations that penalise people for speaking clearly or challenging ideas teach everyone else to pretend to agree instead of thinking properly.

As a simple test, in your next meeting propose something absolutely ridiculous and see if you can get buy in based purely on your seniority. If you can, you have a problem! I have had huge fun with this…

11. A Better Pattern to Normalise

The pattern worth institutionalising is simple:

1. One or two people own the problem.
2. A small expert group designs a solution.
3. A written proposal or PRFAQ is produced.
4. This is shared widely for feedback, not authorship.
5. Leadership decides explicitly.

Meetings become review points, not thinking crutches.

12. The Challenge

If your default response to uncertainty is to book a meeting with everyone you know, you are not collaborating. You are deferring responsibility.

The absence of an agenda, the lack of pre reading, and the size of the invite list are not neutral choices. They are signals that thinking has not yet occurred.

Demand a proof of life. Reward intentional design. Stop mistaking movement for progress. That is how organisations get faster, not busier.