Category: Operating Models & Flow

How software organisations actually deliver: team-of-teams structure, flow economics, cost of delay, and the constraints that decide throughput. Reading the system, not blaming the team.

  • Your Paradigms, Made Visible: A Mirror for Executives in Software-Dependent Firms

    Your Paradigms, Made Visible: A Mirror for Executives in Software-Dependent Firms

    Executive summary

    Think of a physiotherapist. They don’t fix your back. They put a mirror in front of you, show you the exact posture you’ve been holding for fifteen years, and say: “notice you’re doing that? that’s why you’re in pain.” The pattern was invisible from the inside. Once it’s visible, the work is small corrections, practised many times, especially under load. This piece is that kind of mirror.

    NB. The dichotomies below are mostly not original to me; the curation and the synthesis are. I name teachers in each entry and link to their work so you can go upstream when something resonates. If this mirror surfaces something worth working, the people whose names appear in the Watch and Read lines are where I’d send you next. Or me⁠—this is the work I do.

    When senior leaders see the operating paradigms they have been running on, the calls they make under pressure stop surprising them. With that, the response that better fits the new situation becomes available. The work I do with leaders suggests most are running paradigms they cannot see, built for problems the firm no longer has, in territory the paradigms weren’t built for. AI is the most visible driver of the changing context, but not the only one. The piece below offers a mirror for seeing what’s running underneath: 28 observable decision-level dichotomies, written as prompts to compare what you say you believe to what you actually do.

    This is the canonical long-form treatment of the work; a shorter, axis-by-axis article series will follow for readers who want to take it in smaller doses.

    Who this is for, who it isn’t. This is for senior leaders of software-dependent firms whose situation-mix has shifted toward complex, unpredictable work: long-term survival under uncertainty, AI-era operating-model threats, leading technology-driven market disruption. You might suspect the mindset that got you where you wanted to be yesterday isn’t fitting what your new context needs today, or you might find yourself in the midst of a crisis. It isn’t a leadership-style typology, a developmental ladder, or a self-administered test. You are not broken and do not need fixing; you are simply running on paradigms that fit a context you have since left. If your work is genuinely and predominantly Complicated/Ordered (regulated compliance, financial close, structural engineering, mature manufacturing on a stable specification), the classical management paradigms are possibly sufficient. That said, almost no senior role in a software-dependent firm is purely Complicated/Ordered anymore: take thirty minutes anyway, and notice how much the circumstances have shifted underneath you.

    The diagnostic question. Most knowledge work has been Complex/Unordered for decades: the territory where the answer isn’t knowable in advance, only discoverable by probing (Dave Snowden’s Cynefin, defined more fully in “The frame” below). What changed is the cost of mismatch. The Complicated/Ordered habits⁠—the classical management toolkit, built for work where experts can analyse the problem to a known good answer⁠—could carry a slow-moving firm through a Complex/Unordered situation as long as the consequences of being slightly wrong arrived slowly too. With AI accelerating the consequences and reshaping the substrate, the gap between the leader’s habitual response and what the situation actually requires now compounds in months rather than years. So the diagnostic question is: my role has been Complex/Unordered all along; is my habitual response still fitting now that the cost of mismatch is, for a growing number of firms, terminal?

    On Chegg’s May 2023 earnings call, CEO Dan Rosensweig named ChatGPT as the threat to new-customer growth; they launched CheggMate, their OpenAI-built tutoring product, the same month. Three years later the market cap is down roughly 99% from its 2021 peak, headcount has fallen from ~3,200 to under 600, and the Q1 2026 homework business is down 57% year-on-year. They posted their first profit in two years by cutting costs faster than revenue fell. Awareness was not the limiting factor; the org could not redesign around the substrate shift in time.

    The three most important paradigm dichotomies for most readers in 2026. If you read nothing else, read these:

    • Entry 1, AI as superficial productivity layer vs AI as substrate for org redesign. The dichotomy that decides whether the firm’s AI investment compounds or runs out as a local productivity uplift that doesn’t translate to revenue.
    • Entry 6, Utilisation vs flow. The dichotomy that decides whether AI speeds your system up or just relocates the queue.
    • Entry 11, Espoused theory vs theory-in-use. The dichotomy that decides whether your stated principles survive contact with your last three decisions under pressure.

    The six paradigm axes and the two poles. Each axis asks where your operating reflex sits. Pole A is the move that often feels like leadership; Pole B is what the Complex/Unordered contexts reward most. Both poles have bounded applicability, neither is correct for all contexts. The question is whether your habitual response fits the situations you actually meet.

    Change: how this leader produces change.

    • 1. AI bolted onto the existing organisational design, or the organisational design entirely reconsidered around AI.
    • 2. Announce the change programme and run training, or redesign what surrounds the behaviour so the new move is the easier move.
    • 3. Write the strategy and roll it out, or design the conversation that produces the strategy.
    • 4. Ship a directive, or ship a question and an open week.
    • 5. Send people on courses, or block thirty minutes a day for coaching at the work.

    Optimisation: how this leader reads the unit of value and the shape of waste.

    • 6. Keep everyone fully utilised, or keep queues and lead times short.
    • 7. Penalise plan variance, or plan a hypothesis and an experiment.
    • 8. Set efficiency targets per function, or find the one constraint and subordinate everything to it.
    • 9. Celebrate the launch, or celebrate the customer succeeding three months later.
    • 10. Long roadmaps and/or Planning Intervals, or continuous flow, WIP limits, and pull.

    Knowledge: what this leader treats as legitimate knowledge.

    • 11. Judge yourself by your intentions, or judge yourself by your last three decisions under pressure.
    • 12. Project certainty, or voice a hypothesis and the test that would falsify you.
    • 13. Run the checklist, or trust the experienced operator.
    • 14. Standardise across business units, or protect what the local team already knows how to do.
    • 15. Convene more analysis when stuck, or pause and check what the experienced operator already senses.

    Authority: how this leader reads power, decision rights, and their own role.

    • 16. Fill coordination channels with approvals, or fill them with “I intend to…”
    • 17. Decide where the formal power is, or decide where the tacit knowledge actually lives.
    • 18. Get the work out of people, or get out of people’s way.
    • 19. Be the hero, or build up your successors.
    • 20. Cascade the OKRs down the org, or redesign decision rights so the org can move without you.
    • 21. Open with the answer, or open with a question you don’t already know the answer to.
    • 22. Be the deepest expert in the room, or convene the people who know.

    Causation: how this leader reads the relationship between events and their causes.

    • 23. Find the deviator who failed, or close the gap between the work as imagined and the work as done.
    • 24. Count incidents, or study what works well (not just what broke).
    • 25. Tell one clean story, or hold several stories at once.

    Self: how this leader reads their own identity, capacity, and developmental edge.

    • 26. Hold the role as who you are, or hold it as what you’re currently doing.
    • 27. Be surprised by your own pattern when it surfaces, or name the anxiety driving it.
    • 28. Defend the decision after it fails, or refine your mental models after they fail.

    15 minutes today. Look back at the six axes above. For each axis, notice which pole you sit closer to. Where you sit on the first pole, ask: where did this assumption come from, and is it still fitting the work you actually do now? That alone will be enough to start the noticing the rest of the article is built around.

    If the 15-minute pass surfaces something worth more than a glance, continue reading and work the two-week protocol in How to use this mirror at the end.

    Why a mirror, and why now

    Jennifer Garvey-Berger puts it plainly: “We get so used to our patterns that we can forget what the situation calls for and just rely on our own habits.” That is the diagnostic problem this mirror addresses.

    A senior leader who has read this far is still left with a practical question. Which paradigm am I actually running? The intellectual answer is almost always the flattering one. The honest answer lives in last Tuesday’s meeting, in the calls I made under pressure when nobody was watching me make them.

    This mirror is ultimately meant to be used in conversation: with a coach, a trusted peer, a few witnesses willing to compare what you say to what they actually saw you do.

    It shows you what habit has hidden from you. The change is the small correction⁠—repeated under load⁠—in the conversations that follow. One mirror is rarely enough; like a physiotherapist’s, the role is distributed across several people who will keep showing you the same pattern from slightly different angles until you can feel it yourself. You’ll need at least a consultant who understands the paradigms and a developmental coach who can help you through the change; these are rarely the same person.

    The frame: the situation-mix in your role has shifted

    Snowden’s Cynefin distinguishes five kinds of situation:

    • Clear. Best practice, fixed constraints, self-evident cause and effect.
    • Complicated. Good practice via expert analysis, knowable causal relationships, governing constraints.
    • Complex. Exaptive practice via probing, enabling constraints, emergent and dispositional behaviour (which is interestingly something an LLM also embodies).
    • Chaotic. Novel practice, no effective constraints.
    • Confused. Knowing which domain you are in is itself the question.

    Cynefin is a sense-making framework for assessing situations, not for typing leaders. The same leader routinely meets situations in all of those domains and is asked to respond to each.

    The diagnostic question this piece works with is therefore not “which domain do you operate in.” It is: has the situation-mix in your role shifted toward Complex/Unordered work, and does your habitual sense-making mode fit the situations you now meet?

    For most senior leaders in software-permeated firms, the answer to the first half is plainly yes. Strategy under genuine uncertainty, leadership transitions, cross-functional change, AI-era organisation redesign, talent dynamics, market position under technological disruption: these are all Complex/Unordered. This has been true for most knowledge workers for decades. The classical management toolkit was built for Complicated/Ordered work⁠—regulated compliance, financial close, structural engineering, mature manufacturing⁠—and remains right in that domain. The trouble starts when a Complicated/Ordered habit meets a Complex/Unordered situation and treats it as if the answer were knowable.

    Ronald Heifetz puts the same diagnostic in a different vocabulary:

    • Technical problems have known solutions accessible through current authority and expertise: forecast, plan, hold the plan as the basis for accountability; when results slip, take more direct control or buy the answer.
    • Adaptive problems require changes in values, beliefs, roles, or relationships, and no single action controls the outcome: run safe-to-fail experiments, hold the group in productive disequilibrium, let pattern emerge.

    Heifetz’s adaptive-vs-technical and Snowden’s Complex/Unordered-vs-Complicated/Ordered are similar diagnostics at different scales; every entry below is a slice of the larger question: what does this leader do when the response that used to work no longer fits the situation?

    Watch. Two videos frame the rest of the article:

    A worked example: Theory X vs Theory Y

    I learned this exercise from Bas Vodde. Draw a horizontal axis. Theory X to the left (workers cannot be trusted, require coercion and control), Theory Y to the right (work can be as natural as play, people seek responsibility and meaning). Sticky-notes above the line are people’s observations of their colleagues’ attitudes and behaviours. Sticky-notes below the line are observations of the organisational context they’re operating inside. The gap between the two rows of sticky-notes, when it appears, is the data:

    • Pole A, Theory X. Design control structures around the worst-case employee; oversight as the default; trust as a reward earned through visible compliance.
    • Pole B, Theory Y. Design control structures around the average employee; trust the system to handle the exceptions; remove obstacles and let people do good work.
    • Where Pole A is right. Genuinely high-stakes regulated work where the cost of a single bad actor is catastrophic: nuclear plant control rooms, aviation cockpit checklists, surgical theatre protocols, anti-money-laundering compliance. The structural Theory X is not a failure of trust; it is the right engineering response to a Clear- or Complicated-domain risk surface in a low-variance context.
    • Where Pole B is right. Most creative work, most knowledge work, genuinely Complex cross-functional decisions, almost any role where intrinsic motivation is doing the real work.
    • What it looks like in decisions. Pole A leaders write detailed approval workflows for spending below $5k. Pole B leaders set a budget and let the team allocate.
    • Source. Douglas McGregor.

    The larger mirror

    Here are all 28 paradigm dichotomies, sorted into six roughly-organising axes.

    Change: how does this leader read and produce change?

    1. AI as productivity layer vs AI as substrate for org redesign.

    • Pole A. AI is a tool that makes existing roles faster, cheaper, or more leveraged. The organisation chart, role boundaries, and career ladders stay; capable people get more done. Pole A treats AI as adoption.
    • Pole B. AI is a substrate that re-shapes which work is human and which is not. The valuable human role broadens rather than narrows: the builder, or skilful generalist, who can define an outcome, specify the constraints, choose which work goes to AI and which stays human, and verify what comes back. The narrow specialist’s economic logic⁠—expertise is scarce and demand for it is unlimited⁠—is the assumption AI dissolves. Pole B treats AI as redesign and treats the generalist as the new load-bearing role.

    Pole A is right where the work is genuinely procedural, the regulatory or domain constraints prevent role redesign within the planning horizon, or the firm is buying time to learn what to redesign. Pole B is right wherever the planning horizon is shorter than the rate of capability change in the AI substrate, or where competitors are already redesigning.

    In decisions: Pole A leaders sponsor AI-rollout programmes inside existing job families and ask “what’s the productivity uplift?”; Pole B leaders ask “which work is now human, which is now AI-supervised, which is now AI-autonomous, and what does the role⁠—if any⁠—on the other side actually look like?” They accept that the answer reshapes the entire organisation’s strategy, process, people, structure, and rewards. The traps on both sides are different. Pole A leaders may well discover two years late that their biggest cost curve was the incumbent org design itself, not tokens. Pole B leaders get the org design right (adaptive topology, broadened mandates, smaller teams of builders) but might bet specific designs on AI capabilities that aren’t yet stable, and have to walk those back.

    The builders carrying the substrate shift in the firms I see doing it well tend to share a profile: high pattern-recognition across domains, liberal-arts-educated as much as they are technically trained, comfortable holding business, technical, and human-systems vocabulary in the same sentence. They are noticeably less patient with the status quo than average. The org-design literature names the role (multi-learning, M-shaped, expert generalist) but undersells how specific the profile is. Hiring for it is harder than hiring for the role it replaces.

    Watch. Craig Larman, Craig Larman’s Take on 10X ORG: Why He Thinks This Book Matters (5 min). Names the dichotomy directly: Pole A as the cost-curve trap (“AIs cheap as dirt, 24/7, no vacation, humans won’t compete by suggesting ‘hire me, I’ll make you 10% better’”), Pole B as 10x redesign rather than 10% improvement, with 10xOrg, Org Topologies, and LeSS. Companion: the Reinertsen video from entry 6 for the flow-economics half.

    Read. Org Topologies (start with their primer) and 10xOrg on org-design at AI-substrate scale; Jay Galbraith, Designing Organizations (Star Model) on the model that underpins much of Org Topologies and 10xOrg; and Reinertsen, The Principles of Product Development Flow, on what happens to flow and cycle time when the speed of individual process steps changes faster than the surrounding system.

    2. Pushing people vs changing the conditions.

    • Pole A. Produce change by force of will: announce the programme, run the training, hold people accountable for the new behaviour.
    • Pole B. Produce change by shifting what surrounds the behaviour: the path (incentives, friction, information flow) and/or the operating system (the meaning-making that produces the behaviour in the first place). Pole B has two flavours: environmental design (change the situation, behaviour follows) and developmental work (change the mindset, behaviour becomes durable). Change the organisation design and the behaviours will also change.

    Pole A is right in time-critical regulatory or competitive shifts where the new behaviour is specifiable and adoption speed is the binding constraint. Pole B is right whenever the change is adaptive rather than technical, or whenever Pole A compliance reliably decays the moment pressure relaxes.

    In decisions: Pole A leaders announce programmes and run training; Pole B leaders redesign the environment so the new behaviour is the easier behaviour, and accept that the deeper version of the work is developmental, takes much longer than scheduled, and treats early relapse as “not yet” (in Heath & Heath’s frame from Switch, drawing on Carol Dweck) rather than as failure. Training is still valuable⁠—especially when it transmits difficult-to-document embodied wisdom⁠—just not sufficient.

    Watch. Dan Heath, Leading a Switch (10 min).

    Read. Heath & Heath, Switch; Donella Meadows, Thinking in Systems, on leverage points; Robert Kegan, In Over Our Heads; Kegan & Lahey, Immunity to Change, on praxis.

    3. Content vs process.

    • Pole A. Get the right answer; convince others; the decision itself is the work.
    • Pole B. Get the right way of deciding; the quality of the process determines the quality and durability of the decision.

    Pole A is right when the answer is genuinely knowable and the legitimacy of the decision is not at stake: the technical call on a deployment rollback, the regulatory interpretation, the budget reallocation inside an already-agreed envelope. Pole B is right when the decision will be implemented by people who weren’t in the room and whose ownership of the decision is what makes it stick, which is most systemic decisions.

    In decisions: Pole A leaders write the strategy and roll it out; Pole B leaders design the conversation that produces the strategy.

    Watch. Roger Schwarz, Smart Leaders, Smarter Teams (4 min): the leader as architect of how the team thinks together, not just decider of what gets decided.

    Read. William Noonan, Discussing the Undiscussable; Edgar Schein, Process Consultation Revisited; Schwarz, Smart Leaders, Smarter Teams.

    4. Mandate vs invitation.

    • Pole A. Authority issues the requirement; people comply.
    • Pole B. Authority articulates purpose; people enrol or commit; compliance is the floor, not the goal.

    Pole A is right when speed is binding and the cost of partial enrolment is acute. Pole B is right when the work depends on enrolment for any durability.

    In decisions: Pole A leaders ship a directive; Pole B leaders ship a question and an open week.

    Watch. Peter Senge, On Shared Vision (2 min): on the compliance-to-commitment ladder and why a vision has to be talked about with people, not told to them. Companion: Frederic Laloux, 1.2 What truly drives you? (Thought for top leaders) (10 min) on speaking from the why rather than mandating the what. The University Hospital CEO story shows the exact moment a leader stops mandating concepts and resistance vanishes.

    Read. Senge, The Fifth Discipline, on the seven attitudes-toward-a-vision spectrum; Laloux, Reinventing Organizations, on the advice process; Heifetz, The Practice of Adaptive Leadership.

    5. Training vs practice.

    • Pole A. Episodic, off-site, formal; the classroom is the venue.
    • Pole B. Daily, embedded in work, mentor-mentee at the gemba; the workplace is the venue.

    Pole A is right when the content is genuinely transferable from classroom to context and the transfer overhead is low: compliance certifications, language fluency, formal credentialing requirements, software platform onboarding for stable tools. Pole B is right when the content lives in the situated work and the classroom abstraction loses most of what matters: coaching skills, judgment under uncertainty, leadership behaviour under threat, and almost any capability the leader cares about in their senior people.

    In decisions: Pole A leaders send people to courses; Pole B leaders block thirty minutes a day for coaching cycles at the work.

    The exception worth naming: well-designed games, simulations, and case-based kata are training in venue but Pole B in substance. They transmit the tacit pattern-library⁠—the mētis⁠—that “sage on the stage” classroom abstraction usually can’t carry. Donald Schön’s practicum, Gary Klein’s recognition-primed decision simulation work, and Ikujiro Nonaka’s socialisation mode in SECI all name this third space. The diagnostic isn’t the venue; it’s whether the content is codified or situated.

    Watch. Mike Rother, Toyota Kata (10 minutes) (11 min).

    Read. Rother, Toyota Kata; Amy Edmondson, Right Kind of Wrong; Schön, The Reflective Practitioner, on the practicum; Klein, Sources of Power, on RPD simulation; Nonaka & Takeuchi, The Knowledge-Creating Company, on socialisation in SECI.

    Optimisation: what is the unit of value, and how does this leader read waste?

    6. Utilisation vs flow.

    • Pole A. Keep resources busy; idle capacity is waste; efficiency reports are the management metric; manage cost first.
    • Pole B. Throughput is the goal; queues are the enemy; capacity margin is a feature, not a bug. As utilisation climbs toward 100%, queue time dominates cycle time and small upsets in arrivals cascade into long delays.

    Pole A is right in genuinely fixed-throughput operations with stable demand and homogeneous work: call centres on routine queries, very mature manufacturing lines. Pole B is right in any system with variable demand, heterogeneous work, or genuinely }Complex/Unordered prioritisation.

    In decisions: Pole A leaders allocate every engineer to a project and ask “are you fully booked?”; Pole B leaders protect slack, accept idle time at non-constraints, and ask “what are my queue lengths” as a leading indicator of lead times.

    Watch. Henrik Kniberg, The Resource Utilization Trap (6 min). Recommended if you have the time: Don Reinertsen, The Logic of Flow: Some Indispensable Concepts with slides (33 min).

    Read. Reinertsen, The Principles of Product Development Flow; Eliyahu Goldratt, The Goal; Daniel Vacanti, Actionable Agile Metrics for Predictability.

    7. Plan as commitment vs plan as hypothesis.

    • Pole A. Strategy as document, vision as destination, plan as commitment; decide early, execute against the commitment; variance is failure.
    • Pole B. Strategy as verb; set direction, find adjacent possibles; treat each plan as a hypothesis with an expected outcome; check; act on the difference; “cross the river by feeling the stones.”

    Pole A is right when the planning horizon is shorter than the rate of change, the cost of changing the plan is high, and accountability requires commitment. Pole B is right when none of those is true.

    In decisions: Pole A leaders penalise plan variance and demand a guarantee; Pole B leaders demand a hypothesis and an experiment, update the plan, and treat the update as evidence the strategy is working.

    Watch. Mary Poppendieck, The Tyranny of “The Plan” (60 min, transcript also available on LinkedIn; this is canonical and well worth the time).

    Read. Poppendieck, Lean Software Development and Leading Lean Software Development; Reinertsen, The Principles of Product Development Flow; Snowden citing Henry Mintzberg, The Rise and Fall of Strategic Planning; Klein, Sources of Power, on the premortem; Rother, Toyota Kata, on schedule-as-hypothesis citing Novalis via Popper.

    8. Local optima vs system constraint.

    • Pole A. Improve each department on its own metrics; the whole will improve as a sum.
    • Pole B. Identify the one constraint that limits the whole, exploit it, subordinate everything else to it. “A system of local optimums is not an optimum system; it is a very inefficient system.”

    Pole A is right only when the system genuinely decomposes: independent product lines, separate geographies, decoupled value streams with no shared constrained resource. But most systems leaders think decompose don’t. The resources, the people, the queue capacity, the management attention all run through shared bottlenecks the org chart hides. In manufacturing⁠—a Complicated/Ordered domain⁠—Goldratt demonstrates that local efficiency improvements on non-bottleneck resources reduced plant throughput, by pushing more work onto the bottleneck and consuming time that couldn’t be recovered. W. Edwards Deming’s funnel experiment proves the same point for stable production processes: tampering with common-cause variation makes the variance worse, not better. The claim isn’t restricted to Complex/Unordered work; it holds anywhere events depend on prior events and demand has variability, which is nearly every system a senior leader actually meets.

    In decisions: Pole A leaders set utilisation targets per function; Pole B leaders ask “which one resource, today, is governing how fast the whole system can move?” and protect it.

    Watch. Goldratt, Lectures: Thinking Globally (10 min). Companion (constraint physics): Theory of Constraints (TOC) 3 Bottle Oiled Wheels Demonstration (5 min).

    Read. Goldratt, The Goal; Deming, Out of the Crisis, on common-cause variation and the funnel experiment; Senge, The Fifth Discipline.

    9. Output vs outcome.

    • Pole A. The unit of management is units shipped, features released, work completed.
    • Pole B. The unit of management is customer progress, market position, mission impact.

    Pole A is right when output and outcome have been demonstrated to track each other tightly in the relevant domain: a sales organisation on a mature product where deals booked do convert to revenue, a fulfilment operation where units shipped equals customer demand met, a regulatory pipeline where filings submitted equals approvals secured. Pole B is right whenever the firm is producing more output and getting worse outcomes, a common pattern in feature-factory product organisations and in any system where the output metric has become the goal rather than the proxy.

    In decisions: Pole A leaders celebrate the launch; Pole B leaders celebrate the customer using the thing successfully three months later.

    Watch. Jeff Patton, Output vs Outcome & Impact (11 min).

    Read. Clayton Christensen, Competing Against Luck (Jobs to Be Done); L. David Marquet, Leadership Is Language; Reinertsen, The Principles of Product Development Flow.

    10. Batch and push vs single-piece and pull.

    • Pole A. Aggregate work into larger units to amortise setup costs; schedule and dispatch work to resources based on forecast; central plan governs.
    • Pole B. Reduce batch size; resources pull work when they have capacity; demand signal at the customer end governs upstream.

    Pole A is right when setup costs are genuinely fixed and high, forecast accuracy is high, and the cost of inventory is low (classical EOQ logic in mature physical operations). Pole B is right in any context where setup costs can themselves be reduced and the learning rate matters, or where forecast accuracy is low.

    In decisions: Pole A leaders schedule long roadmaps and allocate capacity by Planning Interval; Pole B leaders ship continuously, set WIP limits, and let teams pull from a ruthlessly prioritised and pruned backlog.

    Watch. Kniberg, High WIP vs One Piece Flow Example (7 min); Reinertsen, GOTO 2012 Interview on flow (24 min). Companion (short hook): Reinertsen, Economics of Batch Size and the “Father-Egg” Story (4 min).

    Read. David J. Anderson, Kanban; Reinertsen, The Principles of Product Development Flow; Poppendieck, Lean Software Development.

    Knowledge: what does this leader treat as legitimate knowledge?

    11. Espoused theory vs theory-in-use (Model I vs Model II).

    • Pole A. The leader’s stated principles, values, and intentions are taken as the relevant data; when results miss, change the action while leaving the underlying assumptions intact. Under threat or embarrassment, Model I governs: win not lose, be rational, avoid upset, support others by telling them what they want to hear; the four social virtues that quietly underwrite organisational defensive routines. “The problem is not me, but you.”
    • Pole B. The leader’s actual behaviour, especially under threat or embarrassment, is taken as the data. The gap between espoused and in-use is the diagnosis. Under threat, Model II governs: grant legitimacy to others’ views, assume partiality of one’s own, attribute positive intent, acknowledge impact and contribution. “Aggressive and vulnerable”: strong advocacy paired with genuine inquiry into one’s own contribution.

    Pole A is right for external communication: stated principles need to be stated clearly, and an organisation needs them on the record. Pole B is right for the leader’s own self-assessment, and for any conversation where defensive reasoning is already running and the next decision will repeat the last one unless the gap is named. Most leaders, by their own report later, find Pole A was running underneath their Pole B account in at least some of the territory.

    In decisions: Pole A leaders judge themselves by their intentions, run after-action reviews on the what, and end disagreements with a winner; Pole B leaders judge themselves by their last three observable interactions, run after-action reviews on the what we believed coming in, and end disagreements by asking which observable example would change the other person’s view, and whether the same example would change theirs. This dichotomy is the load-bearing wall of this mirror: every other entry can be self-reported into the flattering pole, and only the gap between espoused and observed produces signal the leader didn’t already have.

    Watch. Roderic Yapp, Double-loop learning: a case study from the front-line (TEDxWandsworth, 17 min): two front-line case studies, Afghanistan platoon houses and then a mental-model challenge, that name the espoused/in-use gap directly. Companion: Chris Argyris, Chris Argyris Talks About Culture and Management (4 min). The framework’s primary author in his own voice, defining theory-in-use and running the canonical “bypass the threat, cover up the bypassing, cover up the covering up” sequence.

    Read. Noonan, Discussing the Undiscussable, in the Argyris/Schön/Action Design lineage; Argyris, Overcoming Organizational Defenses; Schön, The Reflective Practitioner; Senge, The Fifth Discipline; Edmondson, The Fearless Organization, on situational humility.

    12. Certainty vs honest uncertainty.

    • Pole A. Strong, confident, resolute positions communicate competence; doubt is weakness.
    • Pole B. Lack of certainty is strength; certainty is arrogance. Think out loud; voice context and hunches; invite challenge; make 90% confidence interval predictions and audit calibration after.

    Pole A is right in genuine emergencies⁠—Chaos in Cynefin terms⁠—where projected confidence is the team’s anchor and the cost of paralysis exceeds the cost of being wrong. Pole B is right almost everywhere else, especially in low-validity decision domains where confidence tracks coherence of story rather than quality of evidence.

    In decisions: Pole A leaders make point predictions and defend them; Pole B leaders advance positions with the test that would falsify them.

    Watch. Julia Galef, Why you think you’re right — even if you’re wrong (TED, 12 min). Companion: Kathryn Schulz, On Being Wrong (TED, 18 min).

    Read. Marquet, Leadership Is Language, on “Think Out Loud”; Daniel Kahneman, Thinking, Fast and Slow, on confidence as coherence of story; Doug Hubbard, How to Measure Anything; Garvey-Berger, Unlocking Leadership Mindtraps, on the rightness mindtrap; Galef, The Scout Mindset.

    13. Analysis vs recognition.

    • Pole A. The right answer comes from listing the options, comparing them against criteria, and choosing the best. Deliberate analysis is what makes a decision defensible.
    • Pole B. The right answer comes from recognising the situation as one the experienced operator has seen before, generating one workable course of action, and mentally simulating it forward. Pattern-recognition is what makes a decision fast and, in the right conditions, reliable.

    Pole A is right when the environment is irregular, feedback is delayed or absent, the stakes are high enough that the decision will be publicly justified, or the operator is not yet experienced enough for Pole B to be trustworthy. Pole B is right when the environment is regular enough that experience has built trustworthy patterns and feedback is rapid enough to keep those patterns calibrated: emergency response, surgical theatre, deployment rollback, anything an expert has done a thousand times. Klein and Kahneman, who spent years disagreeing about whether expert intuition was real, eventually agreed: it is real where the environment is regular and feedback is rapid, and it is unreliable everywhere else. That joint conclusion is the diagnostic for which pole fits.

    In decisions: Pole A leaders introduce a checklist or formal review where stakes are high and feedback is poor; Pole B leaders trust the experienced operator’s first reasonable option and notice when the situation has slipped outside the territory the operator’s experience covers.

    Watch. Kahneman, Thinking Fast vs. Thinking Slow (Inc. Magazine, 7 min). Companion: Klein, Introduction to NDM and RPD (9 min).

    Read. Klein, Sources of Power; Kahneman, Thinking, Fast and Slow, on the Kahneman-Klein agreement.

    14. Codifiable vs situated knowledge.

    • Pole A. Knowledge that matters is universal, codified, decomposable, teachable as formal discipline; standards, documentation, and knowledge-management systems are the organisation’s memory.
    • Pole B. Most operating knowledge is local, implicit, and held by practitioners: James C. Scott’s mētis, Nonaka’s tacit knowledge, the river pilot’s feel for the one harbour. Mentor-mentee transmission and shared experience are the real infrastructure.

    Pole A is right where the work is genuinely procedural, the knowledge is genuinely codifiable, and personnel turnover is high enough to need it. Pole B is right wherever a work-to-rule strike would halt the operation, which is almost everywhere outside fully automated processes.

    In decisions: Pole A leaders standardise practices across business units and invest in documentation; Pole B leaders ask the local team what they already do that the standard fails to capture, protect it, and invest in senior staff coaching junior staff at the work.

    Watch. Rother, Toyota Kata (11 min). Humourous example: Exact Instructions Challenge (7 min).

    Read. Venkatesh Rao, A Big Little Idea Called Legibility (essay, ~20 min); Scott, Seeing Like a State; Nonaka & Takeuchi, The Knowledge-Creating Company, on the SECI model; Rother, Toyota Kata.

    15. Knowing vs sensing.

    • Pole A. Information is gathered, analysed, decided upon; the cognitive faculty is the relevant tool.
    • Pole B. The body knows before language does; felt sense, presence, embodied attunement are signal, not noise.

    Pole A is right when the situation is tractable enough that analysis converges and the body’s signal is dominated by cognitive bias. Pole B is right when the situation is intractable, analysis has converged on a position the body finds suspect, and the suspicion is data.

    In decisions: Pole A leaders convene more analysis when stuck; Pole B leaders pause, attend to body, name the discomfort, and let the next move emerge.

    Watch. Eugene Gendlin, Focusing (Nada Lou archive, 12 min). Gendlin himself on felt sense: “the body has its own take on what’s going on… more subtle, more intricate… you walk by the familiar feelings… one more step.”

    Read. Gendlin, Focusing; Otto Scharmer, Theory U; Steve March, Alētheia coaching at integralunfoldment.com.

    Authority: how does this leader read power, decision rights, and the leader’s role?

    16. Leader-follower vs leader-leader (and the orders that go with each).

    • Pole A. Authority lives with the leader; subordinates seek permission and report status; orders are detailed, control is by supervision, deviation is failure.
    • Pole B. Authority lives where the information lives; subordinates state intent and act, the leader replies “Very well”; orders are intent, purpose, constraints, and antigoals, with subordinates choosing the right action as conditions change.

    Pole A is right in genuine emergencies where time-to-decision is the binding constraint and command structure is what is being practised, or where the right action is precisely specifiable and the cost of unauthorised initiative is high. Pole B is right almost everywhere else, including most of what looks like an emergency, and especially where the right action depends on local conditions.

    In decisions: Pole A leaders’ calendars fill with approval meetings and they write detailed task lists; Pole B leaders’ calendars fill with conversations that begin “I intend to…” and they write a paragraph of purpose and a list of what must not happen.

    Watch. Marquet, “Greatness” (Inno-Versity) (10 min).

    Read. Marquet, Turn the Ship Around!; Reinertsen, The Principles of Product Development Flow, on Marine Corps mission orders; Poppendieck, Lean Software Development, on Auftragstaktik.

    17. Hierarchy vs network.

    • Pole A. Information flows up, decisions flow down; the org chart is the operating system.
    • Pole B. Information flows where it is needed; decisions are made where the information is; the org chart is one of several views.

    Pole A is right where regulatory accountability or genuine command structure requires it: defence, regulated finance, certain public-sector contexts. Pole B is right almost anywhere else, including in regulated industries where the structure has been kept for inertial reasons.

    In decisions: Pole A leaders re-org by redrawing reporting lines; Pole B leaders re-org by changing meeting cadence, information flow, and decision rights. Steve Jobs named the Pole B move plainly at D8 2010: Apple is “organised like a startup… run by ideas, not hierarchy.”

    Watch. Gitte Frederiksen, Great Leadership Is a Network, Not a Hierarchy (TED, 12 min). Companion: Stanley McChrystal, Listen, Learn… Then Lead (TED, 16 min).

    Read. McChrystal, Team of Teams; Laloux, Reinventing Organizations; Reinertsen, The Principles of Product Development Flow.

    18. Theory X vs Theory Y. See the worked example above. Pole A is right in two distinct contexts: genuinely high-stakes regulated work with catastrophic-bad-actor risk (pharmaceutical batch release, nuclear plant control rooms, anti-money-laundering compliance, aviation cockpit procedure), and routine low-skill, low-discretion work where the task itself doesn’t generate intrinsic motivation and the structure is doing the load (high-turnover transactional roles, certain warehouse or contact-centre tasks where the work is the work and capability development sits outside it). Pole B is right in most knowledge work, most cross-functional work, and most situations where intrinsic motivation is doing more of the load than the control structure can see.

    Watch. Dan Pink, RSA ANIMATE: Drive — the surprising truth about what motivates us (11 min).

    Read. McGregor, The Human Side of Enterprise.

    19. Hero vs steward.

    • Pole A. The leader’s authority and competence drive the team; subordinates execute; the leader takes personal credit for success and personal responsibility for failure; the organisation orbits the leader’s competence.
    • Pole B. The leader retains final authority but creates highly participative teams; builds capacity that outlives them; the test of leadership is what happens after they leave.

    Pole A is right in genuine crisis where personal visibility holds the team together, and is over by the time the crisis ends. Pole B is right almost everywhere else.

    In decisions: Pole A leaders close debates by deciding, accept extension after extension because the organisation “needs them”; Pole B leaders close debates by surfacing the disagreement and inviting the team to decide, and measure success by their successor’s competence.

    Watch. Marquet, How Great Leaders Serve Others (TEDxScottAFB, 18 min). Companion: Peter Anderton, Great leadership comes down to only two rules (TEDxDerby, 17 min).

    Read. Marquet, Turn the Ship Around!, on “don’t be missed after you depart”; Jim Collins, Good to Great, on Level 5 leadership; Joiner & Josephs, Leadership Agility.

    20. Orange vs Teal.

    • Pole A. Organisation as machine; meritocracy, MBO, KPIs, R&D, balanced scorecards; effectiveness as the yardstick.
    • Pole B. Organisation as living system; self-management, wholeness, evolutionary purpose; sense-and-respond rather than predict-and-control.

    Pole A is right in tractable, stable industries with well-understood competitive dynamics: regulated utilities, mature consumer staples, infrastructure with predictable demand. Pole B is right in industries undergoing genuine technology-driven disruption where the planning horizons no longer track the disruption rate, which is most software-permeated industries right now.

    In decisions: Pole A leaders run quarterly cascades of OKRs; Pole B leaders run quarterly listening practices to “what the organisation wants to become.”

    Watch. Laloux, 2017 CEO Summit talk (30 min).

    Read. Laloux, Reinventing Organizations.

    21. Telling vs asking.

    • Pole A. The leader’s job is to know the answer and communicate it clearly. Effective leadership is articulate direction; effective change is handing the team the answer, the plan, the playbook.
    • Pole B. The leader’s job is to surface the information needed for good decisions. Ask questions to which you do not know the answer; let the team find the answer; develop capability, not just compliance.

    Pole A is right when the leader genuinely knows the answer, the team genuinely does not, and either the cost of getting the answer wrong is high or the team genuinely lacks the prerequisite skill and the cost of failure is high. Pole B is right whenever the leader is acting from confident position on a question the team is closer to than the leader is, or whenever the leader is solving problems faster than the team can grow into.

    In decisions: Pole A leaders open meetings with a position statement and shorten meetings by deciding faster; Pole B leaders open with “What’s on your mind?” and lengthen meetings by asking the five Toyota Kata questions, accepting that the team’s answer may be better than theirs.

    Watch. Michael Bungay Stanier, How to Tame Your Advice Monster (TED, 14 min).

    Read. Schein, Humble Inquiry; Stanier, The Coaching Habit; Rother, Toyota Kata.

    22. Expert vs facilitator.

    • Pole A. The leader is the most senior technical authority; problems are escalated up to where the expertise is.
    • Pole B. The leader’s role is to make others’ decisions possible; expertise lives at the work.

    Pole A is right when the leader is genuinely the deepest expert and the call is technical: the founding CTO making the last call on a core architecture decision, the chief surgeon overruling on the table, the lead investigator on a specific case. Pole B is right when the leader’s expertise is a layer or two removed from where the work is actually being done, which is almost every senior leadership context outside narrow technical-founder situations.

    In decisions: Pole A leaders are the technical decider on contested calls; Pole B leaders convene the people who know and facilitate the call they make.

    Watch. Schein, Humble Inquiry (lecture, 21 min).

    Read. Joiner & Josephs, Leadership Agility; Schein, Humble Inquiry.

    Causation: how does this leader read the relationship between events and their causes?

    23. Deviation vs conditions.

    • Pole A. When work goes wrong, the explanation is a deviation: from procedure, from competence, from intent. The fix clarifies the standard or addresses the deviator. “Human error” is a sufficient diagnosis.
    • Pole B. Real work continually adjusts to underspecified conditions; the gap between work-as-imagined and work-as-done is where both safety and risk live. Failure is the unexpected combination of normal variability; “human error” is a symptom of that gap, not a diagnosis.

    Pole A is right in tractable Complicated/Ordered failures: a broken bearing, a software null-pointer exception, a structural calculation error, an individual whose behaviour was genuinely reckless. Pole B is right in any incident where the failure was the unexpected combination of normal variability, which is most of what goes wrong in Complex/Unordered work.

    In decisions: Pole A leaders write performance-management documents, root-cause reports, and policy clarifications; Pole B leaders go to the gemba (the Japanese term for “the actual place”, where the work happens), ask “what surprised you? where did you have to improvise?”, and change the system people are operating within.

    Watch. Sidney Dekker, Safety Differently (2018 lecture, 33 min). Software-native companion: John Allspaw, How Your Systems Keep Running Day After Day (DevOps Enterprise Summit 2017, 33 min).

    Read. Cook, Allspaw, Woods et al., The Stella Report; Dekker, Drift Into Failure and The Field Guide to Understanding Human Error; Erik Hollnagel, Safety-I and Safety-II; Todd Conklin, Pre-Accident Investigation; Scott, Seeing Like a State; Deming, The New Economics, on variation.

    24. Safety as absence vs safety as presence. This is a corollary of entry 23, framed at the level of metrics and investment rather than incident analysis.

    • Pole A. Safety is the absence of events; the fewer accidents, incidents, and near-misses, the safer the system. Safety investment is insurance against accidents.
    • Pole B. Safety is the presence of defences, the ability to succeed under varying conditions. Safety investment is investment in productivity.

    Pole A is right in tractable systems with stable specifications: the lost-time injury rate on a mature manufacturing line, the field-failure count for a long-standing physical product, the audit-finding count on a stable regulated process. Pole B is right in intractable socio-technical systems where work-as-done routinely adjusts to conditions work-as-imagined did not anticipate: a software platform under continuous deployment, a clinical service operating with staffing variability, anything where the absence-of-events metric stops moving while everyone reports getting away with more than they used to.

    In decisions: Pole A leaders count injuries; Pole B leaders ask “how are we able to do this work well 999,999 times out of a million, and what do we need to preserve about that?”

    See also. The sources under entry 23, Dekker’s Safety Differently and Allspaw’s How Your Systems Keep Running, both teach this dichotomy at the metrics-and-investment level too.

    Read. Hollnagel, Safety-I and Safety-II.

    25. Simple stories vs multi-causal stories.

    • Pole A. Beginning-middle-end arcs with clear heroes, villains, and lessons.
    • Pole B. Several stories simultaneously about the same event; the discomfort of multiple frames as the data, not as a sign that the analysis is incomplete.

    Pole A is right when the audience needs to act and the action is genuinely unambiguous: the all-hands message after a successful product launch, the board narrative on a clean quarter, the customer communication after a single root-cause incident with a documented fix. Pole B is right whenever a confident single-cause story is being constructed under conditions the data does not support: most strategic narratives, most multi-quarter performance explanations, most post-incident reviews where “human error” was offered as the answer in the first 24 hours.

    In decisions: Pole A leaders narrate quarterly results as a story of decisions made; Pole B leaders narrate them as a story of conditions encountered, with several versions on offer.

    Watch. Garvey-Berger, Mindtraps — Simple Stories (5 min). Companion: Tyler Cowen, Be suspicious of (simple) stories (TEDxMidAtlantic, 16 min): names the narrative fallacy directly and argues for “the mess” (multi-causal reality) as the alternative to single narrative. “Every time you tell yourself a good-vs-evil story, you’re lowering your IQ by 10 points.”

    Read. Garvey-Berger, Unlocking Leadership Mindtraps; Dekker, The Field Guide to Understanding Human Error, on authentic stories over accurate stories.

    Self: how does this leader read their own identity, capacity, and developmental edge?

    Every other dichotomy is mediated by the leader’s relationship to themselves. The developmental literature drawn on here (Kegan, Lahey, Garvey-Berger, Joiner) has decent measurement reliability for trained scorers, modest construct validity, and contested predictive validity. The dichotomies below name observable behavioural patterns rather than relying on staging interpretations to do the diagnostic work.

    26. Socialised vs self-authoring vs self-transforming.

    • Pole A. Identity is given by the surround: role, profession, expectations.
    • Pole B. Identity is a self-chosen stance; the leader can hold their own values against pressure from valued others, and the role they hold is one expression of who they are, losable without the self being lost.
    • Pole C. Identity is held lightly; the leader values their own frame and watches for the data that would refute it.

    Pole A is the right response in some contexts: early-career apprenticeship, certain professional-formation contexts, communities of practice where the work depends on shared identity. Pole B is what most senior leadership roles structurally require. Pole C is rare and not necessary for most roles, but is the right fit in the most VUCA situations where holding any paradigm too long is itself the risk: what Meadows called transcending paradigms, the highest leverage point in her hierarchy.

    In decisions: Pole A leaders cannot disappoint valued authorities on behalf of their own judgment, and cannot imagine succession because the role is doing the identity-work; Pole B leaders can disappoint valued others, and treat succession as an explicit part of how they hold the role; Pole C leaders can disappoint themselves on behalf of evidence that contradicts their judgment. A three-pole entry; the gap between A and B is usually more salient than between B and C.

    Identity-given-by-surround is the structural failure mode AI exposes most cleanly. Pole A leaders cannot distinguish good from plausible: the LLM’s confident prose lands in the same register as the voices that shaped their expectations. They accept what the model tells them to do not because they’re naïve but because they have no felt sense of what fitting would mean; the model’s output is just another voice from the surround. Pole B leaders feel the dissonance when a confident output doesn’t fit the situation, and slow down. Pole C leaders treat every model output as a hypothesis to be tested against evidence the model couldn’t have seen. The leader who cannot disappoint a confident voice cannot govern an AI either.

    Watch. Kegan, The Further Reaches of Adult Development (The RSA, 20 min): Kegan himself walking socialised → self-authoring → self-transforming.

    Read. Kegan, In Over Our Heads; Joiner & Josephs, Leadership Agility; Garvey-Berger, Unlocking Leadership Mindtraps; Heifetz, The Practice of Adaptive Leadership.

    27. Subject to assumptions vs object of assumptions.

    • Pole A. The leader’s frame is what they look through; it is invisible to them.
    • Pole B. The leader can look at their own frame; they can hold it up to inspection.

    Pole A is the structural default; every leader is functionally subject to most of their assumptions most of the time, and a working organisation depends on the leader operating from a frame rather than constantly inspecting one. Pole B is right where the situation is already telling the leader their frame is not fitting (results recurring, conversations repeating, the same diagnostic appearing in different vocabulary each quarter). The diagnostic move is the noticing in those moments, not the constant inspection.

    In decisions: Pole A leaders are surprised by their own pattern when it surfaces; Pole B leaders can name the anxiety that drives the behaviours they keep noticing in themselves.

    Watch. Kegan, An Evening with Robert Kegan and Immunity to Change (Boston College OD Network, 14 min). Opens with the 14-frogs-on-a-log puzzle (gap between deciding and doing) and names the immunity-to-change framework. Walks through identifying big assumptions, then lands on “being able to look at the whole thing”: the subject-object move on one’s own frame.

    Read. Kegan, In Over Our Heads; Kegan & Lahey, Immunity to Change.

    28. Attached to outcome vs attached to inquiry.

    • Pole A. The decision must yield this result; if it does not, the decision was wrong.
    • Pole B. The decision was a test of a hypothesis; the outcome is data; the question is what to learn from it.

    Pole A is right when the decision was a genuine commitment to a specifiable outcome and the accountability frame requires defending the commitment. Pole B is right when the decision was a hypothesis dressed up as a commitment, or when defending the commitment is doing more work for the leader’s identity than for the outcome.

    In decisions: Pole A leaders defend the decision after it fails; Pole B leaders refine the model after it fails.

    Watch. Astro Teller, The unexpected benefit of celebrating failure (TED, 16 min). Kill-and-pivot stories from Alphabet’s X: vertical farming, cargo blimp, self-driving cars (the supervised model failed, the team switched to fully autonomous). “We bonused every single person on teams that ended their projects.” Closes on “enthusiastic skepticism is optimism’s perfect partner.”

    Read. Rother, Toyota Kata, on “problems are jewels”; Reinertsen, The Principles of Product Development Flow; Edmondson, Right Kind of Wrong, on intelligent failure.

    How to use this mirror

    The fifteen-minute version, named at the top, is enough on its own: look back at the six axes, notice where you sit on the left, and ask where those assumptions came from and whether they still fit. If the noticing surfaces something that wants more than a glance, the two-week version below is built for that. Four movements, four calendar slots, about two weeks end-to-end.

    Movement 1, the reading pass. About 1 hour, today. Read the essay through once and flag the three or four entries that strike you on first pass as most provocative for your current situation. Then sample the embedded videos and essays under the Watch/read lines for those entries; most are 5-15 minutes, a few are longer. Notice which of your initial flags shift, drop, or sharpen once you’ve watched the videos or read the excerpts for those entries. The settled list is what you take into Movement 2. The point of this step is to keep this mirror itself from doing too much of the work; the sources are doing the teaching, and your first read should reflect what you actually find when you let them.

    Movement 2, the dichotomy walk. 20 minutes alone, this week. Take your settled three or four entries into solo work. For each, ask three questions: which pole am I claiming?, which pole would my last three decisions in this territory actually show?, which pole does the situation I am facing actually require? The third is the Cynefin discipline: the situation determines the right pole, not the leader’s preference. The first two are the espoused/theory-in-use discipline (entry 11, the load-bearing wall). The interesting territory is wherever those three answers diverge. Write down what you find; you will need it for Movement 3.

    Movement 3, the witness round. Send by Friday; one-week response window. Send the same three or four entries to three or four people who have watched you make recent decisions in the territory. Ask them which pole they observed in your last three decisions. One sentence each is enough. Compare to your own answer from Movement 2. The gap, when it appears, is the diagnostic.

    Movement 4, the conversation. 45 minutes with a coach, the week after. Take the gap to a coach and work it: make visible the operating pattern that is already happening, and make the next decision a choice rather than a reflex. The achievable end state is one sentence you can say out loud: “On entry N, my espoused pole is X, my observed pole is Y, and the situation usually calls for Z.” If you do not yet have a coach who works at this depth, finding one is the work; this mirror is built for that conversation, and the conversation is what makes this mirror do anything other than sit on the page.

    A staff-runnable variant. For a leadership team rather than an individual: same four movements, no coach. Movements 1 and 2 stay solo. Movement 3 is the team being each other’s witnesses on a single shared entry (entry 1 is a strong first choice). Movement 4 becomes a 30-minute conversation about the gaps that surfaced: what each person’s espoused pole was, what their last three decisions in this territory actually showed, and what the situation the team is facing actually requires. Run on one entry per fortnight. The team’s situation, not the facilitator’s, determines what each conversation produces.

    What this mirror does, and what it doesn’t

    This mirror makes the operating paradigm observable. It does not, on its own, change it. The change-work is the conversation that follows. The mirror is the first step of that work, not a substitute for it.

    Three things you might do next.

    • If one entry hit hard: send it to one peer who has watched you make recent decisions in that territory, and ask them which pole they observed. One sentence is enough. That single exchange will tell you more than another read of the article will.
    • If you want the larger argument: read the companion essay, Come Prepared to Die: Your Paradigms Were Survivable. AI Makes Them Lethal. This mirror is the first step of the work that essay names. For a taste of what transcending paradigms entirely looks like, take a look at Just This.
    • If you want to talk: flick me a note on LinkedIn, or visit hi.chrisgagne.com. If you do not yet have a consultant and/or coach who works at this depth, finding one is the work.

    Some book links are Amazon affiliate links. If you buy through them I earn a small commission at no cost to you. Primary-source citations (papers, reports, articles) link to the original or to free archives.


    Originally published on LinkedIn, 18 May 2026.

    Some book links here are Amazon affiliate links; if you buy through them I may earn a small commission, at no cost to you.

  • Several Simple Hand Signals for Video-Based Collaboration

    Several Simple Hand Signals for Video-Based Collaboration

    Remote and hybrid work can take some getting used to. When you and your colleagues move from in-person to video-based collaboration, you miss out on some of the subtle body language that helps you know how to adjust your discussion flow.

    Coaching globally distributed teams, I found these hand signals genuinely useful, so I thought I’d share what we learned. We used variations of them for years.

    Before you start, make sure everyone can see everyone else at once. Most video platforms have a grid or gallery view that shows all participants on one screen.

    The “stack” to facilitate taking turns speaking

    The first set of hand signals is simply “the stack.” If someone else is speaking and you’d like to talk next, raise a finger. If someone already has a finger up and you’d like to speak after them, put two fingers up, and so on. I’ve seen stacks of up to five fingers.

    When you’re done speaking, take a quick glance at everyones’ video feeds and call on the next person in the stack.

    If you’re in the stack and still waiting when someone drops off the stack, lower one of your fingers so your place in line stays clear.

    Try not to lower your hand for long, because that signals to the rest of your team that you no longer wish to speak. It’s polite to both go to the end of the stack if you still want to speak and let others get back in where they were if they try to return there.

    The “C” to request a clarification with a question or comment

    A “C” hand signal means you’ve got a clarifying question or comment. Anyone showing a “C” cuts to the front of the line and gets to speak before others in the stack. Use your judgement and try not to abuse this privilege.

    If you’re speaking now when someone displays a C, call on them next. I rarely see more than one person throw a C at a time, but I’m sure you’ll find a way to work it out.

    The “delta” to request a change in topic

    Making a triangle with your two hands is called the delta. A delta, ∆, in math terms is a change. When you use the delta sign, you’re signaling that you’d like to see a change in topic or approach. If you’re speaking, try to finish soon and check in with the person displaying the delta.

    Wiggling your fingers or thumbs up to express enthusiasm or agreement

    If you are enthusiastic or agree with what someone is saying, you can put up your hands and wiggle your fingers with varying degrees of vigor. You could also show one or both thumbs up.

    “Temperature check” to request feedback on a proposal

    Sometimes you want to get an analog temperature check on how everyone’s feeling about something. To ask, just say something like “Let’s do a quick temperature check. This is ‘I’m hot on this.’ This is ‘I’m luke-warm on this.’ This is ‘I’m cold on this.” Then just give folks a few moments to respond accordingly.

    “Roman voting” to gain consensus or feedback

    You can also get a little more decisive with what Agile coaches call “Roman voting.” You can ask people to show you a thumbs up, a sideways thumb, or a thumbs down.

    A thumbs up means that someone agrees with the proposal, a sideways thumb means they don’t necessarily agree but will go along with it, and a thumbs down means they disagree.

    I suggest holding three working agreements around this:

    • If nobody is displaying thumbs down, you can move on. If you’ve got nothing but sideways thumbs, however, realize your proposal’s support is weak.
    • As the person seeking consensus or feedback, sincerely seek and consider the feedback of individuals displaying thumbs down.
    • If you show a thumbs down, be prepared to explain your objection and ideally what changes to the proposal could get you to a sideways or thumbs up.

    To use Roman voting:

    1. Make sure everyone knows your working agreement about what the hand signals mean and how you’ll use your feedback. For instance, will you proceed even if you get a thumbs down that you can’t resolve?
    2. Ask people to raise a closed fist when they’ve made a decision and they’re ready to vote. Having people put up their closed fist first and voting all at the same time helps you reduce the effects of peer pressure and group think.
    3. Vote on a quick count of three once everyone is ready.
    4. Make a decision and move on, or discuss and vote again if necessary.

    You can use these hand signals in person, too

    I find that many of these hand signals are useful even when you’re meeting in person.

    The “stack” and “C” hand signals help ensure that more people have a voice. Without them, people who are faster to respond⁠—often the highest paid people in the room⁠—often speak before others get a chance. By creating a stack, you help ensure everyone with something to contribute can be heard.

    The “delta” is a way of suggesting that the meeting might be getting off-topic or digging into something too deeply for the time or audience. Teams who use a lot of sticky notes can also display a pad of stickies like a football (“soccer”) referee showing a “yellow card.”

    Be mindful of your cultural context

    I can’t think of too many hand signals that are both universally familiar and inoffensive. So it is important to choose signs that are appropriate for your cultural contexts. This is a balance of familiarity against potential offense: the “thumbs up” or “OK” signals are innocuous and familiar for the teams I supported, but both are offensive in several cultures those teams didn’t include. The specific sign is less important than the shared understanding of the intended concept, so work as a team to find familiar and inoffensive signs for your cultural context that represent the same concept.

    In summary

    You can use hand signals to augment your communication so that your team can work more effectively together. If you like these, share this article with your colleagues so you can come to a common vocabulary quickly.

    What’s most important to your organization isn’t the adoption of these hand signals, but rather that you know you can add additional bandwidth to your communication using hand signals. You can always start with these and create new signals as part of your team’s Working Agreement or at your next retrospective.

  • Agile Lessons from the NUMMI Team Member Handbook

    Agile Lessons from the NUMMI Team Member Handbook

    [May 2026] The safety frame I’m reaching for here is what Edmondson formalises as psychological safety and what Dekker grounds in just-culture. Modern Agile’s “safety as prerequisite” has matured into a richer literature on near-miss reporting, blameless inquiry, and learning-organisation discipline.

    [August 2026] What the handbook shows is a company that changed the conditions rather than exhorting people to try harder inside the old ones. The line I quote here, “You just don’t see the line stop,” is the contrast Chapter 6 of Come Prepared to Die builds on, where I set NUMMI against Deming on tampering and Seddon on failure demand, and treat a Definition of Done as an andon cord.

    I recently came across Mark Graban’s “Highlights from the Original 1984 NUMMI Team Member Handbook” series. Digging through the archives at Ephlin’s UAW office papers were archived at the Walter P. Reuther Library at Wayne State University in Detroit, Mark found some absolutely extraordinary gems, including this one.

    Standing on the shoulders of giants, I reached out to the archivists at the library to see if I could get a copy of the full handbook. They cheerfully obliged, and rather quickly at that!

    Grab the PDF and peruse for yourself. The first several pages are the most interesting, but even as you explore the rest of it pay attention to how human and reasonable it is. Mark provides an excellent commentary on several key sections, so I’ll try to avoid highlighting the same thoughts. I hope you’ll share your own findings and commentary in the comments below.

    Here are some of the gems I’ve found:

    Our Objectives. We seek healthy, sustained growth by fostering high morale and motivation among all team members. You are a valuable resource. Your full involvement in the business is essential to our mutual success. Our objectives are: To help you develop to your full potential. To recognize the worth and dignity of all team members. To establish mutual trust and respect among all team members. To provide continuous employment for all team members through productivity improvements. To provide fair and equitable wages and benefits. To develop team performance as well as individual performance. To encourage excellent attendance. To encourage your participation in improving the work environment. To build the highest quality automobiles in the world.

    Notice that the first objective is “To help [employees] develop to [their] full potential.” In fact, these objectives start with the individual employee, progress to the company, and then ultimately end with the customer receiving the “highest quality automobiles in the world.” This is a notable inversion from the usual objectives, which usually prioritize stakeholders and customers, then the company, then⁠—if at all⁠—the individual employee.

    This is extraordinary in two ways. First, employees are given the expectation that they are going to have a greater autonomy and influence over how other aspects of the organization operate. I’ve heard the statistic that Toyota’s 300,000 global employees make a total of one million suggestions annually, 97% of which are implemented. Secondly, note that the employee handbook is characterized as helping the employee “do [their] job better,” a far cry from the usual purpose of this kind of handbook (protecting the company’s interest).

    (more…)
  • On Doing Versus Being Agile

    On Doing Versus Being Agile

    [May 2026] I now reach for Schein on culture, Westrum on generative-vs-pathological organisations, Edmondson on psychological safety, Senge on learning-organisation discipline, and Galbraith’s Star Model alongside Org Topologies for structure as the more rigorous current vocabulary for what this post calls “structure and culture.” The doing-vs-being distinction still holds; the toolkit has matured. I’ve also since added a fifth box at the cheap end of the diagram, to the left of tools: “terms,” changing the words you use. It’s the easiest change and the emptiest one, and I can’t claim much originality for it. Craig Larman named this years ago in the second of his Laws of Organisational Behaviour: any change initiative gets reduced to redefining or overloading the new terminology to mean basically the same as the status quo. New words, same operating model.

    [August 2026] The NUMMI listening questions I set out here, about what changed in the plant and what GM could not replicate elsewhere, are the ones I work through at length in Chapter 3 of Come Prepared to Die. Same plant, read the other way round: the chapter takes NUMMI as the inverse case, where GM copied the production system and left the structure alone. AI now hands you the tools-and-process win almost for free, which leaves the structure you never touched as where most of the remaining gain sits. I came back to that plant from a different angle in the Team Member Handbook post.

    Are you doing Agile, or have you become Agile?

    The difference seems pedantic at first…

    You are doing Agile when you’ve changed your tools and processes. This is relatively easy to do but doesn’t offer much in the way of benefits. You’ve become Agile when you’ve changed you structure and culture too. This is relatively hard to do, but offers significant benefits.

    Agile isn’t just a process. It’s a complete framework that brings together a shift in culture, structure, and processes. This framework is supported by tools such as Rally and other Agile Lifecycle Management (ALM) tools.

    (more…)
  • How Scrum Teams Can Seek Out and Destroy Organizational Impediments and Unplanned Work

    How Scrum Teams Can Seek Out and Destroy Organizational Impediments and Unplanned Work

    [May 2026] I’d now call this the early Planned/Unplanned Velocity instinct. The 2014 practice (track unexpected requests and impediments as a separate signal) has matured into SPC control charts on the two streams (Shewhart, Wheeler) plus a displacement rule that triggers intervention when unplanned work crowds planned work; same instinct, sharper measurement.

    [August 2026] The refusal at the heart of this post, that a team landing at 72% has told you something about its conditions rather than about itself, is what Chapter 14 of Come Prepared to Die works through. The chapter carries it into incident response, where hunting the operator who deviated leaves the conditions that produced the deviation untouched.

    A team should be able to complete 80–110% of their planned stories each and every sprint without heroics.

    Why is this important?

    • The work output from this team is predictable. When the team commits to a set of stories at the beginning of the sprint, other teams can rely on them to deliver.
    • Predictable output breeds confidence. If a team consistently delivers on their commitments, they are considerably more credible when they need to push back on unrealistic expectations.
    • The team will likely feel motivated because they’ve demonstrated a degree of mastery in their craft.
    • The team has a stable base. Because they are delivering on their expectations, they can focus their energy on continuous improvement and optimization.

    If a team regularly completes less than 80% of their sprint objectives, why does this happen?

    • The work tasks do not meet INVEST criteria and thus cannot be estimated accurately.
    • New work is given to the team mid-sprint.
    • The team faces new and old impediments that interfere⁠—usually unpredictably⁠—with their ability to deliver the work.

    It’s not always easy to glean these issues from tools like Rally. Thankfully, there’s a simple solution that can help both individual teams and the program discover the severity and nature of the issues that prevent a team from achieving fast, flexible flow.

    The Status Quo

    Let’s take the example of a 2-person team working a 2-week sprint. (This isn’t an ideal team setup, but it keeps the numbers easier to work with.) Here’s their sprint backlog a few hours after planning:

    Rally sprint backlog a few hours after planning: six stories totalling 39 points and 93 task hours, with all 93 hours still to do and work started on the first story.

    They’ve taken on 39 story points, which is one fewer than the 40 accepted story points they completed last sprint. That’s perfectly reasonable.

    They’ve added tasks to each of these stories and began work on the first one.

    I like to assume 6 hours/day of productivity per developer to account for planning meetings, standups, retrospectives, breaks, lunch, etc. Two developers * 2 weeks * 6 hours/day = 120 hours. Assuming a 25% “safety factor” (some teams use 30%, others use 20%, the truth is that we’re splitting hairs at this point), the team should be able to complete about 96 hours of planned tasks this sprint. They’ve identified 93, so this “smells” okay.

    (Note: the team should use story points to gauge how much work to accept into the sprint backlog. Use the task hours as a sanity check.)

    Let’s fast forward a week and a half. It’s Tuesday afternoon, and there are about 2-1/2 days left in the sprint:

    Rally sprint backlog mid-sprint: two stories accepted, two partly done, two not started, with 36 of 93 task hours still to do.

    The product owner accepted 18 points or 46% of the sprint. There’s 36 hours of work left and about 30 hours of time left, so we’re a little behind. Most novice Scrum teams would not register concern at this point.

    What happened during the sprint? The development team raised impediments during the standup and worked through them. One developer was out sick for a day. The team had to go to an unexpected all-hands meeting, and they had to do a couple of side projects.

    The problem is, there’s no measurement or record of these unexpected requests and impediments. The unexpected requests should not have been added mid-sprint unless they were (rare) “on-fire” issues. The team (and anyone who attended the standups) would know what the issues were, but this knowledge is limited or non-existing at the program level or higher.

    This is a missed learning opportunity as we do not have the transparency we need to inspect and adapt.

    Introducing the Unexpected Requests and Impediments Story

    Let’s rewind and add a new story to the sprint backlog:

    The same Rally sprint backlog with a seventh item at the bottom, Sprint 5 Unexpected Requests and Impediments, carrying no points and no hours yet.

    Note the addition of “Sprint 5 Unexpected Requests and Impediments” at the bottom. This doesn’t get story points and it’s at the bottom because it’s the last thing you want your team to be working on.

    Each and every unexpected request or impediment gets added to this story as a task (with hours) during the sprint, like so:

    The Unexpected Requests and Impediments story expanded into 46 hours of tasks: a marketing deck (12 hours), fixing a broken staging environment (18), a conversion report (2), a production rollback (6), an all-hands meeting (2) and a sick day (6).

    Suddenly these side projects and impediments become real.

    Let’s take a look at that mid-sprint view of the backlog again.

    Suddenly, the problem becomes even more clear. We should be able to complete about 120 hours of work in a 2-person, 2-week sprint, but our task estimate is now up to 139. Unless this team works overtime (which they should not do as it is demotivating and ultimately productivity-killing), we’re not going to complete all of our stories in time for the demo.

    So here’s where this team ended up right before their demo:

    Rally backlog just before the demo: four stories accepted (28 of 39 points), one story partly done and one not started, plus the completed Unexpected Requests and Impediments story.

    They completed 28 story points or 72%. A “pointy-haired boss” might look at this team and say “you failed.”

    That statement in and of itself is a failure. It jumps to the conclusion that the team experienced a performance failure. In reality (with all credit due to Mary Poppendieck), the more likely failure is that of the original hypothesis: that the team could have completed the work in the first place. There’s a major missed opportunity: the opportunity to learn something from our system and adapt.

    We budgeted 25% of our time for these sorts of issues, or 24 hours. We wound up with 46 hours of unexpected requests and impediments, 22 hours “over budget.” We had 15 hours of work remaining on the two stories we didn’t complete, so it’d be pretty reasonable to say that had it not been for those extra 22 hours of work, we would have completed this sprint (and perhaps even added a 1- or 2-point story).

    Ideally, you’re keeping track of your velocity from sprint to sprint. Add another metric: keep track of the percentage of task hours each sprint that came from unexpected requests and impediments.

    So what?

    Now we have transparency. Transparency allows inspection, inspection allows adaptation. Here are some ways to use this information to inspect and adapt:

    • The team can review the impediments and suggest user stories to the product manager (often spikes or technical user stories) to help address some of the underlying technical impediments.
    • The team can use this as feedback that they may need to slow down and refactor to address technical debt. They may not want to create new user stories, but they should at least spend a little extra time on their new user stories to clean up old debt and avoid creating new debt.
    • The Product Owner can show stakeholders the cost of unexpected requests and impediments on their predictability. This gives them the evidence they need to hold off on new requests until the next sprint and spend more time building quality into the work that they are doing.
    • Engineering managers and program managers can review impediments across teams and look for impediment patterns to solve. For instance, an engineering manager may be able to quantify that the company spends 10-15% of their development time fixing broken environments. This data could justify an much-needed investment: “We lose $1M a year in productivity fixing broken environments [based on salaries multiplied by time lost]. A new VM system would reduce this cost by 50% and cost us $100K.”

    There you have it. Regardless of the software you use (if any), you can add the Unexpected Requests and Impediments story to your sprint backlog. You can use the data it generates to gain knowledge and take corrective action.

    What are your thoughts? Have you used something like this in your own team? Please share your thoughts!

  • What a 106-year-old psychological law tells us about stress in the office

    What a 106-year-old psychological law tells us about stress in the office

    [May 2026] I’d frame this more carefully now. Social-evaluative threat and Amy Edmondson’s psychological safety are close cousins, not the same thing: psychological safety is about whether people believe it’s safe to take interpersonal risks at work. And I’d treat Yerkes-Dodson as a useful heuristic rather than a hard law. The point I still stand by: lower the threat in the room, don’t push harder.

    Work harder!

    We’ve all been admonished to work harder at some point in our lives, whether it was from a well-meaning parent, a sports coach, or a manager facing a deadline.

    What many Agilists have come to empirically observe is that the more we can get people to feel happy and have a good work/life balance, their total productivity goes up. We’ve come to learn that “busyness” is not productivity. I have heard managers brag of how dedicated their teams are because they’re working 100-hour weeks on their latest and greatest innovation. Yet they seem to miss the fact that had their teams spent 35–40 hours a week on their latest and greatest innovation, it would be less late and even greater.

    So, why do some managers insist upon added stress and arousal? Clearly there must have been a time or place where “cracking the whip” made sense.

    Hint: It’s not in highly creative fields like software development.

    It turns out that there are some times when it makes sense. According to the Yerkes-Dodson law, an “empirical relationship between [physiological and mental] arousal and performance,” performance increases when arousal does but only up to a point. In some cases, further arousal lowers performance.

    For simple tasks, more arousal equals more performance, at least up to a point at which it relatively plateaus. For difficult tasks, more arousal equals more performance, until it reaches a peak and begins to plummet at the rate that it rose. This is because stress negatively affects cognitive processes such as attention, memory, and problem solving, all critical for the modern knowledge worker.

    Put another way…

    One of the things that I really like about Agile is that it’s all about staying empirical… Transparency benefits inspection, inspection benefits adaptation. And over the years, we’ve come to learn in the business context what many have learned in the psychology and biology contexts.

    For instance, a 2007 review of the effects of stress hormones like glucocorticoids found that people’s performance on memory tests and the levels of stress hormones in their blood produced very similar responses to what Yerkes and Dodson found nearly a century earlier. One example: long-term memory formation followed the same inverted-U — best with a modest level of glucocorticoids in the bloodstream, and worse at either extreme, whether the adrenal glands were removed (no glucocorticoids at all) or extra glucocorticoids were injected.

    Interestingly, this same review found that in order for something to induce a stress response, it has to be perceived as: novel, unpredictable, uncontrollable, and/or possibly leading to social rejection. Naturally, any knowledge worker’s office is likely to be plagued by novelty, unpredictability, and a lack of control (at least from external circumstances like competition).

    One of the things Agile teaches is how to manage these constants well. Rather than stressing out and feeling like we need to “replan” because “things didn’t go the way we planned,” Agile assumes that things won’t go as planned. Uncertainty is embraced. Servant leaders who understand the nature of software development reality deeply understand these things, and so don’t unnecessarily create a culture of fear that produces the sense of a “social evaluative threat” when “the plan isn’t met.” The plan hypothesis was wrong in the first place.

    Thus, workers in strong Agile cultures are more productive not only because they aren’t working 80-hour weeks, but also because the whole culture (especially the leadership) is mature enough not to freak out at every single change. These workers experience less stress, therefore they’re producing less stress hormones, and therefore their brain isn’t acting like it’s about to be eaten by a tiger. Keep in mind the tiny amount of time that has elapsed between the constant fear of violent death and the modern 72°F office environment, at least from an evolutionary perspective.

    This is your brain on stress.

    Truly Agile companies put people in environments where they feel autonomy, mastery, and purpose, providing strong intrinsic motivation, which doesn’t create the same kind of stress. Fear and command-and-control drive that out, and the people with the most options are the first to leave. Performance is shaped as much by the system around a team as by any individual in it: a culture of fear is a system problem, not a talent problem.

    It’s easy to feel like a hero or a martyr when you’re working those eighty-hour weeks “for a cause.” Managers can tell their employees that they’re not “strong enough” and need to “man up” and put in the hours. But try as we might to ignore them, rarely can we escape the simple facts of our physiology and biology.

    And if your own arousal is running past its peak right now: I built a two-minute breathing pacer for exactly that. Set a timer and try it.

    Source note: the original 2014 version of this post leaned on Wikipedia’s overview of the Yerkes-Dodson law for the background.

    Parody poster. A hand holds an egg: This is your brain. An empty pan: this is stress. An egg frying: this is your brain on stress. Any questions? From the Yerkes-Dodson Partnership For A Low-Stress Workplace, by Chris.
  • Mary Poppendieck’s “The Tyranny of ‘The Plan'”

    Mary Poppendieck’s “The Tyranny of ‘The Plan’”

    [August 2026] Mary names a paradigm here that I’ve since written a book around, and she got there well before I did. Her claim is that a schedule rolled up from a work breakdown is a hypothesis dressed as a commitment. Chapter 7 of Come Prepared to Die works that axis and leans on this talk to do it, particularly her reading of Sapolsky on Polaris, where PERT turns out to have been a façade built to keep Congress paying. Her Empire State material runs the other way, toward Chapter 8. They had a fixed date, 1 May 1931, because that was when New York leases turned over, and on the day the contract was signed there was no design. The stone went up in 8 months. The job came in 18% under budget. The Empire State build is also the cleanest case I know for scheduling by flow rather than utilisation; I take that up in Utilisation vs Flow. If your plan keeps going nervous on you, the plan is likely the problem, not your team. Working out which one you have is most of the diagnostic I run. If you want this school of thought as a primary document, the 1984 NUMMI team member handbook shows the same thinking written for the factory floor.

    A couple of years ago, my former manager David Denton forwarded me a recorded presentation by Mary Poppendieck, a leading Agile software development expert and co-author of the popular book “Leading Lean Software Development: Results Are not the Point.“

    Watching the video on the InfoQ website is a bit kludgey and Mary has lots of wonderful details that are worth hearing. So, with Mary’s permission, I’ve had the video transcribed and included her slides in context. I hope that this will make this very useful knowledge easier to find and learn from. Mary, thanks again.

    I’ve eschewed block-quote formatting as it made this transcript a little harder to read. I’ve also edited slightly for readability. Otherwise, everything beyond this point is Mary’s work.

    (more…)
  • The Customer is the Marshmallow

    The Customer is the Marshmallow

    [May 2026] This argument still holds. Both “ship quickly and often” and “defer commitment” remain true today; cost-of-delay weighting (Reinertsen, Fox & Gregory) and real-options framing are the sharper economic vocabulary that grounds them.

    [August 2026] “They build slowly and test often” is the practitioner’s version of an argument I make more formally in Chapter 7 of Come Prepared to Die: a plan held as a commitment kills the learning, and a plan held as a hypothesis invites it. The marshmallow is what a premature commitment feels like when it lands.

    Many of you will be familiar with Peter Skillman’s Marshmallow Challenge, an exercise frequently given to teams and business school students. Teams of four are given 20 pieces of spaghetti, 1 yard of tape, one yard of twine, and a marshmallow. They are then given 18 minutes to build a free-standing structure that places the marshmallow as high off of the table as possible. The team with the highest marshmallow wins.

    If you haven’t seen it already, Tom Wujec’s TED talk is a good place to learn about the challenge. And if you haven’t introduced your team(s) to it, take 45 minutes out of one of your days to administer the challenge and see what revelations you get.

    (more…)
  • A Retrospective on Managing a Client Services Team

    A Retrospective on Managing a Client Services Team

    [May 2026] The instincts in this essay still hold; the vocabulary has caught up. I now name the headcount-process-tools progression as constraint-led capacity work (Goldratt), the support team as a feedback loop in the organisation’s learning system rather than a conduit, inter-departmental SLAs as the kind of cross-functional commitment Deming’s “94% systemic” rule demands, and the recipes-for-failure list as a systemic-failure-mode catalogue rather than a list of management mistakes.

    About a year ago, I left a job as a Director of Client Services and began interviewing at other firms. I had a great interview with a firm that I’ll call Company Y. After the interview, I wrote up a little essay describing my thoughts on the scalability, people, and operation of a client/customer service team. I hope you’ll find it useful and share your comments and feedback.

    Scalability

    A support department’s capacity to support work volume is based upon three factors: headcount, process, and supporting technology/tools.In its infancy, the support department gains volume by adding headcount. A department can reliably scale from one to two or three agents. Beyond three or four agents, however, inefficiencies begin to mount and dwarf the marginal gains from adding additional employees. For instance, two or three employees communicate easily about the state of the product and client base. Four or more employees can’t communicate nearly as well.

    At this point, adding clearly defined standard operating procedures usually provide more productivity than adding additional employees. We can start this process by identifying and building upon the informal processes that the team and employees found useful. For instance, our team at Company X found notes on client accounts to be extremely helpful. As a result, we added a “you must add a note to a client’s account every time you touch it” to our list of standard processes.

    At Company X, we found the most and least efficient parts of our workflow and built scripts and flows that helped employees cover their bases. In addition, we actively involved the team in defining and documenting the processes, giving them a strong sense of participation and ownership. This gave us a chance to reiterate that the processes were being developed to help the team thrive. We also had a chance to let our talented employees capitalize upon their strengths and take a break from the usual routine.

    One of the most frustrating parts of developing processes is that the tools to support those best practices often come much later, if at all. Much of the work that the account managers did on a daily basis at Company X was significantly more manual than ideal. This is a source of risk, because if a company adds too many processes and “rubber-stamp” operations without giving employees effective tools, they begin to feel burnt-out and limited. They could feel like mere cogs in a machine because much of their work was simple and repetitive when it could have been automated.

    Here’s an example at Company X. First, we established that retaining existing clients was substantially more cost-effective than trying to obtain new clients. So, we brainstormed on ways of retaining our client base. A member of our technical team suggested that we regularly audit each client account so that we could see how well they were using the software and make proactive suggestions.

    We put this process into place. A successful audit could take 20-30 minutes: the account manager needed to log into each account and manually review every aspect of the account. Were the client’s users logging in on a regular basis? Create a custom report and find out. Are they using these reports effectively? Look at the page view reports.

    Needless to say, this was a time-consuming process and we had limited bandwidth to get the job done. However, it also served an important function; we were able to suffer through the high cost of the process and ultimately determine that it was worth using. We also better understood how our customers used our software and learned of improvements we could make to our documentation and training processes.

    Based on the work we did manually evaluating accounts, we were able to develop a utilization metrics system that helped us automatically quantify a client’s use and success with the software. Since the tool was automated, we could quantifiably track customer “satisfaction” over the course of time and even trigger early alerts about major changes in client engagement. We could even sort clients in our administrative interface by level of engagement, making it much easier to triage the clients who were in good shape, hurting but salvageable, or lost. As a team, we moved from need to process to sustaining technology.

    Processes are never stagnant – as the landscape changes and additional staff join the team, we need to continually improve upon our modes of operation. However, we will come to a point where the baseline components of our process are stable enough for us to begin developing project requirements and ultimately tools.

    There’s a balance of risks – on the one hand, you risk frustrating the team with time-consuming and repetitive processes that could be automated. On the other, you risk spending a good deal of time and money developing or purchasing the right solution to the wrong problem.

    These days, I’m more inclined to use open-source or commercial products rather than trying to develop process-supporting tools. My litmus test is simple – do not reinvent the wheel. We would not create our own email server software, but we might integrate Exchange with our application.

    There are two components to most process-related technology: general fundamentals (such as allowing a client to interact with a ticket-management system via email and a web interface) and specific adjustments or integrations with existing systems. I’ve found that many of the fundamentals are a) solved dozens of times by other people, and b) contain lots of “devilish details” that make developing your own version more difficult. Most of the time involved in getting two systems to communicate well is in developing an API for each system. Many off-the-shelf solutions include APIs for common tasks, so we need only attach our current software for the existing API.

    At Company X, I found that we tried to develop our own tools when we should have purchased off-the-shelf solutions. We often had very limited tools that were tightly integrated with our system. The tools were fairly efficient (we didn’t have to enter data in more than one place very often) but they weren’t particularly helpful, either.

    For Company Y, I’d likely recommend an off-the-shelf CRM tool such as RightNow. This gives us early wins (we can start tracking clients, tickets, and custom development more effectively), and we can add tighter integration with our existing back-end systems as we have time.

    People

    In our discussion together, I identified the best technical support employees as having the following characteristics:

    • Early-career (relatively junior employees)
    • Naturally gifted problem solvers who enjoy “digging into problems”
    • “In touch” with the client base and their overall satisfaction levels, able to spot early problem trends

    I also described ideal account managers as being:

    • Naturally empathetic to their customers’ needs
    • Effective, college-educated communicators
    • Able to defuse upset customers

    The wrong environment can make these employees feel “crazy,” overworked, and under-valued. Here’s a recipe for failure:

    • Under-staff the department.
    • Develop processes and procedures without employee input and fail to provide adequate supporting tools.
    • Fail to provide adequate problem-resolution tools and resources.
    • Fail to effectively respond to early-warning indicators described by the support team.
    • Create an “us vs. them” relationship between the customer-care team and the rest of the company.

    Conversely, a recipe for success:

    • Staff the department appropriately given the workload and tools available. If possible, anticipate staffing needs 1-2 months in advance so that new employees can get up to speed; it’s difficult for new employees if the best trainers (their coworkers) are buried under a mountain of work. Thankfully, a team can tolerate understaffing as additional employees are hired and processes and tools are developed, but the shortage cannot be chronic.
    • Use collaborative process mapping techniques to document and understand how employees use tools and go about their work. Follow-up by leading the team in converting the process map into a design map that addresses inefficiencies and waste in the current process, then follow up by actually implementing new processes and tools.
    • Provide adequate tools for diagnosing and resolving problems. Ensure that other departments have a faster SLA to the support team than the support team has to the client.
    • Evangelize for the customer-care team and investigate their early warnings seriously. Because they have the most day-to-day interaction with the customer base, they know better than anyone how customers feel about the product and its performance. Remember that many account managers have, perhaps to a fault, a very strong sense of empathy for customers and will be the best source of information about how clients are feeling.
    • Help foster relationships between the customer-care team and incident engineers, developers, the sales team, and other members of the company. In addition to providing valuable insight, the customer-care team gains support and appreciation for their work.

    Organization

    Organizational issues are the most difficult to solve because they require a commitment across all functional groups.

    A customer-care team is ultimately a conduit between a customer’s experience of a product and the rest of the organization. A customer-care agent cannot succeed unless they can provide the customer with a strong resolution to their problem in a timely fashion. However, that resolution is often out of the grasp of the individual representative.

    It is therefore critical that the customer-care team can count on faster service level from escalating departments as they promise to their own customers. For instance, if customer service is expected to provide a satisfactory response within 24 hours but the development team consistently takes 48-72 hours to respond, three negative things will happen: a) the customer is let down, b) the representative takes the heat from the customer and feels equally let-down and overwhelmed, and c) bad blood often develops between the “martyr” customer-care team and the rest of the company.

    A strong set of processes is important. For instance, as development requests often come through the customer-care team, we must create a set of processes and controls that ensure accurate communication about the customer’s needs and expectations.

    A strong set of tools is also important. For instance, a customer-care representative must be able to see the current status of a trouble ticket so that they can proactively keep their customer informed and up to date. It’s obviously stressful for a customer-care representative to have to hound escalation engineers for regular updates. Any ticketing system developed or acquired should then include other departments as agents so that each issue is tracked from end to end.

  • I hate priorities

    I hate priorities

    [May 2026] I still think rigid priority-number columns mislead, but I no longer believe the fix is sitting down with stakeholders to sort the list by hand. Today I’d weight by cost of delay (Reinertsen’s WSJF, Fox and Gregory’s economic framing) and treat ordering as a live conversation grounded in numbers, not as a one-time stack-rank artefact. The instinct toward relative priority was right. The toolkit was thin.

    [August 2026] Cost of delay is the variable Chapter 4 of Come Prepared to Die names, and this 2008 post was reaching for it without the word. What I argue here is only that relative order beats absolute priority. The chapter adds the economics that argument was missing: in high-variation work, keeping everyone busy makes the system slower, and queues are what you are managing whether you know it or not. The Customer is the Marshmallow makes the companion argument: defer the commitment and test before you build on top of it.

    More specifically, I hate numbers or letter representations of priorities when it comes to product backlogs.

    It’s a common strategy, even in Scrum. (Henrik Kniberg’s wonderful scrum book talks about a product backlog where higher priority items get higher priority numbers, preventing the “if this is critical and priority 0, what is ultra-critical? priority -1” issue.)

    So why the hate? Simple – they do a lousy job of actually priortizing tasks. How many times have you encountered a product backlog where there were several items that were all of critical importance? How is this truly helpful?

    Think of it in this way – what if half the items in your email inbox were of CRITICAL priority? At this point, what value does this tag add? At the end of the day, you’ll have to choose ONE thing to do next. What will it be?

    I therefore argue that it’s exactly this hard decision that needs to be made earlier in the process, with the stakeholders who will wonder why this critical priority issue took precedence over that critical priority issue.

    The real issue is that priority values attempt to apply a rigid metric of ABSOLUTE priority when the only thing that matters in the real world is RELATIVE priority – what do we do next? Even if you have the ability to complete work in parallel (e.g., more than one developer), you still need to figure out what those n people will do next.

    Therefore, I propose that we kill the concept of priority values in the agile workplace.

    Take your product backlog, remove the priority column, and sit down with the stakeholders. Don’t walk out of the meeting room until every item is sorted in order of relative priority.

    The rest is easy: in your next sprint planning meeting, figure out how many story points you have available and work down from the top of the list. There are only two exceptions:

    • When the developers believe that two pieces of work are similar enough to realize greater efficiencies if completed together. If this happens often, you need greater developer involvement in the priority setting meeting.
    • When the remaining story points don’t support the next priority item. For instance, suppose there are 3 remaining story points but the next item in the product backlog requires 5. It’s OK to scan down a little and take the next item at or below three points.

    What do you think? What has worked well for you?