Prioritization isn't what it used to be.

"Prioritization" once meant finding the one, single most important thing. In the Latin root, prior was a singular absolute. There could be only one. But the world accelerated. Hence, the concept fragmented: we started juggling "priorities."

In this post, we'll explore how the historic concept of prioritization breaks down in complex, high-velocity systems, and what a modern, systemic view of "prioritization" looks like.

Where "Prioritization" Came From

For centuries, the term "priority" made perfect sense: Every monastery had one Prior - the one who led the monastery, coordinated its logistics, and gave meaning to the work of the monks. Rulers dealt with events in succession, because information changed slowly: During a public audience, there might have been interrupts, but other than that, everything was coordinated and arranged in a clear sequence. The "Kölner Dom" was built over centuries, and the decision how much labor and funding to allocate to the construction was made many times, across many generations. The world itself moved at a human pace.

The industrial age changed that, and the Internet completely broke us. Communication became instant; execution, however, did not accelerate at the same pace. Suddenly, multiple "first things" competed for limited time and attention.

The POTUS Dilemma

Imagine for a minute, you're the President of the United States. You look at your phone. There are 3 messages:

• China has declared war.
• A rioting mob is storming the Capitol.
• Someone threatens to kidnap your daughter.

You can't ignore any of these issues, but you can only make one call at a time. Which number do you dial first?

That is prioritization!

The Collapse of Time

In 1875, if China had declared war, the message would take weeks to arrive. Today, it would hit every device on Earth within seconds — but the machinery of response still moves at human speed.

The result: information travels faster than action. Decisions are always chasing relevance. “Prioritization” becomes less about choosing and more about adapting.

The Decision Loop

When people at operational level claim "prioritization failure," they usually mean, "management failed to decide what not to do." But that's just passing the buck. It fails to acknowledge that there's a much deeper, systemic design issue: it's not that easy.

Every organization today runs through the same cyclical funnel:

• Information: What do we notice?
• Decision: Which trade-offs do we accept?
• Action: Who acts, when, and with what resources?
• Result: Which outcomes count as meaningful?

Prioritization doesn’t happen once inside this loop. it happens continuously, at every stage.
And whereas in the past, it was quite easy to run this cycle maybe once a quarter at board level, today, even a day hardly cuts it.

Where Prioritization Really Lives

We must get beyond the concept that "Prioritization" is the management activity of deciding which work gets done and what doesn't get done. While not totally wrong, it misses the mark. Practically, "Prioritiztation" is not a management-only act. All the cognitive filters we apply to our environment are acts of prioritization - do we pay attention first to our own area, or to the system? Do we pay attention to the short term, how much attention do we pay to the long term?

When organizations struggle with "prioritization," it's rarely because "management doesn't decide properly." It’s because the system is designed in a way where prioritization flow naturally across the loop in an effective manner.

The task of leadership, then, is not to pick individual projects, tasks or activities from a pre-defined list of options - but to design how prioritization happens.

Conclusion

"Prioritization" is a concept from times gone by, where the speed of information was measured in days, and the world's information could be measured in books. Today, we're dealing with information arriving within seconds, and every day, the Internet is flooded with more new information than the world's biggest library could contain. The context is no longer one where we can easily sequence our activities, without loss of outcome quality.

The core issue is an inability to sense, interpret, and adapt quickly enough to retain focused on what truly matters.

As information accelerates, and as AI begins to process it at near-light speed, the meaning of "prioritization" will shift from choosing actions to defining value systems which enable full-automating not only the decision of which information is important, but also determining the impact: What needs to change, and who needs to be informed.

The real question we need to answer in prioritization is not about work packages. It's about the information we need to send, and to process.

The challenge is not coming up with an ordered task list. It's how we keep it relevant in real time.

AI Estimation - helping you understand Architectural Quality

Artificial Intelligence can be a blessing and a curse. While developing VXS, I have come upon a personal reflection exercise:
At the end of every working day, I tell my IDE AI to "please explain all the changes we have made today."
Then, I feed the output into chatGPT and ask it, "Please provide for me a conservative estimate for this backlog."
The result is usually something like this:

The Evening Ritual

Every evening I close the laptop with a simple ritual. I ask my IDE's assistant to explain, in plain language, everything that changed today: which modules moved, which interfaces shifted, which tests were added or deleted, where the seams tightened or tore. It replies with a neutral, factual log. No heroics, no storytelling, just the anatomy of the pure code work.

I take that log and hand it to an external estimator (I use chatGPT) with a fixed prompt: "Give me a conservative effort estimate for the following backlog:" The prompt never changes. The intent never changes. Only the code does. And I'm not asking for a plan or a deadline. I'm asking for a mirror.

The estimator returns a number and, more importantly, a decomposition of why the number is what it is. I archive the result alongside the day's log. Tomorrow I'll do it again. Over weeks, a pattern emerges: sometimes the estimated effort grows; sometimes it shrinks; sometimes it holds steady. The numbers are not my speedometer. They're my oil pressure gauge.

How I do it

Consistency makes this work: I use a consistent source description (the IDE's explanatory log) and an identical estimator (same prompt, same assistant). The descriptive prompt helps keep things consistent. The only variation I tolerate is that I separate either by user-facing behaviour (for anything that has user impact) or technical behaviour (things that affect structure or technical arrangements rather than users) - the point is categorical comparability, not theatrics.

My git commit logs are the source of truth. I don't talk about work that is not visible in the codebase. So it excludes anything that does not lead to a technical change: and that's on purpose. We will get to that soon.

I never doubt the estimate. I never ask for a second-guess unless chatGPT made obviously wrong assumptions. I do not think I'm a hero if the number is high. Nobody knows the real numbers - except me and my dev diary. I am interested in a single question: "What did today's work say about the architecture's ability to accept change?"

Why I do it

Most development "estimation" is theater. I don't have time for theater. I am not in a situation where it matters how long something takes - what matters is that it's done, and it works. I don't care how fast other people work - I care what I accomplish. I don't care what is easy or difficult - I care for the results I produce. So the estimates themselves are not the value.

And I don't care for quantity of output - what I am concerned with is malleability - the rate at which the system can absorb change. This one property tells me whether the system is getting better or deteriorating over time. The result might look like this:

Interpreting AI estimates as "architectural telemetry" flips the estimation narrative on its head. When the estimates rise over time, it means the system is able to absorb larger changes than before: The boundaries are clear, the tests reliably catch issues, the code is adaptive, and the coupling of components is honest. However, a decline in estimates is caused by poor changes: Poor modularity, Clean Code Violations, WET code, "unidentifiable bugs," unfixable tests, non-working features. These are all things that steal my time and result in fewer changes integrated over the course of the day.

So what I end up with is not a developer performance metric - it's an architectural quality metric, and an extremely powerful indicator of Technical Debt. This measure is much more connected to business value than anything that others measure before: If I can do 3 days of work in 1 day, it means that my engineering efforts are highly valuable. If it were 1/2 day, I'd better throw away the entire codebase and start from scratch.

Additionally, this routine also helps me check cognitive drift. Immersion blurs judgment. The AI, as an external estimator, given a fixed description, stays objective enough to challenge my gut. It stays neutral and unbiased. It has no incentive to make me feel good or bad about the work I do. It is pure consequence. This removes the emotional justification from the process.

How you can use this

You do not need a specific tool to adopt this. All you need is a rhythm: a factual daily log, a consistent external estimator, and a small note about your architectural intent. Done steadily, the series becomes a quiet diagnostic of design health. You will discover whether your system starts resisting meaningful change, and you can see the payoff of investments into code quality long before defect curves become visible.

There's a temptation to optimize the number, and managers may be tempted to look for high numbers. But: Goodhart's Law is inevitable if you try. The entire approach only works because it's not about making numbers go up. The number is just a mirror. And it helps you reflect on key design questions: "Why was this so hard, when AI said it should be easy?" - "What can we do to make it easier without getting ourselves into a pickle tomorrow?" - "What prevents or causes deterioration of change integration?" The answers will relentlessly point out the weak spots in both your architecture and your development approach.

Over time, you will notice the codebase becoming calmer. Working in this way and asking these questions frequently leads to Relentless Improvement. No tests? You did poor. Tight coupling? You blew the estimate. Hardcoding? You can't keep it. And that's the value of the exercise: a leading indicator of architectural quality that you can gather with nothing more than honesty and repetition.

Tips & Tricks

When the estimates of today's work increase after a deliberate cleanup, that's the right track. Keep going. You've unlocked leverage: the same unit of intent now reaches farther into the system.

When estimates decrease without special causes (e.g., you had a lot of meetings, were sick etc.) - stop and look for debt: hidden coupling, missing tests, undocumented contracts.

When estimates stay constant while scope expands, confirm that your boundaries are carrying their weight; if they are, you've found equilibrium worth defending.

The point of the AI Estimation metric is not to go faster. The point is to stay flexible. True agility in software development is "the ability to achieve more tomorrow than you could today, with less sweat or fear." When used in this way, AI estimates will tell you whether you're creating or losing that freedom.

Is your Strategy a Waste?

"Strategy" has a bad rap in many teams - not because it's a bad thing, but because in most companies, it's disconnected.
Disconnected from reality, from their work, from the situation they are facing.
A team lead recently told me, "We're not involved in strategy. That's someone else's job. We just get told our job, and then we do it."
And that's how strategy goes to die before it's even ready to walk.

Three Signs your Strategy is Failing

Over the years, I have condensed a few leading indicators for strategic failure that help you avoid the pitfalls:

1. Strategy Without Operational Awareness

Don't get me wrong: It's not like I haven't built my own strategy slide decks.
But: most of the time, strategy builds cloud castles - created by folks who don't do the work, for people who don't do the work.
I remember having an executive explain to me their "strategy" in detail, patiently, for over an hour. Finally, I asked four questions:

• How does that relate to the work people are doing?
• What signals do you expect, to tell you whether you're getting there?
• What steering mechanisms will you be using as you drive?
• Do the people doing the work even know about this strategy?

All I got was, "That's Operations, not Strategy."
And that's exactly the kind of cloud castles I'm talking about: there's zero chance that such a strategy survives contact with reality.

2. Your Strategy is a Fixed Plan

Most companies create a strategy in fixed intervals, and then document, file and distribute it.
At the end of the strategic interval, they run a post-mortem to figure out why it didn't work.
Predictably. Every. Single. Time.
Strategy is an abstraction. On purpose. It ignores the details. It needs to - or it deteriorates into tactics.
It's built on assumptions. But these assumptions need to be validated against reality - in real time.
The missing nuances? No problem - until they become a problem. When that happens, you need to catch the signal, and adjust course:

• Without mechanisms to capture whether your understanding of your situation is your situation, you're hallucinating, not strategizing.
• As time progresses, your deck drifts further and further from reality. The answer isn't spending more time on better slides: it's adaptivity.
• When internal and external conditions make your strategy unfeasible, you need to adjust your strategy, not the work.

3. Your Strategy isn't Aligned with Execution

I was amazed when working with a CEO who was so adamant that his strategy was clear - and nobody knew what to do with it!
Yes, his closest circle had seen the slides, but this "strategy" was a mumbojumbo of sloganized buzzwords like "AI-powered innovation empowered with data-driven decision-making" and "Industry leadership with future-proof paradigms."
People simply wanted to know, "Do you want to strengthen existing products, or diversify?" - but none of that was answered: Execution simply drifted mid-air.

The misunderstanding?

• Strategy doesn't need fancy words. It needs to connect: What customers need, what people do, and how people think.
• You're not defining strategy for executives. It's for execution. If you can't tell me how you execute, you're blank.
• If your execs don't know how to talk to workers, and vice versa, your strategy gets "lost in translation."

How to Close the Gap

Closing the Strategy-Execution gap is not optional. If you don't, you'll burn money, drive off your best people, and lose out on market opportunity. A coherent, executable strategy is not a "nice to have" perk - it's necessary to run a sustainable business. Incoherence, however, creates waste and friction - translating into money spent for nothing, and money not earned. So here are a few tips to help you close the gap:

Map the Situation, then the Destination

Of course, you need a vision - but "a vision without a plan is a hallucination." And a plan includes a transition "from here to there." That means:

• Where are we today?
• How will our situation be different?
• What are the key moves we're going to make?
• What is needed in order to make these moves?

Many "strategies" fail as key moves are not realistic based on today's situation, or the preconditions for making a move are out of sync with the available capabilities and resources.

The people who know the situation, and how to change it? These are the execution folks - which is why they need to be at the table when you close the gap.

Build Real-Time Feedback

If your strategy is fire-and-forget - let me tell you: it's forgettable.
Strategy that has a bite connects outcomes with metrics, signals, feedback, and conversations.
Strategic Post-mortems aren't a sign of a healthy strategic process: they're a sign that your process isn't built to succeed.

Make Strategy Responsive, Not Directive

Percolating strategy top-down is the most pervasive disease corporations have, and too many small companies get inspired to adapt it, even though the results are mediocre and failures massive. Strategy is a map and a compass - not the road. The road needs to be built, and that is execution.
The people deciding distance, speed and direction don't even have the information or bandwidth to concern themselves with every rock or tree on the ground. That's okay - but their ability to succeed depends on taking these things into account.
That's why you need a responsive strategy - one that adapts as necessary without losing the way, or the plot.

Co-Create With Execution

The best strategies build momentum from "where we are" by leveraging the strengths that are already there. Ask the people who are executing the work what they see as meaningful steps, and where they believe resources are mis-invested, you'll be amazed.
A good strategy should have clear, actionable goals, and be immediately relatable to people's daily work. If people can't say where they fit in the big picture, you've found the problem already. And it's either that people didn't get connected, or that there is no connection. In either case, you can adjust right there, right then - and don't need to wait for a post-mortem held in an ivory tower among people, none of whom know why the strategy failed again.

tl;dr

Most strategic failures aren't caused by a "bad strategy" or "poor execution." They died in the strategy-execution gap - and when that happens repeatedly, teams lose trust in "strategy." But it's not hopeless. There are a few things you can readily do to improve - starting today Map the situation, wire in real-time feedback, and make strategy responsive and co-created. Close those loops, close the gap.

Story Points answer nothing

It's 2025, more than a decade since Story Points should have been buried. But they still aren't.
Let me tell you why they're a distraction, not a solution.

The purpose of Estimation: Decisions

When Estimates come up, I always ask: "Who needs the estimate, and what decisions will be made based on them?"

Let me give you a few examples when estimation can't be answered by providing a Story Point number:

• "I need to know whether we can afford this. Can you tell me how much it costs?"
• "We need to plan for contingency in case this is late. Can you do it on time?"
• "Would it make sense to distribute the work across multiple teams to get it done faster?"
• "Is this the simplest thing we can do to reach our goal? Does it make sense to take a shortcuts?"
• "How big is the risk of failure to deliver on time, in quality by deadline?"

Did you realize that none of these questions need to be asked inside the team - and none of them relate to "Agile?"

Business-facing, not team-facing

When the only party depending on the estimate is the team, internally - why do you even estimate? There is no criticality, no risk, no dependency, no impediment. Just do it. Best you can do, as soon as you can deliver. That's enough. But - for the business, that is not enough.

None of the questions suggested above are relevant inside the team: their relevance is defined outside the team. With your stakeholders, the people who pay your bills. If they can't make a proper decision, you're alienating them, risking a communication gap that could cost you your credibility.

Stakeholders don't need to know if something is 12 or 49 Story Points. They don't care if something is a Story or an Epic. What they care is, "Do I need to adjust anything? Will I get what I need, when I need it, how I need it - at a price I can afford?"

These questions can not be answered by Story Points, unless you clearly relate Story Points back to team days and money. But if you do that - then why use them to begin with?

Estimation that doesn't drive business decisions is waste.

Customer decisions, not team decisions

What many Scrum teams and Scrum Masters fail to understand: business requires planning, too. Your sales team must give an account to your customers if they get what they signed up for. Your customers must plan their budget, and how they use their resources.

Let me give you an example: If you buy a Mobile phone, you want to know when you can use it. Customers don't accept "You get it when you get it" - they'll most likely leave the shop and take your money elsewhere. And the answer, "We still need 17 Story Points until you can use it" would immediately trigger the question, "And how long is a Story Point, exactly? Minutes, Hours, Weeks?"

Estimation that pushes uncertainty to the customer is an antipattern.

Conclusion

Before you talk about which estimation method to use, try understanding your stakeholders:

• Learn what your answer causes for them. Understand which decisions they will make with the information you provide.
• Use the estimation approach that helps you come to a common understanding with your stakeholders.
• Sometimes, "No problem, you'll have it by the end of next week" is all the information required.

When possible, skip estimation entirely - just make sure you're confident that you can live up to your promises.
But when you need to estimate: find out for whom, what they need, and give them that. And use the approach that makes you confident your answer is trustworthy.

Your job is to make the business successful, not to "do Estimation correctly."

Don’t «Trust the Team» if They’re Stupid!

Yes, that title is intended to ruffle a few feathers. "Trust the team," without context - is a slogan: unhelpful, misleading, and quite often the cause of, not the solution to, greater problems.
Many people associate "Stupid" with low intellect. If you do: let me change your mind. In business, stupidity is behaviour, not IQ.

This is stupid

Imagine you’re the CEO of a company in crisis. An old friend offers a deal that could get you back on your feet.
The only catch: they need to be convinced their contribution will be valued. You assure them it will.

You arrange for them to meet your team. You can’t be there, but they’re all professionals: they’ve got this.

Then your phone rings. There will be no follow-up. The deal is off. Worse: they’ll no longer offer introductions or recommendations; it would damage their own reputation.

What just happened? Your team's actions just cost you an ally and years of relationship-building. There was no malice or sabotage. It was just plain stupidity.

People do stupid things - even with every safeguard in place. And when it happens, your role shifts instantly: from shaping the future to cleaning up the mess.

Understanding Stupidity

Half a century ago, the economist Carlo Cipolla wrote a satirical, uncomfortable essay titled "The Basic Laws of Human Stupidity" ("Le leggi fondamentali della stupidità umana", 1976)

He determined the value of actions by two factors: impact on self and impact on others. Stupidity, he said, harms both.

You may ask, "Why would anyone do that?" Which is the point: There is no reason, yet it happens, far more often than we think. And - it's stupid.

The Leader’s Field Guide to Dealing with Stupid Teams

Executive Lens - the "CEO Method"

Stupid teams damage the company and themselves. Deal with them in three steps:

C

ontain - Contain the blast radius and do damage control.

E

ducate - Teach, guide and provide information. Tighten feedback loops.

O

bserve - Actively monitor for change. If there's no improvement, disengage or remove the team.

Below is the full, detailed guide to fixing "Team Stupidity."

Full Guide

Locate your team in the quadrant. Lead accordingly. With the exception of the Intelligent team, move them out of the quadrant.

Helpless Teams Indicators Say “yes” → drown → miss their own deadlines. Apologize to stakeholders for internal confusion they didn’t cause. Work hard, little leverage; impact diffuses into others’ wins. Contain Set a single owner and cap WIP; enforce trade-offs. Give permission & scripts to say “not now” without guilt. Pair with an assertive peer; protect calendar from drive-bys. Educate Boundary & negotiation training. Actively guide prioritization. Teach cost-benefit thinking Observe Check for signs of power slopes. Level the playing field. Create visibility into team outcomes.

Intelligent Teams Indicators Net-positive outcomes for team & stakeholders; few surprises. Double-loop learning: they stress-test their own ideas. Credit-sharing, clear handoffs, clean partner interactions. Grow Protect decision rights; remove bureaucracy and politics. Feed them high-leverage problems at their competence boundary. Use pre-mortems & lightweight decision logs to scale the pattern. Keep this! Don’t move them. Codify playbooks; mentor others; plan succession. Guide them to mentor others as well.

Stupid Teams Indicators Celebrate "wins" that produce more fallout than benefit. Repeat the same error after feedback; high confidence, low grasp. Create more problems than they resolve; eroding external trust. Contain Suspend outward-facing autonomy immediately. Enforce brief → act → debrief with decision logs & pre-mortems. Route external comms over an “adult in the room”; assign a fixer. Educate Provide context Teach about consequences. Coach forward-thinking. Observe Positive change: gradually grow autonomy. No measurable shift: redeploy or remove. Protect the company. Unsuccessful: disengage. Protect your reputation.

Bandits Indicators Local "wins" with systemic damage; stakeholders feel squeezed. Information hoarding, triangulation, credit theft. Success depends on optics, not durable outcomes. Contain Shift metrics to shared outcomes; add sunlight (public cause-effect dashboards). Rotate ownership; enforce conflict-of-interest disclosures. Close feedback loops; limit blast radius. Educate Remove incentives that put personal gain over systemic benefit Tether incentives to peer and stakeholder satisfaction. Redesign structure to face customer outcomes. Observe Aligned outcomes: anchor changes. Misaligned outcomes: modify incentives. Exploitation persists: disengage.

Stupidity is Contagious

Can't you just ignore Stupidity? No!

Uncontrolled stupidity sucks you into its blast radius at the worst moment.

And here’s the real danger: tolerating stupidity makes you stupid. Leadership turns into firefighting. Disastrous trade-offs become "pragmatic." Cut corners become "quick wins."

A single act of stupidity rarely remains alone. It triggers a domino cascade, and before long, you're no longer a leader - but cleaning up the debris.

The Leader’s Job: Damage Control

Stupidity is more dangerous to your organization than banditry. Bandits can be managed: Their moves are predictable, and can be redirected by adjusting incentives.

Stupidity, however, is an entirely different beast. It's chaotic and self-reinforcing. You can't predict what they'll do, when or how, and what it will cause. And worse: Stupidity compounds - a stupid move is often addressed by yet another stupid move.

With a stupid team, every day is risk. Challenge poor logic directly. Immediately intervene when "good intentions" cause damage. Invest in change. And when that fails, cut the ties.

Leadership doesn't mean suffering from stupidity - but to end it.

Trust the Right Teams

"Trust the team" is powerful - when the team has earned it! Trust intelligent teams. Give them space to think, act, and lead.

When you see stupid moves, stop "trusting" - actively fix it, fast and with consequence.

Stupidity has no limits. But the market's patience does.

The Castle Is Under Siege - are you the bard?

“If you focus on people being busy, you get people being busy.”

You’ve probably heard that one in some Agile training or coaching session. It sounds profound. But it’s often used in ways that are… well, wrong.

This kind of slogan gets thrown around as if it’s gospel. It’s Agile Coaching Dogma: stemming from half-understood principles and applying Goodhart’s Law in isolation.

Let’s be clear: it’s nonsense. And it misdirects.

The Castle Under Siege

Imagine a medieval castle under siege.
Enemy troops on horseback are approaching fast.
The guards are scrambling to prepare.

The defenders need bows: Everyone will be dead if the siege succeeds.

But there’s only one fletcher.

He’s already buried in work, literally stringing bows as if his life depends on it. There’s a line of guards waiting, each of them waiting for a bow. He’s clearly under pressure.

Meanwhile, his apprentice is chasing that irritating mouse which gnawed at the bread overnight.

Just at that moment, a bard arrives with a clearly urgent request:: “ My mandolin broke, and I really need you to take a look. It’s for the royal banquet tonight. The king will be very upset if there is no music!”

So what’s the real problem?

The issue here isn’t just who’s busy — it’s how busy they are - and what they’re busy with.

What we're talking about here isn’t micromanaging everyone’s calendar. It’s understanding the Critical Path and applying the Theory of Constraints.

1. You have a bottleneck on your Critical Path to success.

The fletcher is the bottleneck. No bows = no defense. No defense = everyone's dead. Preventing that situation is the mission. Everything else is a means to this end.

2. The performance of the bottleneck defines the outcome.

In any system, the bottleneck limits total performance. Here, it's the speed at which the fletcher produces bows which defines whether the castle stands or falls.

3. When the bottleneck is overburdened, stop everything that doesn’t contribute to the Critical Path.

Seriously - cancel that mandolin repair request. Forget that status report. And that retrospective can wait until the archers are equipped.

4. Everyone else's job is to support the bottleneck.

Even if they're inefficient. Two guards stringing bows badly still gives you more bows than one fletcher collapsed from being overworked.

"But they're not specialists, it's not their job description, they aren't trained ..." - you underestimate human ingenuity. They will learn. They will grow. And even if they can't do all of it, there's most certainly some steps where they can relieve your bottleneck.

5. If others are blocked, and it’s not on the Critical Path?

That’s not the bottleneck’s problem. Trying to make it the fletcher’s problem only increases the risk of failure.

Everyone has their own "highest priority. And that's exactly the problem: not knowing the Critical Path, not understanding the price your request towards the bottleneck has in the Big Picture - that's how you destroy performance and slow everything down!

Does it resonate?

In a cartoon, the issue is obvious. You see the problem.

But in real organizations?

• Workloads are hidden.
• Everything seems critical.
• Risks are opaque.
• Goals are unclear.
• And attention is given by status and urgency, not by impact.

So what happens?

• Managers ask the fletcher to put down the bows and provide a status update.
• Consultants draw the fletcher into working sesstions to map the fletching process.
• Agile Coaches pull the fletcher into a retrospective and point out that skipping the Dailies means he's not embracing Agile.

Meanwhile, the castle is about to be overrun.

The brutal truth

The fletcher doesn’t need your coaching right now. The fletcher doesn’t need an alignment workshop. The fletcher needs help!

If you’re not helping, get out of the way. And then figure out how you can help.

This is Theory of Constraints

• Identify the bottleneck.
• Utilize the bottleneck.
• Protect the bottleneck.
• Support the bottleneck.

Not everyone in your company is the fletcher. But someone is. Do you know who?

And if you’re not helping them?

You just might be the bard.

Predictability in middle management? Good luck!

If you’ve ever worked in middle management, you’ve likely felt stuck between chaos from below and control from above. Executives demand structure, predictability, and process adherence. Teams, on the other hand, thrive on flexibility, adaptation, and autonomy.
And the manager? They’re caught in the middle, playing a never-ending game of Rock-Paper-Scissors.

Management: A Game of Rock-Paper-Scissors

You may wonder: What do management and Rock-Paper-Scissors have in common? Middle management is a shark basin - the other a lighthearted, simple hand game often played by kids. I often thought about how to explain what happens in middle management to people unfamiliar with it - and came up with this game as a simple model of what middle management has to deal with.

The Three Moves

As a middle manager, you can ultimately play only one of three moves:

Rock = Stability

Large companies are noisy, chaotic and unpredictable. Playing "Rock" means standardization, consistency, documentation, governance, and regulatory compliance create some predictability.

On the downside, an overuse of Rock makes the process itself the goal, and that causes tremendous waste.

Paper = Delivery

Paper is about taking action, getting stuff done, and produces measurable outcomes. With increasing levels of repeatability and reproducibility, performance becomes scalable.

Paper work is smooth. (all puns fully intended.) Unfortunately, Paper will eventually lead to "doing efficiently that which should not be done at all" (ref. Peter Drucker) - and the biggest threat to businesses is investing into results nobody needs.

Scissors = Disruption

Scissors cut through waste, inefficiency and outdated practices. A play of Scissors is leading innovation, making changes, and turning processes upside down - doing something new, or in ways that were never tried (here) before.

The opportunity of Scissors are immense - and yet, an overuse of the Scissors kills productivity: It destabilizes the organization, causing confusion and chaos.

So then - what is the best move? None.

Let me explain.

There's No Single Best Move

Every move creates the conditions for its own counter:

• Rock sets the basis for productivity - but ultimately, Rock itself is unproductive. Hence playing Rock means that Paper (being productive) becomes the next best move.
• Paper means being productive - but also, outdating. A prolonged period of playing Paper must be followed by a play of Scissors (change).
• Scissors cuts the waste - but it causes chaos: forcing Rock (stability).

The Real Complexity: The System Remembers

Middle management is a game played over time and not in isolation. Past moves shape future conditions. There are other players (your fellow middle managers, your teams - and your customers.) To win, you must think several steps ahead:

• Focus on Rock - and you'll lose to Paper. The player who plays Paper in a game of Rock, Rock, Rock - becomes the winner by default: being a results-driver an environment valuing process conformity over outcomes will be a refreshing change to senior leadership.
• Focus on Paper - and you will struggle with Scissors. The player who brings a novel idea into a stagnant organisation wins, as even small, actionable changes can make a world of a difference.
• Focus on Scissors - and you can't handle Rock. When you're constantly facing the reinforcement of status quo, change will be ineffective - regardless of how good and necessary.

Moving in sequence

And now comes the key challenge: "what should you play next?"

Let's explain what the real problem here is: You're playing a Multiway Rock-Scissors-Paper. You're playing against others (a solvable problem), but you are simultaneously playing against your own past and your own future.

We have established that if you played Rock yesterday, your best move today is probably Paper. And if you play Paper today, your best move tomorrow is Scissors. And after Scissors, you'll have to play Rock again.

But that means that you've got to make a tradeoff between scoring today, and scoring tomorrow. And you can only score today if you prepared for it yesterday.

So then, it's all clear: Play Rock, Paper and Scissors in succession.

Right?

Well - not so quick!

Making a winning move

Even if we assume a fully predictable system - the issue is that you're not playing alone. You're competing with other managers on budget, with other companies on market share, and with customers on business versus customer needs.

So if you played "Rock" yesterday, and you're fully predictable, a competitor will play Scissors on you - because you'll be playing Paper today, and that means, you'll lose.

But then - if you can't play Paper, should you play Rock? Well, then you're not being productive, and then your customers will play Paper on you.

Wouldn't that mean the safest bet after a Rock move is Scissors? Yes.

Except - because it's the safest bet, others will prepare for you playing Scissors by playing Rock.

So you should play Paper?

You see where this is going.

Your own predictability is reducing your odds of making a winning move - so your best chance is to not create any hints on what your next move could be.

The winning strategy: unpredictability

We've discovered that being predictable is a losing strategy.

And a manager always playing the same move is definitely predictable - hence, a single move can not be a successful strategy.

We've also seen that a sequence is also predictable, so "Stabilize, Perform, Disrupt" as a cycle is also not a winning strategy.

That leaves only one strategy for success:

• Play all three moves dynamically, and never lock into a single mode.
• Introduce controlled unpredictability to avoid becoming exploitable.
• Plan for future moves (n+2), not just the next one (n+1).
• Break your own pattern before the system forces you to.

And the desire for Predictability? That's the Problem.

Stakeholders constantly demand predictability: "We need a roadmap." "We need a deadline." "We need clear processes." "We need clear roles." Oddly enough, these demands create the very unpredictability they despise:

• Playing Rock (stability) reduces performance, requiring a rapid move to Paper (performance). And that means less focus on "How", and more focus on "What and When."
• Playing Paper (performance) leads to stagnation, inviting Scissors (disruption). This is going to be uncomfortable, but the only way to remain in business.
• Playing Scissors (innovation) leads to chaos, demanding a follow-up with some solid Rock (stability). But the people who thrive in creative chaos are the first who leave when things get cast in stone.

There’s No Easy Way Out - just a smarter way to play

The fundamental truth of middle management is that it is not a "problem that can be solved:" it is a system that must be navigated.

• Expect stability, and you'll be blindsided.
• Expect performance, and you'll be sidelined.
• Expect innovation, and you'll be slowed down.

Winning in middle management isn't about picking the right move - it's about ensuring you remain ahead of the game and are ready to make your move at the right time.

The only way to be sustainably successful in middle management is that you must know all three moves, you must know how to play them well, you must know when to play them - and what to do when one is being played on you. And why you can't win by locking in any of them.

So, the next time someone asks "predictability in middle management" - just smile. Because now, you know the truth: Good luck.

Organisational GRIT

Many people wonder, "What's the difference between a successful organisation, and one that struggles?"
Throughout my decades of consulting and observation, I have observed four factors that I call "GRIT."
Take heed of these, and you're most likely in good shape. On the other hand, ignore these at your own risk.

The GRIT Factors

When analysing what's going on in a company, there are four factors at play that create GRIT - in healthy organisations, these are naturally tended to and require little effort.

However, unhealthy systems of work neglect one or more of these, with dire consequences:

Goals

The first factor of a healthy system of work is that people have clear goals: things we want to achieve in the future. That can be the personal goals, team goals, business goals.

Best case, everyone has all of these - and all of them align.

Worst case, people have no goals, in which case they will show up just to get paid.

The worst case scenario lends itself to all kind of doomsday scenarios for a business owner: nothing getting done, people wasting their time with unfruitful conflict, or people leaving to make more from their life.

Relationships

The second factor of a healthy system of work is that people have positive relationships with the people around them. That includes their team, other departments, business partners and customers.

Best case, everyone has sustainable, sufficiently close relationships that make their network resilient.

Worst case, people's relationships are toxic or adversarial.

I don't think it requires further explanation what happens when the customer is treated like an enemy - but many organisations seem to be entirely oblivious to the cost in time, effort - and ultimately money - that is wasted with infighting.

Improvement

The third factor of a healthy system of work is that people continuously pursue improvement at all levels: make work faster, easier, better. Reduce risk, friction, cost. Make customers happier. Go home with less stress and more happiness.

Best case, the system of work makes that a natural part of the work, and everyone actively contributes.

Worst case, processes and tools deteriorate and everyone is looking the other way.

It's easy to figure out what happens when improvement is not part of people's thoughts or actions, but that's the reality in many organisations: The tyranny of the Urgent makes improvement fall over the edge until the cost of fixing things has reached frightening levels, and people are scared to even get started.

Tomorrow

The fourth factor of a healthy system of work sounds very abstract - "tomorrow" - so let me make it a bit more tangible: Tomorrow, a competitor may arrive on the market. Your business model may get disrupted. A key player in your team may move on. Are you prepared?

Best case, the company is constantly and persistently putting efforts into being prepared for the uncertainties and inevitabilities of tomorrow, and people are not scared to look into the future.

Worst case, everyone knows that the business is heading downhill, but people close their eyes to this uncomfortable reality. And with every day, the looming specter of Tomorrow becomes more threatening.

It doesn't take a lot of imagination where a company is headed when they have no plans for Tomorrow. And yet, few can articulate a clear plan.

Building GRIT

Building a company with GRIT is easy if that's how you've always done it. But if you've never done it, it's staggeringly hard. In fact, it seems insurmountable. So I'll give you a few pointers for getting started on the journey of building GRIT.

1. Itemize the most important Challenges, Opportunities and ongoing Activities in each sector.
2. If a sector has few or no items in it, it's a blind spot. Take some time to think!
3. Ask yourself, "How can we improve our situation?"
4. Take action on the first item and see where it leads you.

Now, that wasn't hard, isn't it?

From now, you may frequently revisit your GRIT matrix, see what pops up and whether you're making progress.

By taking GRIT building serious, you will see a significant reduction in risk, stress and fear - and significant boosts in sustainability, employee satisfaction and business outcomes.

Give it a try!