Hard Boiled Software

Justin Reock is Deputy CTO at DX, the developer intelligence platform built on the research behind DORA, SPACE, and the DevEx framework. An engineer, speaker, and writer with more than 25 years in software, Justin spends much of his time with engineering leaders worldwide, helping them measure developer experience, turn that data into continuous improvement action, and figure out what their AI spend is actually buying.Episode DescriptionEveryone wants to know whether AI is paying off. Justin Reock has more data on that question than almost anyone and claims ROI may not be here yet. Token spend is up roughly 50x year over year, but velocity is climbing in a straight line rather than a curve, and CFOs have started showing up in engineering meetings. He argues that’s a strong signal the current hype cycle is about to get a reality check.Nerd/Noir has been an early adopter and partner of DX, so Justin and Dave start with the origin story: how DX grew from a PhD-grade perceptual survey into the Core 4, why qualitative signals from engineers turn out to be more reliable than system metrics in almost every divergence, and why you should never wait for your data to be “ready” before you start measuring. From there, the conversation turns to the hard part: change management. Justin lays out the two beliefs an organization has to adopt before any of this data does anything: developer experience is a systems problem, not a people problem, and it is the leading indicator of productivity.The back half is about what endures. Physics and cognitive psychology have not changed. The theory of constraints is still Justin’s north star. Psychological safety remains the strongest predictor of a productive team, and it is under more threat now than in years. Justin also previews what DX is building next: the CAFE(S) framework for context engineering, and PDLC Insights that bring the DXI’s rigor to product managers and designers. Because once the code is instant, the bottleneck moves somewhere else.Links & ResourcesGuest Links* Justin Reock on LinkedIn* DX* DX NewsletterDX Research & Resources* State of AI Impact in Engineering: Q3 Report* The DX Core 4 and the Core 4 guide* Developer Experience Index (DXI)* DX Core 4 Benchmarks* CAFE(S): Your Agent Is Only as Good as Its Context in ACM Queue, and the DX whitepaper* AI Effectiveness report docsFrameworks & Research Referenced* DevEx: What Actually Drives Productivity by Abi Noda, Margaret-Anne Storey, Nicole Forsgren, and Michaela Greiler* The SPACE of Developer Productivity by Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler* DORA metrics* Google’s Project Aristotle on psychological safety* Theory of Constraints and the five focusing steps* Likert scale and “top box” scoring* Big Ball of Mud, the classic Foote and Yoder paper* LinkedIn’s Developer Productivity and Happiness FrameworkBooks Mentioned* Peopleware: Productive Projects and Teams by Tom DeMarco and Timothy Lister* The Goal: A Process of Ongoing Improvement by Eliyahu M. Goldratt and Jeff Cox* It’s Not Luck by Eliyahu M. Goldratt* The Infinite Game by Simon SinekPeople Referenced* Abi Noda, CEO and co-founder of DX* Dr. Margaret-Anne Storey, University of Victoria, co-author of SPACE and DevEx* Dr. Nicole Forsgren, co-author of DORA, SPACE, and DevEx* Brian Houck, distinguished scientist at DX, formerly Microsoft developer productivity research, lead author of CAFE(S)* Eirini Kalliamvakou, GitHub, co-author of CAFE(S)* Max Kanat-Alexander, Capital One, co-author of CAFE(S), formerly LinkedIn’s Developer Productivity and Happiness framework* W. Edwards Deming* Simon SinekAlso Mentioned* Agile Slovenia, where Justin gave the closing keynote, “Building 10x Organizations in the Era of AI,” on October 21, 2026* Honeycomb, creator of an observability platform and source of Justin’s “drowning in a sea of useless metrics” stickerTopics DiscussedFrom Research to Platform: How DX GrewDX started with research, not a product. Abi Noda’s joint work with Dr. Margaret-Anne Storey and Dr. Nicole Forsgren produced the DevEx framework, which, alongside DORA and SPACE, meant three metric frameworks were competing for attention. The Core 4 collapsed them into one, and the product grew outward from there.Key points:* The CEO is “allergic to scope creep,” which Justin credits for stable growth without sprawl* The surveys were engineered at a PhD level and get unusual participation: a recent client ran 23,000 engineers at 98% participation* Evolution went from survey, then system metrics normalized into the Core 4, then benchmarks, then AI impact measurementMaking the Case for Perceptual DataLeaders tend to value tool telemetry over sentiment. Justin’s counter argument: in almost every case where a qualitative signal and a system metric diverge, the system metric is the one that is broken.Key points:* Engineers are great observers of their environment when asked psychologically safe questions about the system rather than about themselves* Per Deming, 90-95% of productivity output comes from the system, not the worker* The DXI is a weighted composite scored on a top-box Likert scale; every one-point improvement returns roughly 10 hours per engineer per year* Nobody will ever score 100 on their Developer Experience Index; entropy always wins somewhereSystem Telemetry Made UsefulHooking up 15 or 20 tools and piling the output on a dashboard produces fragmented, diluted, and unactionable data. The fix is a normalization layer that maps everything back to a small set of meaningful metrics, and a culture that actually uses them.Key points:* None of the data matters without an audience committed to continuous improvement; it is an infinite game, not a project* Don’t fall into the “data readiness trap.” Your data will never be ready. Start now and let qualitative signals guide the cleanup* You need both: perception tells you builds are too slow; system metrics tell you whether that means two hours or ten minutesFrom Data to Action: The Core 4 as a ContractDave raises the failure mode of leaders using the data for apples-to-apples team comparisons. Justin reframes the whole thing as change management, which starts with adopting two beliefs and then breaking fragmentation.Key points:* Belief one: developer experience is a systems problem, not a people problem. That makes leadership accountable for delivering it* Belief two: developer experience is the leading indicator of productivity* Peopleware found about a 20% productivity spread inside a single organization but an 11x spread between organizations. A 10x developer in a 1x organization will never 10x* A single framework gives frontline managers autonomy to improve their teams however they see fit while keeping the organization aligned on one definition of productivity* Look for bright spots, not low scores. Get the leaders of high-performing teams together and ask what is replicable* This data should never be weaponized. Individual performance is an HR conversation, not a DX oneThe Core 4, DefinedJustin walks through the four measurements: speed (PR or merge throughput, or DX’s TrueThroughput, which weights PRs by complexity with a small ML model), effectiveness (the DXI), quality (change failure rate or defect ratio), and impact (innovation ratio, the share of time on new features versus keeping the lights on).Key points:* The four dimensions are atomic: you cannot derive speed from impact or quality from effectiveness, which is why Justin doubts there will ever be a “Core 5”* The counterbalancing comes straight from SPACE, what Storey calls “a constellation of metrics in tension with one another”* None of these are perfect metrics, but they are good proxies for change over timeWhat Leaders Are Worried About Right NowFresh off a travel binge through India, Singapore, Sydney, Western Europe, and the UK, Justin reports that despite the fastest hype cycle of his career, most leaders are still asking first-principles questions about how their developers are doing.Key points:* What is goo… This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit newsletter.nerdnoir.com

Hey all! We’re back from the summer break with Season 2 of Hard Boiled Software. This season’s theme is “people in the AI neighborhood" in which we seek out unique roles adapting to new technology. Today we have a story from two AI co-founders working across two startups. Double the fun!It was such a pleasure having an in-depth conversation with Chris and Troy. These guys are fascinating, pushing two AI-first companies forward at the same time. There’s a lot in here for anyone working in product discovery or innovation. The GuestsChris Hefley is co-founder and CEO of Predictability at Scale, the company behind UsageTap, and co-founder of FocusedFit, an AI-native executive recruiting platform. He previously co-founded and led LeanKit, the enterprise Kanban platform that was acquired by Planview in 2017 and is now known as Planview AgilePlace. A developer by training and a product leader by practice, Chris has spent his career building software companies and obsessing over how to hire the people who make them work.Troy Magennis is co-founder and CTO of Predictability at Scale and the founder of Focused Objective, where he became one of the best-known voices on probabilistic forecasting and Monte Carlo simulation in software delivery. He is the author of Forecasting and Simulating Software Development Projects, a Brickell Key Award recipient, and a former VP of Development and Global Architecture at Sabre. These days he builds open-source tooling for teams trying to bring some rigor to AI-assisted engineering.SummaryChris Hefley and Troy Magennis met in the middle of a conference hall in Seattle, with Troy holding a laptop and teaching Chris Monte Carlo simulation off an Excel spreadsheet for forty minutes. That conversation turned into years of collaboration at LeanKit, and eventually into a pair of AI companies they now run together.In this episode, Dave talks with both of them about what happens when the constraint that shaped software development for decades suddenly moves. When coding is no longer the slow step, uncertainty doesn’t disappear. It relocates, landing on strategy, product decisions, go-to-market, and the operating costs nobody budgeted for. Troy puts it plainly: at 600 miles an hour, being one degree off your strategy is a very big miss.The conversation covers their honest pivot story (including the part where a very good product arrived too late for its market), why software features alone no longer hold value, what AI inference is doing to SaaS margins, and how UsageTap and FocusedFit are each betting on a different kind of attention. Along the way, Chris explains why he doesn’t believe in A players, Troy shares his favorite forecasting tell, and Chris walks through how he runs a nightly council of AI agents that wake him up to a dozen pull requests every morning.Links & ResourcesGuest Links* Predictability at Scale: Chris and Troy’s company* UsageTap: usage metering, limits, forecasting, and billing for AI-native apps* FocusedFit: AI-native recruiting platform with agents that run the full search* Alvarez Search: healthcare executive search firm where FocusedFit took shape* Troy Magennis on LinkedIn* Chris Hefley on LinkedIn* Troy’s Substack* Focused Objective: Troy’s forecasting and metrics consultancy* Focused Objective Resources on GitHub: Troy’s free forecasting spreadsheets and presentations* Forecasting and Simulating Software Development Projects by Troy Open-source and AI Engineering Tools* PromptOpsKit: prompts and system instructions as versioned, linted, compiled application assets* CapabilityKit: capability-as-code, giving coding agents a dependency tree of what the system does* DeliveryTower: agentic engineering performance tracking, including capturing “regrets” as future constraintsBooks & Articles Mentioned* The Mom Test by Rob Fitzpatrick: how to get honest customer feedback when people want to be nice to you* Who: The A Method for Hiring by Geoff Smart & Randy Street: the A-player hiring book Chris references* Netflix Culture Deck: the first edition of the “we’re a team, not a family” professional sports team framing* “Big Ball of Mud” by Brian Foote & Joseph YoderTools, Frameworks & Concepts* Monte Carlo Simulation: probabilistic forecasting that rolls in the uncertainty of past outcomes* LeanKit / Planview AgilePlace: the enterprise Kanban tool Chris co-founded* OpenRouter: AI model gateway, recently acquired by Stripe* Stripe: payments, and UsageTap’s billing integration* Hugging Face: open model hub, recently acquired by Nvidia* Nylas: email and calendar connector API Chris pays for rather than maintaining himself* Lovable: AI app builder, cited for treating free-trial inference as marketing spend* Product Hunt: the launch platform where vibe-coded products meet their first inference bill* Myers-Briggs and DISC: the personality instruments Chris compares to “horoscopes for men”People Referenced* Jim Benson & Tonianne DeMaria: organizers of the Seattle Lean Kanban open space event where Chris and Troy met* Sanchit Maruti, MD: psychiatrist, UVM Larner College of Medicine associate professor, and FocusedFit co-founder* W. Edwards Deming: “A bad system will beat a good person every time”* Brian Foote & Joseph Yoder: authors of “Big Ball of Mud”Key PointsMonte Carlo and Where Uncertainty Lives NowTroy picked up Monte Carlo in the defense industry in the 1990s, where it was simply how risk was managed on fixed-price work. He brought it to software because a hope-and-prayers approach to on-time delivery was never good enough. AI hasn’t made forecasting obsolete. It has pushed us to confront where uncertainty lives.Key points:* Handoff and coding uncertainty is shrinking, but “are we building the right thing” and “does it stay working in production” are as uncertain as ever* Historical data only helps if your way of working hasn’t changed, which is exactly the trap for vendors who forecast from years-old data* Chris’s revelation in that first conversation: you don’t need thousands of data points to forecast usefully, just a small, recent sample from your new way of working* Troy kept his forecasting tools in spreadsheets on purpose, so people had to engage with the assumptionsThe Constraints Have MovedWith coding no longer the bottleneck, every other constraint in the system suddenly matters. Roles that used to have months of breathing room between quarterly planning cycles are now fielding “it’s done, what’s next?” within days.Key points:* Product, marketing, sales, training, and strategy can no longer hide behind a slow development constraint* Troy’s warning: at six miles an hour, being one degree off strategy leaves time to react; at 600, it’s a big miss* Teams can now wander into competitive markets they never should have entered, because poorly considered features ship faster than ever* Chris argues the Lean and Agile principles still hold, but every ceremony from big room planning to the retrospective deserves fresh eyesPivoting HonestlyChris and Troy trace the path from BlockedApp, a tool for surfacing blockers across large enterprises, through an AI gateway product that ran into OpenRouter, to the cost and usage features customers actually wanted. That extraction became UsageTap, and an example app built for an executive recruiting firm became FocusedFit.Key points:* Their blocker, dependency, and team forecasting work was genuinely good, and genuinely too late for a market that no longer plans the way it did in 2025* Troy on accepting “the death of some of your time”: no amount of wanting it changes what the market needs now* Chris’s discovery toolkit is mostly conversations, including treating early investor pitches as free consulting, while watching out for the Mom Test problem* Building in public matters more than ever, since traditional marketing can’t cut through the inbox noise* Showing up with a working product is now the baseline, and investors and accelerators increasingly expect around $10K in monthly revenue before taking the meetingWhere Software Value Lives NowIf anyone can buil… This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit newsletter.nerdnoir.com

Vic Chynoweth is the CEO of Tempo, a strategic portfolio management platform used by more than 30,000 organizations, including a large share of the Fortune 500. A biology undergrad who found his way into finance, Vic built his career on the operating side of software companies, with CFO and COO roles at Planview and JAGGAER, multiple leadership roles at Cray, and a turn as Managing Director and Operating Partner at Cove Hill Partners before taking the CEO seat at Tempo in 2025. He describes himself as a framework- and principles-led leader.Episode DescriptionWhat if the reason software valuations are falling apart has nothing to do with cost structure and everything to do with a single line in a discounted cash flow model?Vic Chynoweth came up through finance, not engineering, and that vantage point gives him an unusual but valuable perspective for this show. In this episode, he gives us a crash course on the concept of durable right to win and answers why AI putting that in question is enough to vaporize the terminal value that carries most of a high-growth software company’s valuation. It is the clearest explanation of the so-called SaaS-pocalypse you’re likely to hear, delivered by someone who has to lead a company through it.From there, the conversation turns to practical leadership. Vic lays out the leadership axioms he introduces on his first call with a new company, why he thinks his job is to make himself unnecessary, and the four categories of work (architecture, orchestration, builder, and field operations) he is currently using to rethink human capital management from scratch. He and Dave dig into where the delivery bottleneck went once AI removed it, why attribution between human and agent work is becoming a first-class measurement problem, and how to automate change management so the system doesn’t create developer whiplash every five minutes.There is also a nice segment on org design as a continuous experiment rather than an annual reorg, an honest postmortem on why monolithic portfolio management implementations made everyone miserable, and Vic’s argument that employee engagement is the single most important metric at a software company. Not because it’s a nice vibe, but because it is one of the very few measures where the professional and personal wins point in the same direction.Links and ResourcesGuest Links* Tempo Software, the strategic portfolio management platform Vic leads* Vic Chynoweth on LinkedIn* Vic’s Forbes Technology Council profile, which lays out his leadership axioms* Tempo’s announcement of Vic as CEO (January 2025)Films and Articles Mentioned* The Thinking Game (2024), the documentary on Demis Hassabis and Google DeepMind that Vic and Dave both watched recently. It centers on AlphaFold solving the protein folding problem, and is free on YouTube* Anthropic on Project Glasswing and Claude Mythos Preview, context for Vic’s point that security is his biggest AI concern* Dario Amodei’s warning on entry-level white-collar work, the Anthropic CEO comments Vic referencesTools, Frameworks, and Concepts* Durable right to win, a company’s long-term sustaining ability to generate cash flow, and the thing Vic argues AI has thrown into question across software* Terminal value, the perpetuity assumption at the end of a discounted cash flow model, and where most of a high-growth software company’s valuation actually lives* Vic’s leadership axioms, in order: visibility and alignment, accountability and support, enable and empower* Vic’s scalability principles: simplify, standardize, consider the customer experience, sustainability* Vic’s four categories of work: architecture, orchestration, builder, field operations* Vic’s definition of attribution, measuring the economic value of putting a person versus an agent versus both on a piece of work* Strategic Portfolio Management (SPM), the category Tempo competes in, project portfolio management (PPM)* Jevons paradox, raised by Dave in the context of AI creating new categories of work. Worth noting that Amodei himself reached for the same framework in 2026* Systems of record versus point solutions, Dave’s framing for which software businesses have a data moat and which are in the crosshairs* Forward-deployed engineers, a role originated by Palantir, Vic notes nobody was discussing a year ago, and everyone is discussing now* Planview, where Vic served as EVP and CFO, and a major player in traditional PPM* Atlassian and Jira, the ecosystem Tempo has historically built on, plus Linear, one of the ecosystems it is expanding into* Build, measure, learn, invoked by Dave as the loop that becomes essential again once shipping stops being the constraintPeople Referenced* Dario Amodei, CEO of Anthropic, on AI displacing early career roles in technology: a prognostication he’s since walked back on but continues to bubble up in the conversation* Demis Hassabis and Google DeepMind, via The Thinking Game* Marie-Michèle Caron, Tempo’s Chief Revenue Officer* Kevin Nanney, Tempo’s Chief Product Officer* Shams Chauthani, Tempo’s Chief Technology OfficerTopics DiscussedFrom Biology to Finance to the CEOVic opens by acknowledging that the path from biology undergrad to software CEO is not exactly a straight line. What connects the dots is a self-assessment he made early on: he is adequate as an entrepreneur but much better at scaling enterprises. Cray came first, one of the hardest and best experiences of his career, followed by private equity software, and then a run of CFO and COO roles.Key points:* Starting a company between undergrad and grad school taught him less about entrepreneurship than about the difference between what he prefers and what he is merely adequate at* Finance is what he calls a “connected organization,” with an open door into every function, which forces you to go find where you can add value* The single most important thing that role taught him was empathy: asking what he would need to make decisions if he were the CRO, the CTO, or the CIO, then bringing exactly that to the table* His formative habit is delivering data in the right form at the right time, usually visually, because up and to the right is legible in a way that rows and columns are notLeadership Axioms and the Goal of Not Being NeededAsked how to get a leadership group functioning as an actual team rather than treating teamwork as a contributor-layer concern, Vic reaches for the three axioms he introduces on his first call with any company. They stack, and each one lays the groundwork for the next.Key points:* Visibility and alignment come first, because without visibility you cannot align, and without alignment you head north while your partner heads east* Accountability and support come next: a faster business makes more mistakes, and that is fine as long as failures are surfaced, supported, and not repeated* Enable and then empower, in that order. Empowered decision-making without enablement just distributes decisions to people who lack the frameworks to make them* His stated philosophy across everything: figure out how to not be needed. He contrasts this with the common pattern of hoarding information precisely in order to remain necessary, which he calls a non-enduring approach to leadershipThe SaaS Apocalypse, Durable Right to Win, and Terminal ValueThis is the analytical heart of the episode. Vic explains why software valuations are compressing, and the answer is not the one Dave initially guesses. It is not that AI drives down labor costs and therefore changes the economics. It is that AI casts doubt on whether the company will even exist in ten years.Key points:* For a high-growth, low-profit software company, the overwhelming majority of valuation can sit in terminal value, the year ten assumption that the business persists and grows modestly into perpetuity* If AI puts a company’s durable right to win in question, terminal value does not get marked down gradually. It can go to something near zero effectively overnight, taking most of the valuation with it* The market shifts … This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit newsletter.nerdnoir.com

Simon Brown is the creator of the C4 model for Visualising Software Architecture and the founder of Structurizr, the original developer-friendly “diagrams as code” tooling for version-controlled architecture documentation. An independent consultant based in Jersey, he has spent 15+ years helping hundreds of organizations across roughly 40 countries communicate their software architecture more clearly. His new book, “The C4 Model: Visualizing Software Architecture”, arrived from O’Reilly this month.Episode OverviewWhy have software architects, declared dead a decade ago, suddenly turned up again on client org charts? And how did a set of plain block diagrams Simon Brown used to sketch for his own day job become a whiteboard standard you can spot everywhere from Miami to London to Mumbai?Simon tells the origin of C4 with characteristic modesty (he calls it “really boring”). It started in mid-2000s London, where he ran architecture workshops, looked at the diagrams people drew, and realized he couldn’t understand any of them. With UML on its way out and no appetite to bring it back, he taught people the block diagrams he already used at the office. That became C4: four levels of abstraction, one at a time, with a Google Maps-style zoom from a broad system context into containers, components, and code.From there the conversation ranges across the architecture revival and what’s driving it (compliance gaps, lost water-cooler knowledge, and a flood of AI-generated code nobody understands), why Simon refused to build a drag-and-drop editor and made a text-based DSL instead, the deployment diagram he thinks is the most slept-on view in the whole model, and a candid comparison of how developer cultures differ on either side of the Atlantic. It’s a clear-eyed, plain-spoken look at the craft of drawing software so other people can actually read it.Links & ResourcesGuest Links* Simon Brown’s website* The C4 model* Structurizr and the Structurizr docs* The C4 Model: Visualizing Software Architecture by Simon Brown (O’Reilly, 2026) — the rewritten and expanded successor to his self-published LeanPub C4 book; first six chapters are in early access* Software Architecture for Developers by Simon Brown (Leanpub)* Simon on LinkedIn* Simon on Bluesky* Simon on XBooks & Articles Mentioned* The Culture Map: Breaking Through the Invisible Boundaries of Global Business by Erin Meyer — the book Dave references on cross-cultural communication and negotiation styles, which maps how different cultures approach meetings and deals (best guess at the title Dave couldn’t recall in the moment; worth confirming before publishing)Tools, Frameworks & Concepts* Structurizr DSL — a lightweight, text-based domain-specific language for defining a C4 model as code; a wrapper over the original Structurizr for Java library, built during COVID lockdown* Model Context Protocol (MCP) — Simon added MCP tooling that runs validation and parsing so an LLM can read the error messages and fix its own invalid DSL* PlantUML — text-based diagramming tool; Structurizr can export views to it* Mermaid — diagrams-as-code tool with a C4-style syntax that doesn’t enforce C4 semantics or view rules* UML — the OG modeling notation that fell out of favor after the Agile Manifesto, leaving the gap C4 filled* The C4 abstractions — system context, container, component, and code, plus the supporting system landscape, dynamic, and deployment diagramsTopics & Key PointsThe "Boring Origin Story of C4Simon traces C4 back to the architecture workshops he ran in mid-2000s London, where he discovered he couldn’t make sense of the diagrams participants drew. With UML already on the way out, he simply taught the block diagrams he used in his own day job.Key points:* The work grew out of consulting: growing a consultancy meant creating more tech leads and architects, so Simon started teaching people how to move into those roles* C4 is “a formalization of the block diagrams” he drew in a post-UML world, shaped over years of feedback rather than designed as an invention* The name stuck even though most teams use only the top two levels; Simon jokes it could just as well be called “C2 plus two optional levels”One Level at a TimeThe main move with C4 is to stop putting everything on one page and instead focus on a single level of abstraction at a time, zooming in Google Maps style from the system context down toward the code.Key points:* The “everything on one page” everything-diagram puts almost everyone off: non-technical stakeholders, infrastructure folks, and product owners all tune out* Slicing the picture into levels invites more people to the party: business and UX people engage with the context diagram because they’re thinking about how users reach their goals, and infrastructure and DevOps people gravitate to the container diagram* The container diagram closes the gap between dev and ops who want to collaborate but speak different languages; network engineers have told Simon that the diagram finally let them understand what the developers actually hand over to run and monitor* Code-level diagrams are almost never drawn (Simon has done it once), and even component diagrams are niche, most useful when planning a service extraction from a monolith or arranging a new small-to-medium monolithThe Architecture RevivalDave notes that architect roles are reappearing among clients in 2026 after years of backlash against “ivory tower” architects. Simon offers two theories for why.Key points:* Theory one: organizations that swung from heavy upfront design all the way to “working software over comprehensive documentation” overcorrected, and now fail compliance audits, hold critical knowledge in tribal silos, and don’t fully understand the software running their business; COVID made it worse by erasing water-cooler knowledge transfer* Theory two: AI and vibe coding produce thousands of lines of code nobody understands, can review, or knows how to fit into existing systems, nudging teams back toward some planning, not months of it, but enough to bring structure* Dave frames the shift as planning and feedback loops moving left up the value stream, now reaching into architecture and product conversations* A good plan plus small, reviewable slices (build a slice, then pause and review) is producing strong results in Dave’s own workflowDiagrams as Code with StructurizrSimon explains why he turned down a WYSIWYG editor for C4 and instead built a text-based DSL, and why that choice has aged well in the AI era.Key points:* He’s a developer. He likes text, version control, and diffs. Drag-and-drop canvases give a low barrier and quick wins but become unmanageable at scale (picture adding one system that connects to forty others by ticking boxes in a GUI)* The earliest Structurizr tooling required writing Java, which few people wanted, so during lockdown Simon built the lightweight Structurizr DSL as a wrapper over the Java library; the first version took about a week* The DSL is model-based: one text file can drive multiple views with consistent styling, and relationships defined at lower levels bubble up automatically to reduce what you have to write* All this turns out to be AI/LLM-readable too; Simon added MCP tooling so an LLM can run validation and parsing, read the error messages, and fix its own invalid output* Unlike Mermaid, which offers a C4-style syntax without understanding C4’s semantics or view rules, the Structurizr DSL bakes the rules in and won’t let you mix abstraction levels; you can still export to PlantUML or Mermaid when your toolchain needs themThe Slept-On DiagramsBeyond the four static levels, Simon walks through the supporting views people tend to overlook, and names his favorite underrated one.Key points:* The system landscape diagram is essentially a context diagram without a single-system focus, a wider view of the world around you* The dynamic diagram shows how one feature works at runtime as a set of collaborations; it’s genuinely useful but underused, and the trick is to doc… This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit newsletter.nerdnoir.com

Jimmy Parker is the Founder and Chief Transformation Officer of Peaq, where he helps companies create fast, lasting transformation at scale. A graduate of the U.S. Naval Academy who served 11 years as a Marine Corps helicopter pilot, Jimmy went on to earn a PhD in developmental psychology applied to organizational transformation from Fielding Graduate University. Before founding Peaq, he led organizational development at The Home Depot and Kaiser Permanente, where he spent the better part of two decades studying what actually changes on-the-job behavior, and just as importantly, what doesn’t.Episode DescriptionWhat if almost everything we spend on training never makes it back to the job? That isn’t rhetorical. The research Jimmy Parker has been chasing for 20 years puts the application rate of traditional training somewhere between zero and nine percent. In this conversation, Jimmy traces the path from his frustration as a classroom trainer to a methodology he calls micro experiences, a way of changing behavior at scale by leading with doing rather than knowing.Jimmy’s career arc is a study in contrasts. started in the Marine Corps as an attack helicopter pilot, then carried that low tolerance for theater into corporate L&D. He has studied behavior change wherever the lessons live, including habit science, marketing, addiction recovery, even religious conversion, and he has spent years pressure-testing what survives contact with a real organization. The result is a system designed around the gap between knowledge, behavior, and habit, and a specific format for closing it: a 45-minute action in the flow of work, paired with a reflection question, followed by a small-group conversation, repeated weekly for three to six months.We get concrete in this episode. Jimmy walks through two micro-experiences he uses in the field: the “judo move” for product teams stuck in order-taker mode, and a decision audit for executives who say they want to grant autonomy but never quite manage to. We talk about why most OKR programs would score a D, why simple isn’t easy when you’re designing for behavior change, and why Jimmy ultimately frames this work as a question of equity, because the people who get the highest-quality development today are almost always the rare and privileged few.Links and ResourcesGuest Links* Peaq — Jimmy’s consulting practice* Jimmy Parker on LinkedIn* Email Jimmy directly: [email protected], Frameworks, and Concepts* Micro Experiences — Jimmy’s framework for behavior change at scale, structured as 45-minute on-the-job actions with reflection and small-group debrief* The Four-Step Weekly Cycle — adapt, do, reflect, discuss* Experiential Learning — the tradition of learning by doing and reflecting, traceable to John Dewey* Declarative vs. Implicit Knowledge — the distinction between what can be taught in a classroom and what can only be learned through doing* Unconscious Competence — the final stage in the progression from ignorance to habit* OKRs (Objectives and Key Results) — referenced as an example of how knowing the framework rarely translates to doing it wellPeople Referenced* John Dewey — the philosopher widely regarded as the father of experiential learning, often paraphrased: "We do not learn from experience, we learn from reflecting on experience.”Topics DiscussedFrom the Cockpit to Behavior ChangeJimmy opens with the throughline of his career: a love of leadership picked up in the Marine Corps, sharpened by years of running leadership training programs, and ultimately reshaped by the uncomfortable realization that classroom training rarely changes what people actually do on the job. That frustration sent him on a 20-year hunt across disciplines for what really drives behavior change.Key points:* The military taught Jimmy a low tolerance for things that don’t work, a standard he has carried into executive development* After running thousands of people through classrooms, Jimmy noticed the change rarely manifested on the job* His study took him well outside L&D, into habit science, addiction recovery, religious conversion, and consumer marketing, looking for what consistently moves behavior* The work eventually focused on executive behavior change, because the cultural barriers that block agile teams often exist above the teamWhy Traditional Training Falls ShortTraining is built on a single assumption: if people knew differently, they would do differently. That assumption holds for simple knowledge gaps and breaks down almost everywhere else. Jimmy is direct about the implications, including that the application rate for traditional training tops out at around 9%.Key points:* Studies from Harvard, MIT and others put the percentage of training participants who properly apply what they learned between zero and nine percent* Knowledge transfer is the right move for simple gaps; for complex, contextual, or culturally rooted behaviors, it almost never gets you to adoption* Agile talk is the common tell: organizations describe themselves in agile terms while their actual norms, requirements flow, and decision rights tell a different story* Most OKR programs score a D or C when measured against best practice, even when the people running them teach OKRs for a livingKnowledge, Behavior, HabitJimmy keeps his definitions deliberately simple because the value is in the progression rather than the taxonomy. Knowing is what you can recall. Behavior is what you can be observed doing in a given moment, including how you speak. Habit is what you do consistently, without conscious thought, even when old patterns are pulling you backward.Key points:* The path from ignorance to habit runs through a stage of effortful, high-cognitive-load doing before the new behavior becomes automatic* Most behavior change interventions stop at knowing and hope the rest takes care of itself* Speech counts as behavior, which is part of why team communication and conflict patterns are so hard to change* The endpoint is unconscious competence, and getting there takes deliberate reps over timeExperience as the Lead, Not LearningWhen Dave and Jimmy were planning the episode, Jimmy specifically pushed back on using the word learning to describe his work. The reason matters. Leading with experience is a wager that doing first, then reflecting, gets you further on the hard problems than thinking your way to a new way of acting.Key points:* Declarative knowledge can be taught; the tacit, contextual knowledge of when and how to adapt can really only be learned through reps and reflection* Jimmy borrows from Dewey: experience by itself isn’t enough; the learning lives in structured reflection on the experience* “Do we think ourselves into a new way of acting, or act ourselves into a new way of thinking?” Both work, but the second is consistently underused* For deeply rooted behaviors, especially with senior leaders, the experiential path tends to be the only one that landsAnatomy of a Micro ExperienceJimmy walks through two real examples. The first is the “judo move,” a one-pager for product teams stuck in order-taker mode, offering a handful of responses to use when a stakeholder hands them features without context. The second is the decision audit, where executives track every decision they make for a week and score each on a one-to-five scale of whether someone else should have owned it.Key points:* A micro experience has two non-negotiable components: micro, meaning it fits in 45 minutes or less, and experiential, meaning it happens in real work, not in a simulation or a classroom* Each micro experience runs on a four-step weekly cycle: adapt it to your context, do it, reflect using a designed question, then debrief with a small group of five or six peers* The decision audit consistently surfaces hidden patterns: leaders score their own decisions and realize how many they’re holding onto, and why* Designing micro experiences turns out to be much harder than it looks; Jimmy describes it as something close to a PhD-level design skill w… This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit newsletter.nerdnoir.com

Adam Dymitruk is the creator of event modeling and the CEO and founder of Adaptech Group, a consultancy that builds information systems using event sourcing and event modeling. A software developer with over three decades of experience, Adam is a core contributor to CQRS and event sourcing theory and practice since 2008, a top 0.1% Stack Overflow contributor, and one of the original voices in the ALT.NET movement. He’s currently writing the definitive book on event modeling, with a companion booklet due out first.Episode DescriptionWhy do we keep building software that breaks every time we add a feature? And what if there were a way to describe a system so clearly that business people, designers, and developers could all work from the same blueprint?In this conversation, Adam Dymitruk traces a path from the rebellion of the ALT.NET movement in the mid-2000s through the rise of domain-driven design, the discovery of event sourcing, and the creation of event modeling, a notation and process for describing information systems that has quietly become one of the most practical innovations in modern software design. Along the way, Adam and Dave revisit shared history: the nHibernate Mafia, the fight against sealed classes, the moment when Martin Fowler’s 2005 article on event sourcing planted a seed that would take years to fully grow, and the community of developers who decided they’d rather take care of each other than wait for permission from Microsoft.The heart of the episode is Adam’s case for why event sourcing and event modeling eliminate entire categories of problems that most teams accept as inevitable: the hockey-stick cost curve, the coupling that turns codebases into houses of cards, the schema migrations that become existential crises, and the tech debt that accumulates because every new feature has to touch code that already works. Adam explains how Adaptech Group has built its business on fixed-cost contracts and free bug fixes, not as a loss leader but because the architecture genuinely makes it possible. The conversation closes with Adam’s view on AI as the next irreversible point of no return, why event modeling provides exactly the kind of specification that AI needs to generate good code, and a first look at the two books he’s writing to bring this work to a wider audience.Links & ResourcesGuest Links* Adaptech Group — Adam’s consultancy* Event Modeling — the official site for the event modeling methodology* Event Modeling: What is it? — Adam’s original 2019 article* Adam Dymitruk on LinkedIn* Adam Dymitruk on GitHub* Event Modeling Discord CommunityBooks & Articles Mentioned* Understanding Eventsourcing by Martin Dilger — the first book combining event modeling and event sourcing* Domain-Driven Design by Eric Evans — the influential “blue book” both Adam and Dave reference on multiple occasions* Domain-Driven Design Reference by Eric Evans — the companion booklet that Adam credits as a model for his own booklet approach* Working Effectively with Legacy Code by Michael Feathers — cited by Adam as a model for the reference-pattern format of his upcoming book* “Event Sourcing” by Martin Fowler — the December 2005 article that introduced Adam to event sourcingTools, Frameworks & Concepts* Event Sourcing — an architectural pattern of storing state changes as an immutable sequence of events* CQRS (Command Query Responsibility Segregation) — a pattern for separating read and write models* Domain-Driven Design — Eric Evans’ approach to software development that became the intellectual home for event sourcing in the .NET world* Event Storming — Alberto Brandolini’s workshop format that influenced event modeling’s collaborative approach* ALT.NET — the mid-2000s .NET developer community that championed open source, TDD, and better practices* Test-Driven Development (TDD) — discussed at length, including Adam’s controversial position that event sourcing eliminates the need for it* Cucumber — BDD testing tool that Adam used before discovering that events themselves serve as specifications* Storyteller — Jeremy Miller’s graphical DSL testing framework for .NET that Adam used extensively for specification by example* NUnit — Charlie Poole’s open source .NET testing framework, a counterpart to Java’s JUnit* nHibernate — the open source .NET ORM ported from Java’s Hibernate; central to ALT.NET’s origin story (originally nicknamed the “nHibernate Mafia”)* Dynamic Consistency Boundary — an evolution beyond DDD aggregates for managing consistency in event-sourced systems* Specification by Example / Behavior-Driven Development — the testing and specification approaches that preceded event modeling* Open/Closed Principle — referenced by Adam in the context of event sourcing’s add-only architecture* Cursor — AI coding tool Adam used to demonstrate that event model screenshots produce correct implementations on the first try* Unix Philosophy — invoked by Dave to describe the component architecture that event sourcing enables: many specific tools that each do one thing wellPeople Referenced* Greg Young — CQRS and event sourcing pioneer, longtime collaborator* Scott Bellware — Founder of the Eventide project and co-founder of ALT.NET* Martin Fowler — author of the 2005 event sourcing article* Eric Evans — author of Domain-Driven Design* Michael Feathers — author of Working Effectively with Legacy Code (also former podcast guest)* Alberto Brandolini — creator of Event Storming* Martin Dilger — author of Understanding Eventsourcing* Jeremy Miller — creator of the Storyteller testing framework* Mike Stockdale — creator of SpecSharp, from Calgary* Charlie Poole — creator of NUnit* Sebastian Lambla — .NET open source contributor whose work was famously overwritten by Microsoft* Scott Hanselman — referenced in the context of ALT.NET’s reach into the Microsoft communityTopics DiscussedThe ALT.NET Rebellion and Finding Your PeopleAdam and Dave open by tracing their shared history in the ALT.NET movement, a community of .NET developers who pushed back against Microsoft’s top-down approach to software development in the mid-2000s. What started as frustration with sealed classes, proprietary tooling, and the “embrace, extend, extinguish” mentality became a proving ground for open source, test-driven development, and the architectural ideas that would shape both of their careers.Key points:* ALT.NET (originally nicknamed the “nHibernate Mafia”) was born from developers needing to take care of each other because Microsoft wasn’t supporting the open source community* The community brought together TDD practitioners, open source advocates, and domain-driven design enthusiasts, creating the conditions for ideas like event sourcing to gain traction* Figures like Sebastian Lambla experienced the worst of Microsoft’s competitive stance, having their open source work overwritten overnight by official Microsoft alternatives* Both Adam and Dave credit ALT.NET as the environment where their points of view coalesced, particularly around DDD and event-driven architecturesFrom Domain-Driven Design to Event SourcingThe conversation traces how DDD provided the intellectual soil for event sourcing to take root, beginning with Martin Fowler’s 2005 article and evolving through Adam’s own experiments writing his first event store in 2009. Adam describes the shift from thinking about domain models and objects to thinking about state changes, facts, and immutable ledgers.Key points:* Adam wrote his first production event store in 2009 as a single page of C# code, proving the simplicity of the approach* The key insight: treat information the way accountants treat money, with full accountability and no erasures* Specification by example and BDD, while valuable stepping stones, became unnecessary once events themselves served as human-readable specifications* The community continues to evolve; practices like dynamic consistency boundaries are replacing traditional DDD aggregates, and event versioning through upcasters is giving way to handling multiple event versions directly in read … This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit newsletter.nerdnoir.com

Woody Zuill is the leading advocate of mob programming, now called software teaming, an approach in which the whole team works together on the same thing at the same time on the same computer. A software developer for over 40 years, Woody is the co-author of Software Teaming: A Mob Programming, Whole-Team Approach (with Kevin Meadows) and a globally recognized speaker, trainer, and coach who has delivered workshops on every continent except Antarctica. He’s also an instigator behind the #NoEstimates discussion and a lifelong student of what makes teams actually work.Episode DescriptionWhat happens when you put the whole team at one keyboard and keep them there? In this wide-ranging conversation, Woody Zuill traces the path from his earliest experiments with pair programming in the late 1990s through the accidental discovery of mob programming at Hunter Industries to his current thinking on software teaming, AI, and the art of storytelling. Along the way, he reveals how a children’s book illustrator, a musical instrument factory, and a very specific kind of stubbornness about teamwork shaped one of the most distinctive practices in modern software development.Woody shares the origin story of mob programming with refreshing honesty: how the name was borrowed from someone else’s article, how the practice emerged from simply not wanting to stop working together, and how his early struggles with public speaking led to a decades-long commitment to iterating on the same talks until they shine. The conversation moves through the concept of Team Flow (and why it validated what Woody’s teams were already experiencing), how different teams around the world have adapted software teaming to fit their own rhythms, and why the question “how can five people at one computer be productive?” might be the wrong question entirely.Whether you’re curious about what mob programming actually looks like in practice, wondering whether AI changes the case for working together, or just want to hear why Woody thinks we’ll stop writing code in programming languages altogether someday, this episode delivers the kind of hard-won, experience-tested insight that only comes from someone who’s been doing the work, and paying attention, for four decades.Links & ResourcesGuest Links* Woody Zuill’s Website* Woody Zuill on LinkedIn* Software Teaming: A Mob Programming, Whole-Team Approach by Woody Zuill & Kevin MeadowsBooks & Articles Mentioned* Teaming: How Organizations Learn, Innovate, and Compete in the Knowledge Economy by Amy Edmondson — the book that made Woody wish he’d called it “teaming” from the start* Extreme Programming Perspectives — edited collection containing the original “Mob Programming” article by ThoughtWorks practitioners* Pair Programming Illuminated — early book on pair programming that influenced Llewellyn Falco’s thinking* Team Flow: The Psychology of Optimal Collaboration by Jef van den Hout & Orin C. Davis — research on achieving shared psychological flow in teams* “Big Ball of Mud” by Brian Foote & Joseph Yoder — the classic 1997 paper on the most common software architecture patternTools, Frameworks & Concepts* Software Teaming / Mob Programming — a whole-team approach to software development at one computer* Strong-Style Pairing — Llewellyn Falco’s driver-navigator technique: “For an idea to go from your head into the computer, it must go through someone else’s hands.”* FAST Agile — Fluid Adaptive Scaling Technology, developed by Ron Quartel, is closely related to software teaming* #NoEstimates — discussion and movement around rethinking estimation in software, originated by Woody* Driver-Navigator Pattern — the foundational collaboration technique for pair and mob programming* Team Flow — research concept from Jef van den Hout on achieving collective psychological flow in teamsPeople Referenced* Llewellyn Falco — inventor of Strong-Style Navigation, creator of ApprovalTests, recommended by Woody for an interview* Amy Edmondson — Harvard professor, author of Teaming* Linda Rising — speaker and author who advised Woody early on to tell stories in presentations* Ken Schwaber — Scrum co-creator; Woody trained with him at the 2007 Scrum Gathering in Portland* Ron Quartel — creator of the FAST framework and experimented with dynamic teaming in Seattle* Jef van den Hout — Dutch researcher at Eindhoven University of Technology, developed the Team Flow model* Mihaly Csikszentmihalyi — psychologist who originated the concept of psychological flow* James Herr — Woody’s collaborator on talks about mob programming and AI* Fred Zuill — Woody’s brother, who described AI as “a rather faulty, somewhat moderately skilled collaboration partner.”* Andrea Zuill — Woody’s wife, children’s book author and illustrator (Wolf Camp, Sweety, Dog vs. Strawberry, and others)* Kevin Meadows — co-author of Software Teaming* Brian Foote & Joseph Yoder — authors of the “Big Ball of Mud” paper* Taiichi Ohno — Toyota Production System pioneer (referenced by Dave)Topics DiscussedThe Art of Iterating on a TalkWoody opens up about his journey from someone who couldn’t speak in front of five people to a presenter who has addressed audiences of over a thousand. His approach—repeating the same talk title while continually refining the content—runs counter to the conference circuit norm of always delivering something new, but mirrors the iterative principles at the heart of Agile itself.Key points:* Early advice from fellow speakers (including Linda Rising) shaped his approach: speak about what you know deeply, tell stories, and start with friendly audiences* His wife Andrea’s illustrations became a signature element of his presentations, helping audiences connect emotionally even before absorbing the content* The process of noting audience questions after every talk and incorporating answers into future versions created a natural feedback loop spanning yearsFrom Pair Programming to Software TeamingThe origin story of mob programming traces back through Woody’s pair programming experiments in the late 1990s, an article in Extreme Programming Perspectives, and a series of increasingly larger team experiments that culminated at Hunter Industries around 2011-2012. The naming journey—from mob programming to software teaming—reflects both practical concerns and a deeper philosophical shift.Key points:* The “mob programming” name came from an article in Extreme Programming Perspectives (circa 2001-2002) by ThoughtWorks practitioners who experimented with groups larger than pairs* Woody dropped “programming” because it excluded testers, product people, and designers; he dropped “mob” because it means “bullying” in some European languages* Amy Edmondson’s Teaming (2012) captured what Woody was already seeing: the ability to work effectively as a team at any moment, not just being assigned to one* The real insight wasn’t a method—it was noticing that software teams never actually worked like teams in other industries (construction crews, bands, sign installation teams)Team Flow and the Prerequisites for Great TeamworkWoody connects his team’s experience at Hunter Industries to Jef van den Hout’s research on Team Flow at Eindhoven University of Technology. The academic framework validated what Woody’s teams had felt intuitively—and gave language to the conditions that make it possible.Key points:* Team Flow requires collective ambition (shared life values), a common goal (the work itself), personal goal alignment, high skill integration, open communication, and mutual commitment* The rock band analogy: shared ambition to be a band, common goal of the music, and personal goals that complement rather than compete (you don’t put six bass players in a group)* Once these conditions are met, continuous improvement happens naturally — you don’t need to impose it through retrospectives or process mandates* Woody reads extensively but approaches research skeptically; Team Flow resonated because it matched his direct experienceVariations in Practice Around the WorldHaving conducted workshops … This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit newsletter.nerdnoir.com

Connecting the Dots from Strategy to ExecutionSteve Elliott is the founder and CEO of Dotwork, an AI-native strategic alignment platform built on knowledge graphs and flexible ontologies. A serial entrepreneur with several successful exits, Steve previously founded AgileCraft (acquired by Atlassian in 2019) and served as Head of Product at Atlassian. He also co-founded The Uncertainty Project, a community-driven playbook for better organizational decision-making, and is the author of The Decisive Company.Episode OverviewWhy do so many organizations still run strategy on spreadsheets and slide decks? And what would it look like if AI could actually understand how your organization thinks—not just summarize its documents?In this conversation, Steve Elliott traces his path from Big Six consulting through serial entrepreneurship to the problem that’s consumed his career: strategic alignment in large, complex organizations. He unpacks why the gap between executive intent and team execution persists despite decades of tooling, and why the first generation of enterprise agility platforms—including the one he built and sold to Atlassian—ultimately couldn’t solve it. The root issue, Steve argues, isn’t cultural or procedural. It’s structural: organizations lack a durable, evolving memory of how they operate and why they make decisions.That diagnosis led Steve to build Dotwork, a platform that combines flexible ontologies, knowledge graphs, and AI to create what he calls an organizational operating system—one that can observe how work actually flows (not just how it’s drawn on slides), maintain context across planning cycles, and surface signals to leaders without drowning them in noise. Along the way, the conversation covers why operating models aren’t operating systems, how to make decisions under uncertainty, and what it would take for AI to move beyond task-level productivity to genuine systemic intelligence.Guest Links* Dotwork — AI-native strategy and portfolio platform* Steve Elliott on LinkedIn* The Decisive Company: How High-Performance Organizations Connect Strategy to Execution by Steve ElliottTools, Frameworks & Concepts* The Uncertainty Project — a community-driven playbook of decision-making models and techniques, co-founded by Steve* Knowledge Graphs — graph-based data structures for relating organizational concepts over time* Flexible Ontologies — adaptive data models that capture how an organization thinks and evolves* One-Way Door / Two-Way Door Decisions — framework for calibrating decision speed to reversibility* John Boyd’s OODA Loop — Observe, Orient, Decide, Act decision-making framework* Team Topologies — framework for organizing teams around cognitive load and flow (referenced by Dave)* Product Operating Model — outcome-oriented approach to organizing product development work* Event Sourcing — a software architecture pattern where system state derives from an audit trail of events (referenced by Dave)People Referenced* John Cutler — Head of Product at Dotwork, author of The Beautiful Mess newsletter* W. Edwards Deming — management theorist, referenced by Dave (”by what method”)* John Boyd — military strategist, creator of the OODA loopTopics DiscussedFrom Consulting to Serial EntrepreneurshipSteve’s career began at one of the Big Six consulting firms, where the rapid rotation through large organizations gave him a front-row seat to recurring patterns of organizational dysfunction. Working on segregation of duties in ERP systems, he kept seeing the same problems resurface year after year—and realized that issuing reports wasn’t solving anything. That frustration drove him to build software that could address these problems.Key points:* Consulting provided breadth—seeing dozens of companies’ decision-making patterns in quick succession—but delivering reports felt hollow when the same issues reappeared annually* The pivot from consulting to software was driven by wanting to help customers actually solve problems, not just document them* This pattern of seeing recurring organizational dysfunction became the throughline across multiple startupsThe Strategic Alignment ProblemThe core problem Steve keeps chasing: in large organizations, executives have strategies and teams have plans, but the connection between them is fragile and constantly breaking. Plans go stale within weeks of creation, and the people tasked with keeping everything connected—what Steve calls “human glue”—can’t scale to keep pace with organizational complexity.Key points:* Leaders can’t see what’s working in real time; teams don’t understand why their priorities keep shifting* John Cutler’s framing of “forever problems”—alignment will never be fully solved, but getting meaningfully better at it changes everything* It’s often mislabeled as a culture problem when it’s actually a visibility and structural problem* The faster organizations move (flatter structures, AI adoption, tool proliferation), the harder alignment getsThe Limits of Existing ToolsSteve offers an honest postmortem on both ends of the tooling spectrum: scrappy spreadsheet-and-slides approaches that lose memory every planning cycle, and the first generation of enterprise agility platforms that assumed too much organizational consistency. Both fail for related but different reasons.Key points:* Spreadsheets and slides are cheap but create no organizational memory—every planning cycle feels like starting from scratch* Enterprise agility tools scaled process well but couldn’t scale understanding because their data models were too rigid* The fatal flaw of first-generation platforms: assuming conformity across the organization when real orgs are dynamic and constantly reshaping themselves* Steve built and sold one of these platforms (AgileCraft to Atlassian) and learned firsthand where the approach breaks downOntologies, Knowledge Graphs, and Organizational MemoryThe technical heart of the conversation: Steve explains how flexible ontologies and knowledge graphs provide the foundation for a system that models how an organization operates—and evolves that model as the organization changes. The key concept is “durable context”—understanding not just what decision was made, but also what the world looked like when it was made.Key points:* An ontology is a shared language for how the organization thinks; a knowledge graph keeps those ideas connected over time* First-generation tools had their ontology hard-coded into a relational database—if the org didn’t match the model, the tool broke* Durable context means preserving the factors that surrounded a decision so you can compare past and present conditions meaningfully* Graph technology handles the networked nature of modern work while still supporting the hierarchies that matter (people, budgets, time)Operating Models vs. Operating SystemsA subtle but important distinction: the operating model is the idealized version of how work should flow; the operating system is what’s actually happening on the ground. Steve argues that most organizations focus on the model and neglect the system—missing opportunities to learn from how work actually moves.Key points:* Operating models are like class diagrams; operating systems are like runtime behavior with observability* The gap between model and system is where the most valuable coaching and organizational design insights live* If teams are getting better outcomes by working outside the prescribed model, that’s a signal to update the model—not enforce compliance* Being able to observe both and compare them is a genuinely new organizational capabilityDotwork’s Vision: Intelligence Without More DashboardsDotwork’s approach is deliberately different from the “log into our dashboard” paradigm. Steve describes a vision of a “dark system”—a context engine with organizational memory that surfaces relevant signals to leaders wherever they already work, without requiring them to learn yet another tool.Key points:* Rather than pulling all data into one system via heavy connectors, Dotwork uses AI to progressively retrieve just the specific metrics and signals that matter* The goal is to eliminate status meetings and planning overhead by making alignment observable and continuous* The vision: an AI that knows both you (like a personal GPT) and your organization, enabling higher-value work* Leaders consistently ask for the same thing: help me look around corners and see second-order impacts before they become expensive mistakesAI Beyond Task-Level ProductivityThe conversation closes with a broader look at where AI creates systemic value versus task-level value. Steve argues that the bottleneck isn’t AI capability, it’s organizational context. Without an ontology and memory of how the organization operates, AI agents are flying blind.Key points:* Current AI wins are mostly task-based (code generation, summarization); the bigger opportunity is system-level intelligence* For AI to do meaningful organizational work, it needs to understand who makes decisions, how they’re funded, and what’s been tried before* The missing piece: institutional knowledge and context that currently lives in people’s heads or is scattered across dozens of tools* Steve’s hope: leaders freed from status meetings and compliance toil can spend more time on strategy, experimentation, and building things that matter---Hard Boiled Software is hosted by Dave Laribee. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit newsletter.nerdnoir.com

Diana Larsen is a pioneering figure in the Agile movement who has been shaping how teams learn and work together since the late 1990s. Co-author of the foundational Agile Retrospectives (with Esther Derby) and Liftoff (with Ainsley Nies), Diana brings decades of experience helping organizations build learning cultures. Her recent work with Lead Without Blame (co-authored with Tricia Broderick) extends her focus on leadership that supports team autonomy and psychological safety.Episode DescriptionWhat does it mean to build a learning organization? Why does that matter now more than ever? In this conversation, Diana Larsen traces her journey from the earliest days of what would become the Agile movement to her current work with leaders navigating today’s complex, constantly shifting landscape.Diana shares hard-won insights on why retrospectives so often fail to deliver value (and what actually makes them work), how team chartering accelerates performance, and why the human side of software development keeps getting short-changed in favor of shiny new tools. Along the way, she introduces FAST (Fluid Adaptive Scaling Technology)—an emerging approach that synthesizes open space principles, self-selection, and dynamic reteaming into something genuinely different from the heavyweight scaling frameworks that dominate the conversation.Struggling to make your retros meaningful? Wondering how to support teams without a dedicated Scrum Master? Or just curious what someone who’s been in this game for 25+ years sees on the horizon?This episode offers both practical wisdom and the long view that only comes from sticking around long enough to see the patterns.Links & ResourcesGuest Links* Diana Larsen’s Website* Diana Larsen on LinkedIn* Team Liftoffs — Neil Taylor’s continuation of the liftoff/chartering workBooks by Diana Larsen* Agile Retrospectives: A Practical Guide for Catalyzing Team Learning and Improvement (2nd Edition) by Esther Derby, Diana Larsen & David Horowitz* Liftoff: Start and Sustain Successful Agile Teams (2nd Edition) by Diana Larsen & Ainsley Nies* Lead Without Blame: Building Resilient Learning Teams by Diana Larsen & Tricia BroderickBooks & Articles Mentioned* The Year Without Pants: WordPress.com and the Future of Work by Scott Berkun — on distributed work at Automattic/WordPress* Agile Software Development with Distributed Teams by Jutta Eckstein (2010) — early work on remote/diffuse teams* The Human Side of Enterprise by Douglas McGregor — the Theory X/Theory Y frameworkTools, Frameworks & Concepts* Self-Determination Theory — an academic framework on autonomy-supportive leadership* Open Space Technology — the meeting format that inspired elements of FAST* Dynamic Reteaming — the practice of teams reforming based on work needs* FAST Agile — Fluid Adaptive Scaling Technology, developed by Quinton (Ron) QuartelShout Outs* Esther Derby — co-author of Agile Retrospectives* Norm Kerth — retrospectives pioneer, connected to the retrospective facilitator gatherings* David Horowitz — co-author on the 2nd edition of Agile Retrospectives, CEO of Retrium* Ainsley Nies — co-author of Liftoff* Tricia Broderick — co-author of Lead Without Blame, founder of Ignite Insight + Innovation* Neil Taylor — carrying forward the Team Liftoffs work (teamliftoffs.com)* Quinton (Ron) Quartel — creator of the FAST framework* Scott Berkun — author of The Year Without Pants* Jutta Eckstein — author of an early distributed teams book* Douglas McGregor — management theorist (Theory X/Theory Y)* Matt Plavcan — Introduced Dave to Diana, making this podcast possible * Agile Open Northwest — open space conference (Portland/Seattle)Topics DiscussedThe Evolution of Agile (and Why It Keeps “Dying”)Diana offers a compelling lens on the recurring declarations that “Agile is dead”—connecting them to the diffusion of innovation curve. Each time Agile crosses from one adopter group to the next (pioneers to early adopters to majority), the previous group declares it dead because it’s necessarily changing to accommodate new contexts.Key points:* Diana entered through XP in 1997, bringing experience with cross-functional, self-organizing teams from high-tech manufacturing* Every wave of “Agile is dead” corresponds to a diffusion curve transition* The community’s strength has been its ability to learn its way through major shifts—from co-location to remote, from desktop to mobile, and now to AIWhy Retrospectives Fail (And What Actually Works)The retrospective framework from Agile Retrospectives isn’t just a meeting format—it mirrors how the human brain naturally processes decisions. When teams skip steps or reduce retros to “what went well/what didn’t” lists, they lose the collaborative thinking that drives real improvement.Key points:* The framework follows natural human cognition: attention → perception → implications → decision* “When your retrospectives go well, every other meeting in your organization goes well”* Retros that don’t affect the next iteration’s plan aren’t working—they’re building process resentment* The goal isn’t catharsis; it’s collaborative decision-making that creates buy-in along the wayTeam Chartering and LiftoffsTaking time at the beginning to establish shared purpose, working agreements, and context dramatically accelerates team performance. Diana’s work with Neil Taylor is bringing this practice into the remote-first era.Key points:* Three essential elements: purpose/vision, who’s doing the work and how, and contextual environment* The charter is “always a draft”—available for adjustment but providing a reference point* For remote teams, co-located liftoffs create lasting human connection that sustains virtual collaboration* Team chartering and retrospectives work together as a system—retro insights can update the charterThe Disappearing Agile Roles ProblemAs organizations shed Scrum Masters and Agile coaches, they often expect managers to absorb these responsibilities without developing the skills or capacity to do so well.Key points:* Many organizations hired managers for paperwork and HR compliance, not team nurturing* Lead Without Blame addresses what leaders can do to create conditions for performance without becoming full-time coaches* The human problems in organizations won’t be solved by new tools—they require developing new capabilities in people* Leaders’ plates are overflowing; burnout is the predictable resultFAST: A Different Approach to ScalingFluid Adaptive Scaling Technology combines open space, self-selection, dynamic reteaming, and XP-style small slices of work into an alternative to heavyweight scaling frameworks.Key points:* Created by Quinton (Ron) Quartel after observing open space conferences and asking, “What if we applied this to software development?”* Teams form around work on a short cadence (2-3 days to a week), demonstrate progress, then reform based on what’s needed next* Eliminates the “60% on this project, 30% on that” cognitive overhead while maintaining flexibility* Allows quick response to changing product direction without waiting for quarterly planning cyclesThe Autonomy-Supportive LeaderDiana traces a through-line from Douglas McGregor’s 1952 Theory X / Theory Y work through self-determination theory to today’s challenges. Really good leadership has looked similar for decades—we just keep defaulting back to control.Key points:* Theory Y assumes people want to do good work and will if barriers are removed; Theory X assumes they need to be pressured* Self-determination theory provides academic grounding for autonomy-supportive leadership* Diana’s current work: meeting with leadership groups to share new ideas and help reframe challenges* Focus on environments, team dynamics, and leadership as the three elements that optimize organizational capabilityThanks for listening!If this conversation resonated with you, subscribe to Hard Boiled Software wherever you get your podcasts. Follow us for more conversations with systems thinkers who care about the craft of building software.Visit the Nerd/Noir newsletter for epis… This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit newsletter.nerdnoir.com

Michael Feathers is the author of Working Effectively with Legacy Code, the de facto survival guide for developers dealing with gnarly, untested systems for nearly two decades. He’s been a thought leader in software craftsmanship, refactoring, and technical excellence throughout his career.* Working Effectively with Legacy Code — Michael’s seminal book on wrangling tougher codebases* R7K Research & Conveyance — Michael’s company specializes in software and organizational design* Michael’s LinkedIn Profile — Follow for Michael’s current events and thinkingEpisode SummaryDave and Michael have an honest conversation about what’s happening to the software profession right now. From the dopamine hit of programming to the commoditization of hard-won skills, they explore professional identity, second-order effects of AI adoption, and what remains evergreen in a rapidly shifting landscape.Topics CoveredWhere has all the dopamine gone?* Programming’s intrinsic reward loop—the rush of solving problems and getting closure through code* Whether AI usage can replicate that satisfaction* The difference between the TDD flow state and the AI-assisted workflowAvailability Bias & Path Dependency* Michael’s biggest AI concern: accepting the first generated solution without considering alternatives* Software’s deep path dependency—early decisions compound* The Starbucks analogy: do you care about coffee or caffeine? Design or delivery?Navigating Programmer Ego Death* The psychological transition as coding skills get commoditized* Reframe: loving programming means loving understanding and building systems—social, organizational, economic* Evolution from “problem solvers” to “problem articulators”Second-Order Effects of AI in Organizations* Junior dev displacement may be overstated* Dan Shipper’s model: pairing senior/junior developers with separate agents plus shared AI ops support* The real risk: generating code you don’t understand at unprecedented speed* Metrics creep—lines of code (or token usage) returning; Goodhart’s Law incomingWhat Skills Remain Evergreen* Examples over specifications—few-shot prompting works; Brian Marick’s “an example would be handy right about now”* Sidestepping problems—knowing when to abandon a dead-end approach* Value judgments in architecture—AI can’t implicitly understand context-specific values* Learning how to learn—meta-learning strategies matter more than any specific technologyThe Architecture Moat* No “GitHub for architecture”—no standardized documentation unit* Design and architecture remain more human-protected domains* Experiment: asking an LLM “how would Michael Nygaard design this system?” This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit newsletter.nerdnoir.com