# Agile Leadership (Scott Logic) > [!info] Machine-mediated deep-read — not the author's words except inside quote blocks. > Ported from an existing Readwise deep-read for doc `01kzp1fgrawrv8hz3wjxsp9qxj`. > [!question] Lingering Questions > - Does Mission Command's "even contravene direct orders" latitude have a real software analog, or does agile delegation stop well short of sanctioning deviation from an explicit leadership decision? > - What happens when the delegated team lacks the skill or judgment Mission Command assumes of junior officers — the essay never names a competence floor. > - Is the friction the essay attributes to poor intent-communication actually distinguishable from friction caused by genuinely conflicting priorities between stakeholders and teams? > [!tip] Article Ideas > - Apply the "two levels up, two levels down" intent-communication pattern to open-source maintainer/contributor delegation — a natural analog since OSS has no formal command authority at all. > [!link] Cross Reference > - [[3. Resources/MOCs/Product & Startup Instincts MOC]] — delegation/trust framing applies directly to team and community leadership decisions > - [[3. Resources/Permanent Notes/Managers Should Code Off the Critical Path]] — adjacent engineering-leadership territory, different specific claim > [!quote] Vocabulary > - *Mission Command* — British Army post-WWII doctrine: commanders set intent and boundaries, junior leaders fill in execution and may even deviate from orders to serve the mission > - *intent* — the "why" behind an order, propagated independently of the specific task, so subordinates can improvise correctly when conditions change ## Metadata - Source: [[3. Resources/Readwise/Articles/Agile Leadership]] ## Author's thesis Dave argues leadership and agility aren't separate concerns — agility is a mindset that fails without leaders willing to empower teams — and uses the British Army's Mission Command doctrine (intent-and-boundaries delegation, forged by counter-insurgency's need for fast decentralized decisions) as the working model for what agile software leadership should look like. ## Key arguments (≤3) 1. **The Mission Command analogy is structurally sound, not superficial** — the mapped elements (rapid unpredictable change, need for local decision authority) are genuinely shared conditions between post-WWII counter-insurgency and agile software delivery, not a loose metaphor. 2. **Failure is named on both ends of the trust chain**: intent not reaching senior stakeholders causes control-tightening; intent not reaching teams causes escalation-dependency. Either broken link erodes the agility the model is meant to produce. 3. **The essay generalizes from one book and personal reflection to a universal leadership/agility claim** — a mild hasty generalization, though softened by first-person "I believe" framing throughout. ## Claim atoms ### Mission Command empowers leaders and generates agility > [!quote] ID:rw_missioncommand > this is an approach which empowers subordinate commanders and promotes initiative as well as freedom and speed of action... it empowers leaders at every level and is intended to generate agility and tempo **Context & use**: Quoting Lt Col. Langley Sharp's *The Habit of Excellence* — the essay's core definitional atom that everything else elaborates. **Tags**: #xref #aphorisms <!-- atomicity: 1 idea ✓ --> ### Agile development exists to enable decentralized decisions > [!quote] ID:rw_agiledecentralized > The requirement to facilitate quick decision-making in order to respond quickly and effectively to ever-evolving, and often ill-defined, situations has driven what we know today as agile development. **Context & use**: The direct bridge sentence linking military doctrine to software — reframes agile's origin as decision-latency reduction rather than process ceremony. **Tags**: #xref <!-- atomicity: 1 idea ✓ --> ### Leadership is agility's foundation, not a parallel track > [!quote] ID:rw_leadershipfoundation > If agility is the goal, then leadership is not merely a supporting factor; it is the foundation that makes it possible. **Context & use**: Closing thesis statement in its most compressed form. **Tags**: #xref #articleseed <!-- atomicity: 1 idea ✓ --> ## Permanent candidates - **Delegated authority requires two-way intent communication** — strongest candidate; the essay names the specific failure modes on each side, giving the claim testable structure. See new Permanent note below. ## Processing checklist - [x] Connect into the relevant MOC — [[3. Resources/MOCs/Product & Startup Instincts MOC]] - [ ] Cross-link this essay's trust framework with psychological-safety research (Amy Edmondson) — the essay gestures at it without naming it ## Links - [[3. Resources/MOCs/Product & Startup Instincts MOC]] — engineering-leadership and delegation practice