This episode discusses the final section of the 1969 software engineering techniques conference report…eventually, after discussing how statistics does or doesn't work. I also reflect on both…

A brief introduction to probabilistic forecasting, and how accurate forecasts help us reckon with reality.

> The best part of having a doctorate is any time someone asks me to do something I don’t want to do, I write “absolutely not” on a post it and say sorry can’t I have a doctor’s note > > Dr. Amy * * * ### Why Estimates Fail (And Why You Still Need Them) * 🌡️ **#NoEstimates fixed the wrong thing** : The movement was reacting to a real pathology — estimates being weaponized as performance targets — but the fix is like smashing a broken thermometer and declaring temperature doesn't exist. The thermometer was the problem, not the concept of heat. * 🤝 **Estimates aren't for the team — they're for everyone around it** : External commitments, inter-team dependencies, and ROI trade-offs all require _some_ forecast. Refusing to estimate doesn't solve coordination problems; it just opts out of the game and leaves downstream humans to guess. * 🧩 **Task estimation lives in Cynefin's Complex domain, not Complicated** : Joseph Pelrine's research with 300+ agile practitioners consistently landed estimation in Complex — meaning cause and effect are only knowable in retrospect. Even great teams produce only mediocre estimates, because the ceiling on accuracy is a property of the domain, not team maturity. * 📉 **The Cone of Uncertainty is tragically ironic** : Estimates become accurate right when you no longer need them. Organizations make their firmest commitments at the concept stage — exactly when uncertainty is widest (up to 16x) — and the cone only narrows through _learning_ (scope decisions, spikes, actual code), not through more meetings. * 🔢 **Fibonacci's non-linearity is doing epistemic work** : A 13-point story isn't saying “this is exactly 13” — it's saying “the uncertainty band here is wider than the estimate itself.” The gaps mirror how complexity actually scales, and anything over 8 is usually a story hiding complexity that needs splitting. * 💬 **The number is a side effect — alignment is the point** : When one person says 3 and another says 13, the disagreement _is_ the value. That's where hidden dependencies and technical constraints surface. Cancelling estimation meetings because they're run badly is the wrong fix. * ⚖️ **Separate three things most orgs conflate** : An **estimate** is a probabilistic forecast with assumptions attached; a **plan** is a commitment to a process (“we'll work two weeks, then re-forecast”); a **commitment** is a promise with consequences, made rarely and only when the cone has narrowed. When pushed to commit, commit to priorities, not timelines. * 🛠️ **Practical moves that compound** : estimate late not early, give ranges not points, make assumptions visible, track accuracy to calibrate (never to punish — that just teaches padding), and never let someone outside the work impose a timeline on those executing it. * 🎯 **The uncomfortable truth for both camps** : Estimates are communication, not calculation. Their job is to enable decisions under uncertainty, not to predict the future. The real choice isn't “bad estimates vs. no estimates” — it's between the unconscious low-quality estimates your org will make anyway, and explicit, humble, range-based ones that give people something real to work with. ### The green dot trap * 🟢 **The Green Dot Trap** — Leaders fall into the pattern of responding immediately to every Slack message because it feels productive and keeps them "visibly available," but this creates more problems than it solves * ⚡ **Urgency Culture Creation** — When you respond to everything immediately, you signal that everything is urgent, causing your entire team to live in their notifications and abandon thoughtful responses * 🤔 **The Five Message Layers** — Every Slack message operates at one of five levels: thinking out loud, sharing information, proposing a frame, stating a position, or making a decision — but they all look identical in text * 📝 **Writing is Thinking** — Slack's text-based format is designed to give you space between reading and responding, but most leaders throw away this advantage by treating it like a walkie-talkie * 🔇 **Signal vs Noise Problem** — After sending multiple quick, unclear messages, leaders become "unreadable" and when real crises hit, teams can't distinguish genuine decisions from reflexive responses * ⏰ **The 30-Minute Rule** — Build in deliberate response latency — unless something is actively on fire, wait at least 30 minutes to respond thoughtfully rather than reactively * 🏷️ **Label Your Layer** — Tag your messages with prefixes like "Thinking out loud:" or "Decision:" to help your team understand what kind of response you're giving and what's expected from them * 👥 **Modeling Behavior** — Your team watches how you use Slack more closely than you think — if you're always responding immediately, they'll mirror that frantic energy throughout the organization ### Willingness to look stupid is a genuine moat in creative work * 🧠 **Nobel Prize curse** — Success creates paralysis: once you win recognition, the pressure to maintain that standard often stops great work from happening, as noted in Richard Hamming's "You and Your Research" * 👶 **Youth advantage isn't intelligence** — Young people excel at innovation not because they're smarter, but because nobody expects much from them, so they're free to explore "weird, silly, and seemingly-bad-but-actually-good ideas" * 🎂 **Aadil's Law** — The willingness to tolerate stupidity is directly proportional to the quality of ideas you'll eventually produce; breakthrough creativity requires cycling through bad ideas first * 🪼 **Evolution's stupidity strategy** — Jellyfish survived 500 million years through evolution's willingness to produce countless failed organisms; breakthrough innovation requires the same tolerance for "failure" * 😨 **Two failure modes** — Oversharing leads to being tuned out, but undersharing (fear of looking stupid) leads to bland, safe ideas that never risk or achieve greatness * 🎯 **Reframe the goal** — Instead of trying to share something good, just try to share something at all — shift from selection-focused to production-focused creativity * 🔄 **The courage regression** — The author's past self was "worse at almost everything" but had more courage to publish imperfect work, leading to occasional breakthroughs through sheer volume ### The Courage to Confront: How Real Leaders Balance Candor and Care * 🐘 **Meeting room elephants are culture killers** — The real rot in organizations comes from quiet avoidance, not dramatic confrontations. When leaders stay silent about obvious problems, it breeds resentment and erodes trust over time. * 🎭 **False kindness is actually cruel** — Avoiding difficult conversations to "protect feelings" just postpones pain and makes it worse. Real kindness means helping people grow, not keeping them comfortable in dysfunction. * ⚖️ **Balance candor with care** — "Candor without care is cruel. Care without candor is cowardice." The best leaders deliver honest feedback with respect and dignity, not as a weapon or hidden behind sugar-coating. * 🔍 **Truth-telling deepens relationships** — Contrary to fear, honest conversations strengthen bonds when delivered with respect. People can handle hard truths; they can't handle hidden truths or pretense. * 🧠 **Smart leaders often struggle with people** — High IQ leaders can become overly reliant on logic, impatient with slower processors, and emotionally underdeveloped. Their intelligence can create blind spots about human dynamics. * ⚡ **Intelligence creates leadership distortions** — Brilliant leaders often treat relationships like cognitive systems, underestimate emotions, and develop subtle arrogance that assumes others are "the problem" when they're slower or more emotional. * 🎯 **Impact matters more than intent** — Leaders underestimate how their power magnifies everything — a passing comment can ruin someone's weekend, and blunt critiques can stick for months, regardless of good intentions. * 🔄 **Avoidance creates passive cultures** — When leaders interrupt, rush ahead, or dismiss concerns, teams learn to defer quickly and avoid ownership. Then leaders complain about passive teams without seeing their role in creating that dynamic. ### Stop Thinking of AI as a Coworker. It's an Exoskeleton. * 🤖 **The Wrong AI Metaphor** — Companies treating AI as an autonomous "coworker" get disappointed, while those treating it as an amplifier of human capability see transformative results * 🦾 **The Exoskeleton Model** — AI should work like physical exoskeletons: Ford's EksoVest reduced injuries by 83%, BMW saw 30-40% reduction in worker effort, and military exoskeletons provide 20:1 strength amplification — all while keeping humans in control * 🏃 **Amplification Over Replacement** — Stanford's ankle exoskeleton made running feel like 24.9 miles instead of 26.2 for a marathon — the human still does the work, just more efficiently and sustainably * 🎯 **Micro-Agent Architecture** — Break down jobs into 47 discrete tasks rather than entire roles; build focused AI components that do one thing reliably (like automated commit messages) while keeping humans in the decision loop * 📊 **Context is Everything** — Autonomous agents fail because they lack implicit human context about company priorities, competitive dynamics, and strategic decisions that "never got written down anywhere" * 🔗 **The Product Graph Solution** — Kasava combines automated code analysis with human judgment to create a living representation of what your product actually is, not what marketing says it is * 💪 **Compounding Effects Matter** — A 30% reduction in muscle stress doesn't just mean less fatigue — it means fewer injuries, longer careers, and preserved cognitive resources for creative work that actually moves products forward * 📈 **Market Reality Check** — The exoskeleton market is growing 20% annually toward $2 billion by 2030, but it's for amplifying human capability, not replacing workers — same pattern will apply to AI * * * # That’s all for this week’s edition I hope you liked it, and you’ve learned something — if you did, don’t forget to give a thumbs-up, add your thoughts as comments, and share this issue with your friends and network. See you all next week 👋 Oh, and if someone forwarded this email to you, sign up if you found it useful 👇 ## Sign up for The Managers' Guide Your guide to engineering leadership Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime.

소프트웨어 개발에서 작업 추정은 복잡계(Complex) 영역 에 속하며, 아무리 숙련된 팀이라도 본질적으로 정확한 추정이 불가능함 #NoEstimates 운동은 추정이 성과 목표로 오용 되는 현실에 대한 정당한 반발이었지만, 추정 자체를 거부하면 조직의 조율 능력이 사라...

> Remember: The dumbest person you know is being told 'you are absolutely right' by a LLM right now. > > David Gerard * * * ### Why Estimates Fail (And Why You Still Need Them) * 🌡️ #NoEstimates was reacting to a real problem — estimates being misused as performance targets — but "don't estimate" is like smashing the thermometer because it gives bad news * 🏢 Organizations genuinely need estimates for external commitments, inter-team coordination, and ROI trade-offs — the team isn't the only audience * 🧩 Per Joseph Pelrine's research, software estimation lives in the **Complex** domain (Cynefin), meaning cause and effect are only knowable in retrospect — even great teams will only ever produce mediocre estimates, and that's a property of the domain, not the team * 📉 The **Cone of Uncertainty** means estimates are least reliable exactly when they're most needed — and the cone only narrows through actual learning, not meetings * 🔢 Fibonacci sizing isn't a quirky ritual — the non-linear gaps encode uncertainty, and the _disagreements_ during estimation are where real alignment happens * 🪤 The core dysfunction: estimates become commitments through social pressure, not logic — and estimates imposed on teams (rather than owned by them) make this worse * ✅ The fix is separating three things: **estimate** (probabilistic range with assumptions), **plan** (commitment to a process), and **commitment** (a rare, deliberate promise) * 📋 Better practices: estimate late, give ranges not points, make assumptions explicit, track accuracy without punishment, and split anything over an 8 ### AI Is Forcing Us To Write Good Code * 🤖 **AI forces better code practices** — Agents struggle with messy codebases and can't clean up their own mistakes like humans, making previously "optional" good practices essential for success * 📊 **100% test coverage is a game-changer** — Not about preventing bugs, but ensuring every line of AI-written code is verified with executable examples; creates a simple todo list and eliminates ambiguity about what needs testing * 📁 **File organization becomes an interface** — Since AI tools navigate primarily through filesystem structure, thoughtful directory naming and many small, well-scoped files dramatically improve agent performance and context loading * ⚡ **Dev environments must be fast, ephemeral, and concurrent** — Agents need quick feedback loops with sub-minute test suites, one-command environment setup, and ability to run multiple isolated environments simultaneously * 🔧 **Strong typing eliminates whole classes of problems** — TypeScript with semantic type names (like `UserId`, `WorkspaceSlug`) helps agents understand intent immediately and reduces the search space of possible actions * 🚀 **The "tax" of good practices pays dividends** — What felt like optional overhead for human developers becomes essential infrastructure for AI agents, creating the codebase teams always hoped for * 🎯 **Remove degrees of freedom from AI** — Strict linters, formatters, and automated enforcement of best practices constrain the LLM to only make correct choices, acting as essential guardrails ### Dangerous advice for software engineers * 🔪 **Sharp tools vs. dangerous advice** — Both can be hugely helpful or harmful depending on competence and judgment; giving wrong person dangerous advice is like giving wrong person production SQL access * 🎯 **Examples of dangerous advice** — Make your own decisions about what to work on, deliberately break written company rules sometimes, take strong positions when uncertain, identify as a bit of a "grifter," avoid non-shipping activities * 💡 **Why dangerous advice matters** — Strong engineers crave it like sharp tools; most career advice is "fake" written to avoid liability or impress people rather than actually help * 🤐 **Manager limitations** — Managers almost never give dangerous advice even when needed because if you follow it wrong, it's much worse for them professionally than for you * ⚖️ **High-risk, high-reward nature** — Dangerous advice is disproportionately useful to strong engineers and harmful to weaker ones; requires courage and judgment to follow effectively * 🏢 **Organizations aren't just written rules** — Author argues against "Seeing Like A State" mistake of over-prioritizing legibility; all communities have load-bearing illegible components that matter * 🤔 **Target audience consideration** — If you don't feel comfortable following dangerous advice, you definitely shouldn't; but if you're already operating this way sometimes, you're probably not making a horrible mistake ### Match The Pipes _An executive skill_ * 🍩 **Toxic Management Culture** — A CEO's donut ritual became a bizarre loyalty test, forcing employees to secretly throw away donuts to avoid Monday morning lectures about "not caring enough" * 🚰 **The Pipe Capacity Principle** — Water flow through connected pipes is limited by the narrowest pipe, not the widest — expanding non-bottleneck pipes doesn't increase overall system capacity * 👔 **Executive Trade-off** — Executives sacrifice hands-on detailed work for broader influence and greater rewards, but gain unique visibility across entire organizational processes * 🔍 **Finding Bottlenecks** — Executives can identify the narrowest "pipe" in Product → Design → Engineering → Operations/Sales/Marketing chains by looking for upstream work piling up * ⚡ **Strategic Interventions** — Only executives can reduce upstream output, expand bottleneck capacity, reroute work to non-ideal alternatives, and shift improvement focus when bottlenecks change * 😡 **Pressure vs. Systems Thinking** — The author got emotional about "80-hour work weeks" mandates because pressure doesn't increase system capacity — it just stresses people while consequences fall on those least able to push back * 💔 **Human Cost** — High-pressure environments cause mental health breakdowns, divorces, family trauma, and even suicide — permanent costs with minimal benefit * 🛠️ **Management Responsibility** — Executives have "grave responsibility with life-changing consequences" and need proper management tools from experts like Drucker and Deming, not just pressure tactics ### Slow down to speed up _Why AI makes the slow phases of work more important, not less._ * 🧠 **System 1 vs System 2 Thinking** — AI excels at fast, pattern-matching work (System 1) but human judgment is still needed for deliberate, analytical thinking (System 2) about what to build and why * ⚡ **The Speed Paradox** — AI has made the slow phases of work more important, not less, because when execution is cheap and fast, the leverage shifts to the decisions that precede it * 💸 **The Cost of Wrong Decisions** — A wrong requirement or flawed design assumption propagates faster through everything AI helps you build, making upfront thinking more valuable than ever * 🕳️ **The Illusion of Speed** — AI can help you create technical debt faster by faithfully implementing flawed decisions in thousands of lines of confident-looking code that solves the wrong problem * 📋 **Thinking First Protocol** — Spend time clarifying what you actually want before offloading work to AI — write down the problem, success criteria, and constraints first * 🔍 **AI for Deliberation** — Use the same tool that accelerates execution to accelerate deliberation through pre-mortems, edge case generation, and requirement interrogation * 🏔️ **Hill Chart Methodology** — Map work to "uphill" slow phases (figuring things out, high uncertainty) and "downhill" fast phases (clear path, pure execution) * 🛡️ **Managing Velocity Pressure** — Combat "Can't you just use AI?" pressure by being explicit about which phase you're in, timeboxing slow work, and showing your thinking process * 🎯 **Strategic Slowness** — Teams that ship fastest long-term are often those who slow down at the right moments — speed and slowness are tools for different phases, not opposites ### * * * # That’s all for this week’s edition I hope you liked it, and you’ve learned something — if you did, don’t forget to give a thumbs-up, add your thoughts as comments, and share this issue with your friends and network. See you all next week 👋 Oh, and if someone forwarded this email to you, sign up if you found it useful 👇 ## Sign up for The Managers' Guide Your guide to engineering leadership Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime.

YouTube video by Allen Holub

YouTube video by Devoxx France

YouTube video by Agile meets Architecture

YouTube video by Agile meets Architecture

I’ll admit that until I discovered planning poker many years ago, estimating was not my favourite thing to do. Even though I had experience...