Leadership Academy — Session 6: Agile Leadership, Ownership, and Deciding Under Pressure

Part of the Leadership Academy series — notes from Exaze’s Leadership Academy, Batch 1.

Mentoring, operationalized: boundaries, cadence, and why it can’t be assigned

Session 5 drew the line between managing, coaching, and mentoring. This session opened by finishing the mentoring half of that picture — the practical structure that makes it work rather than drift into something else.

A mentoring relationship needs, in order: a defined purpose (what is this actually for), a clear statement of what the mentor will and won’t provide — perspective, network access, challenges, resources, yes; advice on every decision, emotional support, or performance management, no, because those belong to coaching and managing respectively — a cadence, ideally monthly (frequent enough to keep momentum, infrequent enough that it doesn’t collapse into management), an agenda owned by the mentee (if the mentor sets the agenda, it’s coaching), and progress measured every two to three months against the original purpose.

Two boundary rules worth keeping. First, a mentor and mentee shouldn’t be in a direct reporting relationship, unless the mentor has years of experience keeping the two roles isolated — otherwise what gets said in confidence in a mentoring conversation quietly leaks into how that same person gets judged in a performance conversation. Second, and sharper: mentoring can’t be assigned by a third party. A delivery lead can’t hand a mentor a list of things to develop in someone else — “I want this person to grow in these areas, can you mentor them on that” was explicitly called out as not right. The instructor’s own line on it: “Mentorship is something which cannot be forced upon. If somebody else is deciding on my behalf that I need to be mentored on something, has anyone asked my consent?” A manager can identify someone as a future leader and start that conversation directly with the mentee — but the mentoring relationship itself, and what it’s for, has to be negotiated between the two people in it, not delegated in from outside. The analogy offered: you can’t have eleven captains on a team. Everyone deserves the opportunity to grow, but not everyone gets developed toward the same role at the same time, and pretending otherwise isn’t fairness — it’s avoidance of a real prioritization call.

Agile leadership, without the ceremonies

A question from earlier in the programme finally got answered directly: what does “agile leadership” actually mean, once you strip away standups, sprint planning, and retrospectives? Two things, specifically.

One — leading delivery with clarity. Knowing the priorities, the risks, which decisions need making, who needs to make them, and what needs to be communicated to whom and when. Two — owning outcomes, not tasks. An individual contributor owns a task. A leader owns the result, regardless of who actually did the work.

The session tested this with a blunt question, asked without warning: “What’s the most important thing your team needs to deliver in the next two weeks?” Two participants answered instantly — one with “getting the wealth and investment trading platform integration done,” the other with “the first iteration of the fixed-price automation project.” Both answers were tasks. Neither was an outcome. That gap — the reflex to answer with what’s being finished rather than what actually needs to be true once it’s finished — is exactly what agile leadership is trying to correct. The moment you start thinking in outcomes rather than outputs, the instructor argued, the way you handle the same situation changes.

The same test was run again with a harder scenario: if a client complains, or a key person on your team suddenly goes missing, who do you call first, and what do you say? One answer focused on the missing person — chasing them down, explaining they’re unreachable. A sharper answer skipped straight to impact and options: eliminate key-person dependency from day one by knowing who the next-best-informed person is, and default to that person immediately rather than waiting.

The example that made the point land — a genuinely uncomfortable one. A participant described going to the hospital for the birth of his child, only to be told the doctor wasn’t available. What do you do? The honest answer offered in the room was “live with the harsh reality” — which the instructor immediately pushed back on: “As a leader, you will find the alternatives which cause the least friction, because when things are already tough, if you start engaging in conversations about who, what, why — you’re already losing the plot. Your energy is going somewhere else. That is the time you need to be at your calm best.” The concrete alternative offered: check the hospital next door for availability before spending energy arguing with staff who can’t change the outcome. The leadership lesson underneath the discomfort: you don’t behave differently based on the severity of the situation. Calm, clear triage applies whether it’s a minor customer escalation or a genuine crisis — the instinct to “throw your toys” at a severe one and coast through a small one is exactly backwards from what clarity requires.

Five agile principles, reinterpreted for leaders (not scrum masters)

The session went through familiar agile principles and reframed each one specifically from a leadership seat rather than a process-ownership one.

Deliver in small increments. The point was never “tasks that fit in a day” — that’s the version that turned into cargo-cult ceremony (“agile becomes fragile,” as the instructor put it). The actual intent: break large goals into the smallest reviewable unit of value, because that’s what lets you find failure points sooner and change direction faster. A leader who waits until go-live to find out what went wrong waited too long. The analogy: in soccer, when you’re trying to dribble past a defender, you watch their front foot — it tells you where their weight is locked, and which side is actually open. There’s a reason certain moves work and others don’t; the same discipline of “watch the signal that tells you where to move next” applies to spotting failure early rather than reviewing it after the fact.

Build feedback loops — to anticipate, not to review. A scrum master looks backward: how many stories got delivered, how many didn’t. A leader uses the same feedback loop to look forward: if the burn-down is low, what’s coming next as a result? If it’s high, did I set the wrong expectations in the first place? Same loop, different question.

Prioritize ruthlessly. Completing four things at 50% is worse than finishing one thing at 100% — and the ability to say “not this sprint” or “not this time” isn’t a limitation, it’s a skill. The default failure mode is picking up a fourth thing because there’s “some time left,” which guarantees nothing gets fully finished.

Embrace uncertainty explicitly. Being uncertain isn’t a failure — it’s the default state of any delivery. What separates a leader from a scrum master here is naming it out loud: not “we’ll be able to do it” when you don’t actually know, but “I don’t know yet, but I’ll find out.” Managing uncertainty quietly is a process job. Calling it out clearly is a leadership one.

Own outcomes, not tasks — the same distinction the two-week test surfaced above, restated as a principle: if the result is wrong, the leader owns it, regardless of who made the specific mistake. That’s not about doing the work yourself. It’s about being willing to face the consequences of the outcome either way.

What ownership actually means — and the single most common way it fails

Ownership was flagged as one of the most misunderstood words in delivery — usually taken to mean either “doing the work yourself” or “controlling the people doing the work.” It’s neither. Concretely, in the room, ownership is:

Knowing the current status of every key deliverable at all times, without needing to be asked — if you have to go find out what’s happening before you can answer, you’re not the owner, even if the title says you are. Proactively raising risks before they become problems, rather than waiting for someone else to flag them. Making decisions quickly within your own authority, and escalating just as quickly the moment something sits outside it. Addressing what goes wrong by fixing and communicating it — without spending energy on blame. And following up on delegated work: handing a task to someone else doesn’t transfer the outcome, only the doing.

What it isn’t: doing everything yourself because you struggle to delegate. Waiting to be told what the priority is. Sitting on a risk you’ve noticed but haven’t raised. Hiding behind an ambiguous boundary — “that’s not really my responsibility” — when something falls between roles. And reporting what your team did without offering a view on whether it was actually the right call.

The most common ownership failure, named directly: escalating too slowly, because raising a risk feels like admitting failure — so people quietly try to fix it first, and only escalate once that’s failed too. The instructor’s reframe: escalating early isn’t an admission of failure, it’s what a responsible leader does, because it means you’re either informing someone or asking for help — and either way, it gives the other person more time to respond. A problem that becomes visible to everyone before you’ve raised it has already cost the people around you their ability to respond in time.

In the real world: this is close to word-for-word the argument behind Google’s Site Reliability Engineering postmortem culture — writing up incidents without assigning individual blame specifically because removing blame is what gives people the confidence to escalate early rather than quietly trying to fix things alone first. Google’s own SRE book states the mechanism plainly: a blameless postmortem “assumes that everyone involved had good intentions,” and that safety is precisely what lets people report problems the moment they’re spotted instead of after they’ve already grown. It’s the same underlying trade Harpreet described — blame culture makes people sit on risk; psychological safety makes people surface it while it’s still small. (Google SRE Book — Postmortem Culture)

The “small increments to find failure sooner” principle above has its own well-documented real-world root: Toyota’s one-piece-flow manufacturing, which traces back to 1934, when Kiichiro Toyoda was reverse-engineering an engine and found that inspecting castings one at a time — rather than in large batches — let defects surface immediately instead of after an entire batch had already been processed. The same idea eventually became jidoka: giving individual line workers the authority to stop the whole line the moment they spot a defect, rather than waiting for someone senior to notice later. Small batches aren’t primarily about speed — they’re about how early a problem becomes visible. (Michel Baudin — Origin of One-Piece Flow at Toyota)

MoSCoW, reinforced — and a decision-rights question the earlier framing skipped

MoSCoW came up earlier in the pre-reading ahead of this session, but the live session added a piece the video treatment didn’t cover: who actually gets to decide the category.

The four categories themselves are unchanged: Must have — non-negotiable; if a Must is at risk, everything else stops. Should have — high value, but there’s a workaround, so the outcome can still land on time without it. Could have — good to have if time allows; the first thing renegotiated when it doesn’t. Won’t have this time — explicitly out of scope, not rejected outright, just not now. Two hard rules underneath: a Could-have should never delay a Must-have, and a Should-have can never delay a Must-have.

The decision-rights nuance: it’s neither purely the leader’s call nor purely the team’s. If a requirement comes from a customer, the customer decides what’s a Must for their own ask — a leader’s job is to bring the team’s honest understanding of scope, timeline, and resourcing to that conversation, propose the segregation, and get explicit agreement, not to unilaterally decide on the customer’s behalf. Internally — allocating work across your own team — the leader proposes and owns that segregation, ideally with the team present, but shouldn’t get “too defensive” and treat it as something that must always be fully collectively negotiated either. Having the Must/Should/Could/Won’t conversation early, explicitly, and getting agreement on it, is what prevents the prioritization arguments that would otherwise surface later, closer to a deadline, when there’s no time left to have them calmly.

One clarification worth keeping precise: an MVP is not the same as “one Must-have.” An MVP can contain many Musts — a login screen alone isn’t shippable; authentication, a usable flow, and baseline reliability might all be Musts within the same MVP, while a notification feature sits as a Could and an auto-password-reset policy sits as a Won’t-have-this-time. Naming all of this explicitly and early is what “safeguards the team” — if the team later shrinks, or new work gets added mid-flight, you already have a documented, agreed baseline to renegotiate from, rather than an argument about what was always implied.

When everything is urgent at once

The harder version of prioritization isn’t a backlog — it’s two genuinely urgent things landing at the same time. The session’s worked example: a client-facing proposal is due today, and a P1 defect has surfaced for a different client, both yours to handle, both real. Put honestly into an urgent/important quadrant, both land in the same box — which the instructor treated as a signal to re-sort in your head, not a reason to freeze, because eventually one thing is genuinely more urgent than the other, even if both look identical on the surface.

Faced with exactly that pair, the instructor’s own answer was immediate: handle the P1 first. Reasoning: “If there’s a client proposal due today and I’m the leader and I only find out about it today, I should resign — because that means I failed to plan for it earlier.” The proposal, in other words, had time built into it that should already have been managed; the defect didn’t. The proposal can be delegated for review while you handle the escalation — “can somebody else review it while I deal with this?” — because it’s internal and shareable. The defect usually can’t be, because it’s the thing you’re specifically accountable for. Take charge first, then delegate what can genuinely be delegated — don’t leave everything sitting unaddressed while you decide.

The analogy offered for weighing genuine gravity, not just surface urgency: “If I have to open a tap to water my fields, and somebody outside is injured, I can let the person wait a few minutes while I help them. But if the school itself is on fire and it’s in the middle of my field, opening the water becomes immediately important — not just for one person, but for everyone.” Urgency also isn’t fixed — it moves with time. A proposal due in three minutes changes your next action completely; the same proposal due in three hours doesn’t need to touch your calendar right now. Reassess deliberately rather than reacting to whichever thing feels loudest.

The line worth remembering above the rest: it’s fine to decline or defer without guilt, as long as you say so out loud. The instructor used his own travel schedule as the example — cancelling sessions while meeting customers in person, without apologizing for the choice, because it was the right priority at that moment, communicated in advance rather than sprung on anyone. The most common mistake under overwhelm is going quiet. The better response: proactively tell whoever’s expecting something that you can’t deliver it on the original timeline, and offer what you can — “I’m handling a client escalation right now; I can send you the full version in two hours, or what I have right now if that works better — which would you prefer?” That’s not a failure to reprioritize under pressure. That’s what reprioritizing under pressure is supposed to look like from the outside.

Decision quality drops under pressure — the ten-minute rule

A closing point, stated as a hard rule rather than a suggestion: decision quality measurably drops under pressure, and the worst delivery decisions of a crisis tend to happen inside its first thirty minutes — the period when people make fast, easily-reversible-feeling decisions mainly to feel like they’re making progress, not because the decision was actually sound. Examples given: committing to a customer that something will be done in two hours when you don’t actually know that, or pushing something to production without proper testing because pausing to test feels like it’s costing time you don’t have.

The rule: any decision made under pressure that would be hard to reverse should get a ten-minute pause and a second opinion before it’s finalized. Not every decision — just the ones that are both urgent and difficult to walk back.

In the real world: the closest documented parallel to this rule is the WHO Surgical Safety Checklist’s “time out” — a mandatory pause, immediately before an irreversible action (the first incision), where the entire surgical team stops to confirm the patient, the procedure, and anything critical that could still go wrong, before proceeding. It exists for exactly the same reason as the ten-minute rule: the moment right before an irreversible action, under time pressure, is precisely when a team is most likely to skip a check it would never normally skip — and a short, structurally-enforced pause is cheap insurance against that specific failure mode. The WHO’s own studies credit the checklist, and this pause specifically, with measurable reductions in surgical harm. (WHO Surgical Safety Checklist — Adaptation Guide)

From the pre-reading: still worth keeping, not covered live

Ahead of this session, the assigned pre-reading covered MoSCoW from a video source — now superseded by the fuller, decision-rights-aware version above — plus three things the live session didn’t touch on at all, and which still hold up as genuinely useful additions:

The OODA loop — Observe, Orient, Decide, Act, then straight back to Observe — originally a fighter-pilot decision framework from strategist John Boyd. The leadership lesson drawn from it: speed of cycling through the loop matters more than being right on the first pass, because a bad decision corrected almost as fast as it was made costs far less than a “better” decision arrived at too slowly. It sits naturally alongside this session’s feedback-loop principle — anticipate what’s next, don’t just review what went wrong. (Todd Adkins, LifeWay Leadership)

Leadership Agility’s three stages — Expert (leads through personal knowledge), Achiever (leads through results), Catalyst (leads through creating conditions for others) — from leadership coach Pete Behrens, explicitly framed as non-hierarchical: “there’s no better or worse, there’s more awareness and choice.” Worth reading against this session’s “own outcomes, not tasks” principle — Catalyst is what owning outcomes tends to look like once it’s fully internalized, rather than a separate idea. (Get Agile podcast, ProCognita)

Weighted decision matrices for decisions with multiple real options and limited resources — list what actually matters, weight it, score each option, total it. It doesn’t remove judgment, but it forces the judgment into the open rather than leaving a decision that “felt right” for reasons nobody can name afterward. It’s a reasonable tool for the calls that are genuinely yours to make — the harder, related skill from this session is recognizing early which decisions are above your authority and belong in someone else’s hands, and escalating those quickly rather than deciding them anyway. (Kandis Porter, Effective Flow Connections)

A small, honest detail from the session itself

Partway through the discussion of urgent-versus-important, the instructor’s phone rang — an actual client escalation, mid-lecture on how to handle actual client escalations. He paused, said “I have a coaching session going on, I’ll do it after 15 minutes,” and kept teaching. It’s a small thing, but it’s the entire session’s argument happening in real time rather than as a hypothetical: state what’s happening, don’t go quiet, delegate the response, and don’t let a second urgent thing derail the first one you already committed to.

Coming up next

Time ran out before the session could get to two things Harpreet flagged as next up: the RAPID decision framework (who Recommends, who must Agree, who Performs, who gives Input, and — critically — exactly one person who Decides) and how to maintain a decision and escalation register. Both get their own full write-up once that session actually happens, rather than guessed at here from a syllabus line.

---

Previous: Session 5 — Applying COIN in the Real World, and Coaching vs. Mentoring vs. Managing · Back to the series index

Sources:

• Google SRE Book — Postmortem Culture: Learning from Failure
• Michel Baudin — Origin of One-Piece Flow at Toyota
• WHO Surgical Safety Checklist — Adaptation Guide
• Todd Adkins, LifeWay Leadership — 90 Second Leadership: Agile Decision Making
• Get Agile podcast (ProCognita) — Leadership Agility for Better Decision Making, with Pete Behrens
• Kandis Porter, Effective Flow Connections — Decision Making Made Easy