Leadership Academy — Pre-Reading: Agile Leadership, Delivery Ownership, and Decision-Making
No session transcript for this one yet — just the assigned pre-reading videos on MoSCoW prioritisation, the OODA loop, leadership agility stages, and weighted decision-making.
Part of the Leadership Academy series — notes from Exaze’s Leadership Academy, Batch 1.
A note on what this post is: every other entry in this series is built from an actual session transcript — what was taught live, in the room. This one isn’t. It’s the pre-reading assigned for the next topic, Agile Leadership, Delivery Ownership & Decision-Making, written up before that session has happened. Treat it as a preview, not a record — once the actual session happens, this becomes its own chapter and this post gets folded into it or replaced.
MoSCoW — prioritising when you can’t do everything
Must have, Should have, Could have, Won’t have — with an important nuance most people drop: the full phrase is “won’t have this time.” Won’t-have means deferred, not rejected. The method comes from Dai Clegg in the late 1990s and is built on the Pareto principle — the 80/20 rule.
Practical facilitation notes worth keeping: agree definitions up front with the business/BA/PM (“does it deliver the business case?” is a reasonable bar for a Must), and use a rough 60% Musts / 20% Shoulds / 20% Coulds effort split as a contingency buffer — the Shoulds and Coulds are what you drop if a Must runs over budget or time. A Must can’t be “more important” than another Must — resist the urge to rank within the category. Keep the tooling simple: a spreadsheet or a whiteboard with index cards beats a heavyweight tool. And prioritisation isn’t a one-time workshop — revisit it every cycle, and if a “Should” keeps trying to become a “Must” as stakeholders change their minds, that’s usually a signal the project’s actual objective is shifting, not just the backlog. (Agile Business Consortium / DSDM lineage, via Product Pathways and agileKRC material)
The OODA loop — deciding faster, not just deciding right
A four-phase decision loop, originally developed by fighter-pilot strategist John Boyd, taught here without the acronym but matching it exactly:
| Phase | What it means |
|---|---|
| Observe | What’s actually going on around you right now? |
| Orient | How do you need to adapt, given what you just observed? |
| Decide | Based on that, what’s the opportunity — what decision moves you forward? |
| Act | Execute it fully, then go straight back to observing the result. |
The point isn’t linear — it’s a loop, and the leadership lesson drawn from Boyd’s original context (dogfights) is specifically about speed: the pilot who cycled through Observe-Orient-Decide-Act faster won, not the one who was right more often. Agile decision-making, by this logic, isn’t about making better individual calls — it’s about cycling the loop quickly enough that a bad decision gets corrected almost as fast as it was made. (Todd Adkins, LifeWay Leadership)
Leadership Agility — three stages of self-awareness
From a podcast conversation with leadership coach Pete Behrens (founder of Agile Leadership Journey, drawing on Bill Joiner and Stephanie Josephs’ book Leadership Agility): leaders tend to operate from one of three stages —
- Expert — leads through personal knowledge and technical authority.
- Achiever — leads through driving results and outcomes.
- Catalyst — leads through creating the conditions for others to perform, rather than driving or directing directly.
Behrens’s framing is explicitly non-hierarchical about this: “there’s no better or worse, there’s more awareness and choice.” The stages describe how a leader tends to make decisions and shape strategy under pressure, and moving between them is less about “leveling up” and more about having more than one mode available — echoing the managing/coaching/mentoring distinction from Session 5, one level up in scope. The same conversation names “hollow leadership” and firefighting culture as things that tend to show up when a leader is stuck operating from Expert or Achiever under sustained pressure, with nowhere to reflect. (Get Agile podcast, ProCognita, with Pete Behrens)
Deciding with a weighted matrix, not gut feel
For decisions with limited resources and multiple real options — which projects to fund, which solution path to take mid-project — the standard tool is a weighted decision matrix: list the criteria that actually matter for this decision, weight each by importance, score every option against every criterion, and total the weighted scores. It won’t remove judgment from the decision, but it forces the judgment into the open — you can see exactly which criterion is driving the outcome, rather than a decision that “felt right” for reasons nobody can name afterward. (Kandis Porter, Effective Flow Connections)
This connects directly back to SCOPE’s Escalation component from Session 3 — a weighted matrix is a reasonable tool for the decisions that are yours to make; the harder skill is recognising, ahead of time, which decisions are above your altitude and belong in someone else’s hands instead.
Back to the series index
Sources: