Episode Description

Why 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 & Resources

Guest 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 Community

Books & 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 sourcing

Tools, 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 well

People 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 community

Topics Discussed

The ALT.NET Rebellion and Finding Your People

Adam 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 architectures

From Domain-Driven Design to Event Sourcing

The 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 models

Event Modeling: The Swiss Army Knife

Adam delivers his pitch for event modeling: a notation and process for describing information systems that looks like a sideways storyboard, captures state changes as events in plain English, and deliberately excludes implementation details. Born from the realization that his team at Adaptech was already doing something distinctive (they just thought they were doing BDD really well), event modeling was first formally written down at the Event Storming summit in 2018.

Key points:

• Event modeling uses only three moving pieces and four patterns based on two ideas; it takes minutes to explain and the rest is learned in practice

• No branching logic in workflows; the notation sticks to a storyline by example because human minds remember stories far better than they remember graphs

• The UX/UI is a first-class citizen in an event model, not an afterthought, because every system is ultimately built for human beings looking at an interface

• Event modeling functions as a blueprint comparable to architectural plans for a building: the plumber, the carpenter, and the electrician all work from the same document

The Flat Cost Curve and Why Coupling Is the Real Enemy

Adam makes a direct business case for event sourcing and event modeling: Adaptech Group offers fixed-cost contracts and fixes bugs for free. This isn’t charity; it’s a direct consequence of an architecture where new features don’t touch existing code, coupling is managed by design, and the immutable event ledger serves as the single source of truth.

Key points:

• The “hockey stick” cost curve in traditional software comes from coupling: shared canonical models, CRUD operations that affect multiple consumers, and abstractions that break everything when they change

• Event sourcing inverts this by using multiple purpose-built read models that each have exactly what they need, coordinated by an undisputed set of events

• Schema migrations effectively disappear because new versions of data and old versions coexist naturally

• The biggest conceptual barrier is the industry’s attachment to a single canonical model, an idea sold from academia through inheritance hierarchies that doesn’t mirror how real-world information systems have operated for centuries

AI as the Next Point of No Return

The conversation turns to AI, which Adam frames alongside the Commodore 64, the internet, email, Linux, and event sourcing itself as an irreversible “aha moment.” His own turning point was watching ChatGPT generate CSS animations in seconds that would have taken him three hours, and he sees event modeling as the missing link that gives AI the specification quality it needs to generate real systems.

Key points:

• AI’s impact is comparable to how Google gave us access to everything, but AI gives us the ability to make sense of everything instantly

• The bottleneck is shifting left to planning, which is exactly where event modeling lives: providing clear, structured specifications that AI can execute against

• Adam demonstrated early success pasting event model screenshots into Cursor’s chat window and getting correct unit tests and implementations on the first try, even with less capable models

• The Pandora’s box framing: you can’t uninvent the internet, and you can’t uninvent AI inference; the question is whether your specifications are good enough to benefit from it

Two Books and What’s Next

Adam closes with an update on his long-anticipated event modeling book, which is actually two books. Inspired by Eric Evans’ companion booklet to the DDD blue book and Michael Feathers’ reference-pattern format in Working Effectively with Legacy Code, Adam is releasing a concise booklet first, followed by a comprehensive reference book.

Key points:

• The booklet comes first, designed to be immediately applicable, covering why event modeling exists, its core pieces, and the rules for assembling them

• The full book will include the backstory and motivations, plus a library of reference patterns covering the top 90% of common information system scenarios (sign-up flows, payment integrations, checkout carts, pub/sub patterns, and more)

• Adam deliberately delayed the book because he never wanted event modeling to require a book to understand, a lesson drawn directly from watching the DDD book’s intimidating thickness reduce its effective adoption

• Martin Dilger’s Understanding Eventsourcing already covers event sourcing using event modeling throughout, giving the community a practical resource while the definitive event modeling book takes shape

Hard Boiled Software is hosted by Dave Laribee.

But there’s always room to grow. Even carefully designed exercises can feel generic when they don’t map to the specific people in the room or the pains they’re directly experiencing. Customization works, but it takes time and money. Tailoring scenarios to a specific industry or context could mean weeks of prep for a one-time engagement. Not feasible.

AI just blew past that ceiling. It makes it absurdly easy to build small, interactive tools that let people FAFO with ideas directly. Not slides about a concept, but a hands-on experience with the concept — tailored to a specific room’s needs, pains, industry, concerns, et. al.

Example: A Cumulative Flow Scenario Explorer

One of our go-to teaching tools is the Cumulative Flow Diagram. CFDs show you where inventory piles up and bottlenecks form in a flow of work. They’re powerful, but they can be abstract when you’re staring at a static image on a slide.

Recognizing this lameness, we built an interactive CFD scenario explorer: tools.nerdnoir.com/cumulative-flow-diagram.

Load different scenarios. Watch how bottlenecks form in real time. Create your own scenarios and see what happens. As we like to say, visuals are valuable.

It’s a playground for a concept that once lived in a lecture on a static image.

Before You Say It

I can hear an objection forming: “CFDs? Really, dude? AI agent fleets are about to crush the coding bottleneck. Do we still need to understand flow?”

The handoff-driven software engineering model is being eaten by AI. But bottlenecks shift. They don’t vanish. Understanding where inventory accumulates in your system is a first principle. That doesn’t change just because the constraint moves.

No matter how AI-augmented your shop is, value must still flow through discovery, design, validation, and delivery. This is especially true in enterprise contexts where the stakes are higher and the feedback loops are longer.

The CFD isn’t going anywhere; the bottleneck it reveals just moves upstream. So, I suggest you learn the fundamentals, but I’m betting I can help your group do that faster and more effectively.

This Is Cheap Now

This didn’t take us three months to build. It took a week.

I wouldn’t call this vibe-coded. It’s more of an agentic workflow with a human (me) all up in the loop. We’re developing more fluency and opinions on tools like Claude Code, our rig is improving, and we’ll have more to say on that soon. But it’s uncomfortable in a good way. My tried-and-true instincts keep bumping into this new architecture, and some survive, while others don’t. But the dopamine hits from learning sure are awesome.

How we built the tool isn’t the point. What matters is what you can do once building gets this cheap.

The speed matters, but the leverage comes from accelerated customization. We can develop scenarios that map to a specific industry or problem space, so people will see themselves in it. There’s a big difference between “here’s a generic example of a bottleneck” and “here’s your bottleneck, modeled from your patterns we’ve seen in your kind of work.” One gets a polite nod. The other stokes a conversation.

More to Come

We’re building more of these tools at Nerd/Noir. A broader knowledge site that compounds on these ideas is in the works. It’s not ready for wide release quite yet; I’m just teasing our new direction here.

For now, go play with the CFD explorer at tools.nerdnoir.com/cumulative-flow-diagram. Create and break some scenarios. Model your bottlenecks. Copy the markdown into the LLM of your choice and learn some more.

And let us know what you think!

/ Dave

P.S. The tools site has no tracking, no server-side storage, local only. We’re not trying to become a SaaS company, certainly not in today’s economy. We’re just in it for the learning!

Episode Description

What 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 & Resources

Guest Links

• Woody Zuill’s Website

• Woody Zuill on LinkedIn

• Software Teaming: A Mob Programming, Whole-Team Approach by Woody Zuill & Kevin Meadows

Books & 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 pattern

Tools, 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 teams

People 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 Discussed

The Art of Iterating on a Talk

Woody 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 years

From Pair Programming to Software Teaming

The 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 Teamwork

Woody 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 experience

Variations in Practice Around the World

Having conducted workshops on every continent except Antarctica, Woody has observed that people everywhere respond similarly to working as a real team—but the specific practices vary widely. Three teams at one San Francisco company each found completely different approaches to the same core idea.

Key points:

• One team used timers, one switched drivers on request (”I don’t want to type anymore”), and a third kept one driver until a discrete task was complete—all valid

• Cultural differences exist (some cultures discourage challenging your boss, others expect it), but Woody encourages teams to speak their native language while coding for clearer thinking

• Woody never intended his starting guidelines to become rules; like Ken Schwaber told his 2007 Scrum class, the framework is a starting spot, not a destination

• Ron Quartel’s FAST framework represents a compelling variation: dynamic reteaming every few days based on what the work demands

AI, Learning Debt, and the Enduring Value of Working Together

The conversation turns to AI with both curiosity and caution. Woody sees clear parallels between the navigator role in software teaming and prompting an AI — but warns that speed without understanding creates its own set of problems.

Key points:

• The navigator/driver separation in mob programming was essentially prompting before prompting existed: staying at the higher abstraction level while someone (or something) handles the details

• Fred Zuill’s description of AI as “a rather faulty, somewhat moderately skilled collaboration partner” captures the current state well

• Dave introduces the concept of “learning debt” — when AI generates code using models, libraries, and constructs that the developer doesn’t understand, creating a new and dangerous form of technical debt

• Woody references the “Big Ball of Mud” pattern: AI-generated code risks producing an instant version of the architectural mess that normally takes years to develop

• The deeper concern: teams may be getting more done, but not more of the right things done — echoing a pattern Woody has seen throughout his career

Storytelling as the Next Frontier

The episode closes with Woody’s emerging interest in storytelling workshops, inspired by watching his wife Andrea’s process as a children’s book illustrator. Her approach—drawing a character thousands of times until it becomes a living thing—mirrors the kind of deep, iterative practice that has defined Woody’s own career.

Key points:

• Andrea Zuill’s path from selling prints on Etsy to publishing children’s books began when people kept asking, “What book is that picture from?” — demand preceded supply

• Woody sees storytelling as a natural extension of his work: conference talks depend on stories, and many practitioners want to develop this skill

• Dave suggests product management as a particularly promising audience for storytelling workshops—great product managers tell stories that bring people on board with vision and customer pain

• Woody’s honest reflection on his career’s current inflection point: demand for traditional Agile training is declining, and he’s exploring what comes next while staying true to what he cares about

Hard Boiled Software is hosted by Dave Laribee.

Every time another viral piece of content about AI destroying the workforce makes the rounds, I feel a small knot in my stomach.

I have a daughter who will enter the workforce in the 2030s. And I would like to retire sometime around 2040.

Those timelines make the current wave of AI predictions feel a little more personal.

Some of the essays circulating right now paint a bleak picture of the next few years. Entire professions disappearing. Corporations run by autonomous agents. Office work collapsing within a decade.

One dystopian scenario, 2028, imagines a wave of AI-driven unemployment sweeping across the global economy. The piece clearly struck a nerve, collecting nearly 8,000 likes on Substack. Andrew Yang has made a similar argument, suggesting that advances in artificial intelligence could ultimately bring about the collapse of traditional office work.

These are serious arguments, and hard to dismiss because they seem so damn plausible.

But the more I look at the research from organizational science and knowledge management, and reflect on my own hard-earned experience in the corporate trenches, the more I think these predictions share a hidden assumption that doesn’t hold up in the real world.

They assume knowledge work is mostly explicit and codified. Decades of organizational research show that much of the knowledge inside companies is tacit, experiential, and socially learned. That makes established organizations far harder to “agentify” than current forecasts assume. Not permanently harder. But harder in ways that stretch the disruption timeline well beyond what anyone is currently selling.

Agents Can’t Read Minds

One of the foundational ideas in knowledge management comes from philosopher and scientist Michael Polanyi.

His most famous line is just seven words:

“We know more than we can tell.” (Polanyi)

Polanyi was describing what researchers now call tacit knowledge: knowledge that is non-verbalized, intuitive, and difficult to codify.

Examples are everywhere once you start noticing them.

• An engineer recognizing that a design will create operational problems later, even though the code technically matches the spec today.

• A leader sensing the political dynamics inside a meeting.

• A customer support person recognizing that a frustrated caller does not actually need more troubleshooting steps, but reassurance, empathy, and someone willing to go off script.

A fair objection here is that modern AI systems don’t learn only from written text. Reinforcement learning, agent-based simulation, and feedback loops allow AI to acquire something closer to experiential knowledge. But even granting that, it addresses only part of the problem. The deeper barrier isn’t whether AI can develop judgment in isolation. It’s whether that judgment can operate inside organizations that are fundamentally social and political structures, built on trust, reputation, and unwritten rules accumulated over many years.

Organizations Are Messy Human Systems

Political scientist Herbert Simon observed that organizations operate under bounded rationality: decisions emerge through negotiation, incomplete information, and institutional constraints. That framing raises uncomfortable questions for anyone betting on a near-term agentic AI revolution.

Consider IBM’s rollout of Watson Health. IBM invested heavily in the premise that AI could transform clinical decision-making, a domain rich in explicit data. What they encountered instead was a system that struggled to navigate the informal knowledge structures of actual hospital environments: physician hierarchies, institutional politics, and the kind of contextual judgment that experienced clinicians build over years. By 2021, IBM was selling off the unit at a significant loss. The technology wasn’t the limiting factor. The organizational environment was.

That story isn’t an anomaly. It’s a preview of the challenges that await any aggressive attempt to automate knowledge work inside established organizations.

The unwritten rules. The quiet etiquette that everyone knows but no one says. When to escalate. When to let something slide. These are not technical problems. They are social ones.

We’ve Seen This Movie Before

Technological revolutions often go through a phase where investment runs well ahead of real adoption.

During the late 1990s dot-com boom, telecommunications companies spent more than $500 billion ($1 trillion in today’s dollars) building fiber-optic infrastructure based largely on projections about future internet traffic. Much of it sat unused. The industry coined a term for it: dark fiber.

The internet did eventually grow into that infrastructure and restructure enormous parts of the economy. But it took nearly two decades. And most workers who were mid-career when Netscape launched in 1994 retired with their careers largely intact.

The current AI boom shows similar dynamics. Technology companies are investing massive sums into GPUs, data centers, and energy infrastructure, through partnerships involving Microsoft, OpenAI, NVIDIA, Meta, and others, justified largely by projections about future demand rather than current productivity gains. That’s partly a bet on the future. But it’s also worth noting who is placing the bet. If you sell chips, cloud infrastructure, or AI tools, the story that AI will soon transform the entire economy is an extraordinarily convenient one.

What makes AI particularly good at fueling these narratives is that it’s impressive enough to spark the imagination, but ambiguous enough that its limits are hard to challenge. Dark fiber, at least, was just fiber. You could see it sitting unused. AI’s unrealized potential is much easier to keep selling.

Some Organizations Will Agentify Soon

Where AI may reshape organizations most dramatically is in companies that don’t exist yet, or are in very early stages. This is worth taking seriously because it’s where the more credible version of the disruption argument lives.

Startups have no years of accumulated tacit knowledge to untangle, no legacy systems, no cultural dynamics, no undocumented workarounds baked into muscle memory. They can design everything around agents from the beginning. AI-native organizations will likely be very flat: a handful of humans providing oversight and judgment while agents handle much of the execution underneath.

The concern this raises is real. If AI-native startups outcompete established organizations, jobs don’t disappear from within companies so much as the companies themselves lose ground. That is still disruptive.

But that process unfolds over decades of market share erosion, investment cycles, and organizational turnover. It is not a year- or two-out displacement event. It looks more like the slow replacement of department stores by e-commerce than a wave crashing over the economy all at once.

Established companies will adapt too, but incrementally, and with far more humans-in-the-loop than the more dramatic forecasts suggest.

In The End

The continued importance of humans in organizations is not wishful thinking. It is grounded in decades of research (and reality) on how organizations actually work, how knowledge actually moves, and how slowly even well-resourced organizations change.

The gap between what AI can do in a demo and what it can do inside a messy, politically complicated, legacy-laden organization is real and large. That gap will close. Gradually. Unevenly. With false starts, “dark fiber” moments, and bold predictions that age poorly.

By the time my daughter enters the workforce in the 2030s, AI agents will likely be part of her daily working environment. They may handle significant portions of tasks that humans perform today. But the organizations she joins will still be built around human judgment, human politics, and human relationships, because that is what organizations have always required, and the research gives us little reason to think that changes quickly.

The disruption is coming. Maybe it’s more turtle than hare.

Steve 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 Overview

Why 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.

Links & Resources

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 Elliott

Tools, 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 loop

Topics Discussed

From Consulting to Serial Entrepreneurship

Steve’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 startups

The Strategic Alignment Problem

The 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 gets

The Limits of Existing Tools

Steve 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 down

Ontologies, Knowledge Graphs, and Organizational Memory

The 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 Systems

A 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 capability

Dotwork’s Vision: Intelligence Without More Dashboards

Dotwork’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 mistakes

AI Beyond Task-Level Productivity

The 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.

Episode Description

What 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 & Resources

Guest Links

• Diana Larsen’s Website

• Diana Larsen on LinkedIn

• Team Liftoffs — Neil Taylor’s continuation of the liftoff/chartering work

Books 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 Broderick

Books & 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 framework

Tools, 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) Quartel

Shout 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 Discussed

The 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 AI

Why 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 way

Team Chartering and Liftoffs

Taking 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 charter

The Disappearing Agile Roles Problem

As 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 result

FAST: A Different Approach to Scaling

Fluid 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 cycles

The Autonomy-Supportive Leader

Diana 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 capability

Thanks 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 episode archives, show notes, and more explorations at the intersection of technology and the human condition.

They’re usually not.

Why?

Documentation fails for structural reasons. Shipping is visible and rewarded. Maintenance is quiet and thankless. Without enforcement, documentation updates are always optional, and optional work reliably loses.

The cost isn’t immediate. It surfaces later as slow onboarding, broken runbooks, support escalations, and repeated “How does this actually work?” conversations. By the time anyone notices, the gap between how the system works and how it’s described has already grown expensive to close.

Introducing Doc-Drift

If documentation drift is inevitable without enforcement, the fix has to live where enforcement already happens: the pull request. I built a project called Doc-Drift.

On every pull request, it compares the proposed code changes with the documentation and flags cases where the documentation now contradicts the code. Not hypothetically. Not stylistically. Only when a specific claim in the docs is no longer true, given the change being made.

That framing matters. Most documentation isn’t abstract guidance. It makes concrete claims: which commands exist, which endpoints are available, and which libraries are in use. Those claims are tightly coupled to the code, but we rarely verify that coupling when the code changes.

Doc-Drift treats documentation as a set of assertions that can be checked at the same time the system itself is under review. Instead of asking humans to remember to update docs, it turns documentation drift into a concrete, reviewable signal at pull-request time.

How it works

Essentially, I wired up a GitHub Action that does three things:

1. Reads the pull request diff

2. Checks those changes against documentation sources (e.g., a “docs” folder or an external URL to a document repository)

3. If drift exists, a Doc-Drift report is created and posted as a PR comment

Here’s the mental model:

Here’s the most important constraint: the system is not allowed to guess.

No, “This might need review.”

If it can’t point to a specific code change and a specific piece of documentation that now conflicts with it, it stays silent.

This is a deliberate tradeoff. The system catches specific contradictions, not conceptual drift. It won’t notice a README that omits a new responsibility or guidance that’s become misleading without being false. I chose that constraint because LLMs confabulate, and a noisy tool is worse than no tool.

In other words, Doc-Drift is a starting point, not a complete solution. It catches obvious contradictions; subtler drift still requires human judgment.

See the full prompt.

False positives and cost

In practice, false positives in Doc-Drift have been rare. Maybe one in every dozen findings needs to be dismissed. On cost: I’m using GPT-4o-mini, which keeps things cheap. A typical PR with a moderately sized docs folder runs a fraction of a cent. Enough to leave running on every PR without thinking about it.

To gut-check this, I looked at my actual OpenAI usage data while testing Doc-Drift across many pull requests. The total spend reported was a whopping $0.03.

More expensive models and larger enterprise setups will cost more, but sub-cent checks at this baseline ain’t bad.

Context window limits

GPT-4o-mini has a 128k context window, which comfortably handles most documentation cases. For larger repositories, the action chunks documentation into smaller slices to stay within limits.

Chunking introduces an obvious risk: missing context or drawing incorrect conclusions from partial information. Doc-Drift avoids this by grounding every finding in quoted evidence from the same chunk being evaluated.

Findings

After experimenting with toy repos, I turned to Bulletproof React, a decently complex codebase with over 3,000 forks, extensive documentation, and non-trivial dependencies.

Test 1: Remove a dependency

I was happy to see that removing the dependency @tanstack/react-query (line 29) in package.json surfaced a reference in the performance doc.

The conflict surfaces verbatim as: “It is possible to prefetch data before the user navigates to a page. This can be done by using the queryClient.prefetchQuery method from the @tanstack/react-query library.” Without catching this drift, this guidance becomes useless the moment the PR merges. Worse, the build would likely break, or someone down the road might reintroduce the dependency without understanding why it was removed.

The suggested rewording seems weak: merely replacing @tanstack/react-query with “from a suitable data-fetching library.” I didn’t provide a replacement dependency in the PR, so maybe this is as good as we can expect. Hey, at least it doesn’t hit us with verbose best-practice nonsense.

Test 2: Rename an endpoint

Renaming an endpoint in get-teams.ts (line 8) from /teams to /groups surfaced documentation drift in the project structure file. In this case, the LLM did a solid job, providing a clear impact statement and a suggested rewording that is about as good as you can reasonably expect.

Test 3: Revise the startup command

I intentionally broke a startup command to see whether it was documented. In most projects, startup scripts usually are. The change itself was trivial: a single update to the Vite script (line 7):

"dev": "vite"  →  "start": "vite"

The Doc-Drift report flagged roughly half a dozen documentation files, including Application Overview, Project Standards, State Management, and Testing, all of which still instruct readers to run npm run dev even though that command no longer exists. Once this change merges, each of those instructions becomes a dead end.

Where this could go

Missing Documentation

PR-time drift detection helps keep existing documentation honest. But it doesn’t answer: Where would new documentation add value?

Examples:

• A new microservice with no README.

• A new feature flag with no explanation of safety or removal.

• A UI flow change that leaves the knowledge base pointing users to the wrong steps.

Once you start treating documentation as something that’s checked continuously rather than remembered occasionally, other LLM use cases come into focus.

Code Standards

The same PR-time feedback loop that catches documentation drift can also ask a nearby question:

Does this code change still reflect the standards we say we follow?

Most teams already have these written down somewhere:

• architectural principles

• design patterns

• testing standards

• secure coding guidelines

• naming conventions

The opportunity is that code standards are rarely checked at the moment change happens, when the cost of feedback is lowest.

The question shifts from a post-hoc critique to a real-time prompt:

• Has this part of the system evolved without explanation?

• Does this change contradict how we say we build software here?

Final thought

Documentation will always lag behind the code. The question is by how much, and whether anyone notices before it gets too bad. Doc-Drift won’t close that gap entirely. But it shortens it automatically, on every PR. That’s a starting point worth having.

Try it yourself: Doc-Drift GitHub

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 thinking

Episode Summary

Dave 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 Covered

Where 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 workflow

Availability 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 incoming

What 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 technology

The 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?”

I didn’t have much luck with email tools. Most couldn’t cut through the noise or were pricey. Gemini’s built-in summaries were weak and required hands-on refinement. I needed something sharper, like an email equivalent of Geoffrey from The Fresh Prince of Bel-Air, an assistant who would do much more than summarize.

So, in true 2025 fashion, I asked ChatGPT for help. An hour later, the problem was solved.

An Email Assistant is Born

Here’s how it works:

• Google Apps Script scans unread emails from my curated sender list

• Sends content to GPT‑4o‑mini (strong performance at low cost)

• Returns clean bulleted summaries, tailored insights, subtle market signs to watch out for—no fluff

• Sends a polished digest to my inbox twice daily

Here’s the structure for each summarized email:

• Subject: [Email Subject Here]

• From: [Sender Name or Address]

• Summary:

  • Insight 1 – Quick, key detail

  • Insight 2 – What matters most

  • Insight 3 – Implication or takeaway

• Watch Outs:

  • Potential risk or trend – What to flag

  • Interesting connection – A signal worth noticing

• Link: [Clickable link to open the thread]

Since using my humble email assistant, I begin each day with a couple of emails—usually the important ones, such as school notices or bank alerts—that no longer get buried in my inbox.

Do I miss the polished graphics and immersive layouts? Yes, that is part of the tradeoff. But I don’t miss the scrolling, the weight of dread, or the anxiety of FOMO.

Yep, it’s 7¢

That’s seven cents over thirty-seven days or about the cost of a US postage stamp for a year’s worth of email wrangling. Even a piggy bank could handle that.

Here’s why it’s so cheap — Model selection matters:

• GPT‑4o‑mini was chosen for best cost‑performance, priced at $0.15 per million input tokens and $0.60 per million output tokens.

It gets better: OpenAI’s prompt caching automatically “remembers” the part of my request that remains the same, such as the summary instructions I always use. That means most of my input tokens get billed at the discounted $0.075/M rate instead of $0.15/M, cutting costs without extra work.

Let’s break it down:
297K input tokens across 198 calls

• ~200K cached input → negligible cost

• ~97K fresh input → ~$0.015

• ~40K summary output → ~$0.055

• Total ≈ $0.07

What started as a way to escape unread dread has become a reminder that thoughtful applications of AI can support us in meaningful ways, helping us reclaim focus, skip the clutter, and stay tuned into what matters. That’s how AI helps humanity, by giving us back space to be human.

New Era: Builders, Not Buyers

We may be entering a new era where everyday technologists stop asking “Which subscription do I buy?” and start asking “What can I build next?” Tiny, composable AI tools—scripts, snippets, agents—replace the need for yet another $20‑a‑month app. You design, you own, you iterate. That is a different kind of economy, and arguably a different kind of internet.

Build Your Email Assistant

If you’re interested in building your email assistant, check out my GitHub for the full script and step-by-step guide. Also, feel free to reach out if you’d like to dig in more.

Now, as AI tools and techniques proliferate and teams shrink to three-person units of product engineers managing a fleet of agents, I'm watching that belief get stress-tested in real time. We're not just changing how teams work. We're accidentally dismantling what makes teams work at all.

Teams Are Systems

A team is not simply a collection of people sharing proximity on an org chart. That’s a workgroup or a department, but it's not a team.

A team is a system made up of people. Dr. Russell Ackoff said it best:

A system is never the sum of its parts; it's the product of their interaction. The performance of a system doesn't depend on how the parts perform taken separately, it depends on how they perform together – how they interact, not on how they act, taken separately.

A good team is like Voltron: the parts come together to form a greater whole. There’s even a German word for this concept: Gestalt.

In other words, we produce better results together.

I’ve built my entire career in software development around this belief.

Effective Teams: Small & Capable

What are the systemic properties that make some teams extremely productive?

They possess all the capabilities necessary to produce value. The Agile movement converged on a nice definition of team: groups of cross-functional people aligned on delivering value.

They’re small. Amazon's management culture defined "two pizza teams"—small teams whose catering order could be satisfied by two pizzas. Size matters when it comes to teams because we're trying to reduce the number of communication paths.

And when small, cross-functional teams rigorously manage their work-in-progress, prioritize learning, and focus on meaningful outcomes? They can produce an outsized impact.

My Gold Standard

My gold standard for teaming comes from what we did at VersionOne a decade or so ago: a product manager, a floating designer, and a pair or two of engineers working closely together.

Our teams also had a versatile tester role. These people curated various automated testing suites while helping the rest of the team frame their work in testable specifications. The term “tester” undersells their contribution. They were detail-oriented product people, on hand to collaborate with developers while freeing up product managers to get out of the building and talk with customers.

Our teams were also super capable. They could, for example, adapt their workflow in near real-time to suit the feature they were working on. One quarter, a team would use a kanban-like process being fed by a detective board maintained by their designers. In the next quarter, they’d switch to ticket-based development using GitHub issues. Their workflow served their mission, and the mission was never the process itself.

Context matters here. We worked in a collective ownership model. We had only one main product, a couple of small sidecar products, and a significant number of integrations. However, with 5-6 teams, we were able to deliver substantial value to our customers quickly by working in an ultra-collaborative manner.

Nostalgia is a hell of a drug, but given a similar set of circumstances, this will always be the gold standard for me.

Who needs a team when you have Jira?

Along with the many positive aspects of the Agile and DevOps movements came a commercial gold rush in tooling, and with that, we lost some of the principled approaches we found in eXtreme Programming and DevOps culture. And, yes, I’m aware that VersionOne, as an agile tracking tool, had a part in this.

It became common for me to work with groups that focused on tooling and tickets rather than customers, users, and their unmet needs.

Unfortunately, every good idea eventually gets twisted by monetization. “Ride the wave,” conventional wisdom tells us. For DevOps, it was tool mania. For Agile, it was an overindexing on process, certification, and tracking tools. As for AI? This movement requires vast capital expenditure, so monetization is built in from the start.

One shouldn’t entirely blame these revolutions. They still produce a lot of good. Still, each wave of innovation took its shot at teamwork, promising tools that would shuttle issues to engineers, measuring them as replaceable parts. By default, vendor tools appear to be winning over the principled style of work that once held teams together as the indivisible unit of performance.

The Individual vs. The Collective

In the GenAI era, some teams are getting extremely small. One pizza team! Three slice team!

Solopreneurs are the future! The sole founder unicorn startup! Today’s zeitgeist bends toward certain stock characters: the rugged individual and the eccentric genius. Ayn Rand would be proud.

This kind of talk is the trade of startup hustle culture. It’s a cool idea on the surface. New tools and techniques are certainly empowering smaller outfits to have outsized productivity and reduced development costs.

While these trends are most visible in startup or B2C contexts rather than big enterprises, it's not hard to see the writing on the wall: team sizes are shrinking.

We're seeing this new role (which isn't new at all) called the "product engineer." This is an exceptionally versatile person who can do everything a product manager can do, everything a designer can do, and everything an engineer can do, with the caveat that they're heavily augmented by AI tooling.

Hmm… Where have we heard this before? Full-stack developers, of course!

Embracing New Forms of Collaboration

A more optimistic view is that we’re converging toward small, 3-5 person teams where everyone has a strong foundation in product mindset and reflexive skills that enable rapid exploration and experimentation in parallel. Smaller, faster, better.

The nature of work itself is changing in ways that necessitate a reevaluation of what collaboration entails.

Here’s one scenario: as AI tools become more prevalent in software engineering and product development, the interactions between engineering teammates may begin to approach what Toyota calls Yokoten, which means “the horizontal deployment or lateral sharing of best practices.”

Yokoten isn't your typical corporate "best practices" initiative where someone creates a wiki that nobody reads. It's an active, intentional practice of:

• Spotting improvements worth spreading - Not every local solution deserves global deployment, but the good ones shouldn't stay hidden.

• Adapting, not copying - Smart teams don't just copy-paste solutions. They understand the principles and adapt them to their context.

• Benefiting from feedback loops - When Team A shares a new prompting with Team B, Team B's usage might improve the original solution or make it more generalizable.

Suppose each engineer is managing a fleet of AI agents, iterating on prompts and evaluations. That’s full-stack, at least in the application layer of AI Engineering. Here, collaboration becomes less about dividing tasks among people with different yet complementary skills and more about sharing our insights around achieving results.

Subscribe now

In this near future, teams may resemble communities of practice. Instead of a product manager, designer, and engineer each owning their functional skill set, you might have three people who are all wielding similar AI-augmented capabilities but bringing different perspectives to how they prompt, validate, and iterate. The collaboration occurs at a meta-cognitive level—how do we improve our ability to work with these tools together?

Wither teaming?

Does this mean the concept of teams is headed toward an extinction event?

I don’t think so. Here’s why:

1. Humans are still the best LLM. Despite all the advances in AI, humans bring context, intuition, and judgment that no tool can replicate. We understand nuance, navigate ambiguity, and make connections that stochastic algorithms cannot, especially when we’re building for our species.

2. Collective wisdom rejects bad ideas. Having someone to bounce ideas off generally helps reject bad ideas. Sure, this can create either “naysaying” or “egging on” conditions, but tapping into collective wisdom is invaluable. The best ideas survive scrutiny. The not-so-great ones get chalked up to learning, rejected before they waste too much time.

3. Teams create accountability networks. If I say I'm going to do something to the people I work closely with, I'm more likely to do it. I've put that commitment external to myself, and that social contract matters. It’s how we evaluate the reliability of our teammates.

4. Complex systems require some degree of specialization. As Robert Heinlein said, "specialization is for insects," but in larger, more complex systems, you need elements like human resilience and risk management to mitigate knowledge silos. Teams are the most effective means to these ends.

5. Progression happens around other people. Teams and community can provide access to aspirational people who challenge you to elevate your game. I learn a lot from reading and through solo trial and error, but my most profound learnings have come from working closely with people who were masterful or virtuosic in a skill I envied.

Teaming Evolution, Not Extinction

What we're witnessing isn't the death of teams, it's their evolution. For a teaming nerd like me, that's something to be excited about.

The dinosaurs of team structure—sequential handoffs, rigid role definitions, process-heavy coordination—are indeed facing extinction. Good riddance! The core principle that diverse perspectives and skills can create something greater than the sum of their parts? That's the mammal that survives the meteor.

Tomorrow's teams will likely be smaller, more fluid, and AI-reflexive. They might form and dissolve more rapidly in response to specific needs rather than as permanent structures. We could certainly improve in that area as an industry. But they'll still be teams because the fundamental challenges of building great products (understanding users, navigating complexity, maintaining quality while moving quickly) remain greater than any individual can overcome alone.

The value of human collaboration extends beyond task division and specialized skills. It's about collective judgment, accountability networks, the spark of unexpected connections, and the resilience that comes from shared purpose. These qualities remain relevant even in the wake of technological advancements. They become even more essential as we navigate increasingly complex systems.

Whether we call it Yokoten, Gestalt, or good old-fashioned collaboration, we're still talking about humans creating better outcomes together than they could achieve alone or paired with the most advanced neural network. The mechanics will and should evolve, but the principle remains rock solid: we produce better results together.

That's not nostalgia talking. It's systems thinking shouting from the mountain. And until someone invents an AI that can simultaneously replace human taste, judgment, collaboration, and accountability without posing an existential threat, I'll continue to bet on teams, however they might take shape in the years ahead.

Share

"Busy is the new stupid." I don't know who said it first (some attribute it to Warren Buffett, others to Bill Gates), but whoever coined it nailed something essential about our current moment.

At Nerd/Noir, we're seeing a troubling pattern. Leaders hire us to help with critical initiatives (product transformations, developer experience improvements, organizational design), then struggle to find time to engage with the work they've commissioned. We're not just competing with other consultancies for mindshare. We're competing with the “tyranny of the urgent” for basic attention.

This isn't a humble brag about our calendar-booking prowess. It's a warning sign about how "busy" has become the archenemy of progress.

The Attention Economy War

We're living in an attention economy where everyone is fighting for the same scarce resource: your focus.

Your phone buzzes with notifications designed by teams of behavioral psychologists. Your calendar fills with meetings that could have been handled via email. Your Slack threads multiply like digital weeds, each demanding immediate response.

This isn't an accident. It's by design. Every app, every platform, every business partner is optimizing for engagement, for mindshare, for that precious slice of your sweet, sweet cognitive bandwidth.

And the result? We're all drowning in a sea of artificial urgency, mistaking the volume of inputs for the quality of outputs.

The Busy Trap

Here's what we're witnessing: senior leaders champion an initiative, allocate a budget, kick off the work, and then promptly disappear into a vortex of meetings, firefighting, and reactive work. Three months later, they surface, wondering why the change isn't happening faster.

Sound familiar? From which side?

The problem isn't that these leaders don't care. They're drowning in a culture that mistakes motion for progress, confusing being busy with being productive. Every slot on the calendar feels urgent. Every Slack notification demands immediate attention. Every fire needs to be extinguished personally.

But busy isn't a strategy. Quite the opposite, it's an abdication of strategic thinking.

The Hidden Costs of Perpetual Motion

When leaders are too busy to engage with their own strategic initiatives, several things happen:

First, the work loses its champion. Without ongoing leadership visibility and decision-making, teams diverge, operating on outdated assumptions. Progress slows. Momentum dies.

Second, you send a signal to your organization about what actually matters. If the sponsor can't make time for strategic work, why should anyone else? Your teams start treating the initiative like just another thing on the pile rather than a priority that could transform their work.

Third, you miss the iterative refinement that makes change stick. Strategy isn't something you set and forget. It's something you adapt based on learning. But adaptation requires attention, and attention demands time.

Working Within Reality: Concentrated Collaboration

Recognizing this attention crisis, we've had to rethink how we design our engagements at Nerd/Noir. We've stopped pretending that people have unlimited time for synchronous collaboration. In 2025, I’d go so far as to classify that notion as a Pollyannaish fantasy. It ain’t gonna happen.

Instead, we've redesigned our workshops around a simple principle: attention is precious, so let's make the most of it when we have it.

We've dramatically reduced the number of hours that depend on everyone being in the same room (physical or virtual) at the same time. Instead, we've created rich resources that allow people to engage with the content on their schedule. Pre-work materials, guided exercises, and even AI-powered thought partners that help people work through the concepts before we come together.

When we do gather synchronously, we're not starting from zero. People arrive prepared, having already grappled with the content. Our collaboration time becomes focused on synthesis, decision-making, and resolving tensions, rather than simply transferring basic information.

Let's face facts. These days, people are likely to engage with an LLM anyway to help them process complex concepts. Rather than fight this reality, we're embracing it. We create resources designed to work well with AI assistance, helping busy leaders get up to speed quickly.

The result? Our synchronous time becomes incredibly productive because we're not competing with the urgent—we're making space for the important work that only happens when smart people think together.

The Paradox of Strategic Leadership

Back to you, leaders.

Here’s an uncomfortable truth: the more senior you become, the more your job is about choosing what not to do. Your calendar will expand to fill every available moment unless you actively resist.

I recently facilitated a strategy session where I observed a senior leader multitasking throughout the entire call. This happens all the time. Eyes darting between screens, typing responses to Slack messages, answering emails, and clutching smartphones… do you realize we can see you? All of this was happening while we were discussing a multi-million dollar transformation initiative. When asked for input, there'd be a pause, followed by "Sorry, can you repeat that?"

This leader probably thought they were being efficient by staying on top of multiple urgent matters while participating in our discussion. But how much situational awareness can you gain when your attention is on spinning five or six different plates? The quality of their understanding, their ability to synthesize information, their capacity to make informed decisions?! These are all compromised by the illusion of multitasking productivity.

I remember working with a CPO who constantly complained about not having enough time for strategic work. When we asked about her calendar, we discovered she was attending every product demo, every retrospective, and every planning session across her organization. She was drowning in the tactical while her strategic responsibilities went unmet. Throwing strategy into the multi-tasking hopper is a bad, bad idea.

The fix wasn't time management. It was about learning to delegate, trusting her team, and protecting time for the thinking work or being present for the deep collaborations that only she could do.

Breaking the Busy Cycle

So, how do you escape the busy trap?

Start with the diagnosis. Track your time spent for a week. Not how you think you spend it, but how you actually spend it. The data might surprise you. How much time goes to genuine strategic work versus reactive busywork?

Design enabling constraints. Block time for strategic work and treat it like any other important meeting. Turn off notifications. Close your email. Create the conditions for deep work to happen.

Practice strategic delegation. Ask yourself: "Am I the only person who can do this, or am I the only person who currently knows how?" If it's the latter, teach someone else. These delegation motions also help you build trust within your team and assess their performance and engagement.

Measure outcomes, not activities. The tricky bit about switching to an outcome-first model is that time utilization ceases to be a valuable metric. Make your experiments efficient, but they must be effective first. Stop celebrating how many meetings you attended or emails you answered. Start measuring progress on the things that matter: initiatives that will define your organization's future impact.

Learn to say, “No.” This is the hardest tactic for most leaders people to master. Every request feels important when it lands on your desk. But saying yes to everything is saying no to your strategic priorities. Practice these responses: "I can't take this on right now, but let me suggest someone who can." Or: "This sounds important. Help me understand how it relates to our Q1 priorities." Or simply: "I'm going to pass on this one." The key is to offer alternatives when possible and be direct when not.

Embrace Strategic Boredom

As a leader myself, I prioritize creating unstructured time in my schedule for deep thinking, observation, and connecting ideas. Experience has shown me that my most valuable contributions often come from "doing nothing" (or at least that’s what it must look like to others). Quiet moments of strategic reflection can lead to breakthrough insights and better decisions.

This isn't about working less. It's about working on the right things. The urgent will always be with us, but as for the important? The critical stuff requires protection. Guard it jealously.

If you're too busy to engage with your strategic initiatives, you're not being productive. You're being reactive. And in a world that rewards thoughtful action over frantic motion, that's not just inefficient, it's stupid.

What signal are you sending?

Take a hard look at your calendar this week. What signal are you sending about what matters to you? Are you creating space for the work that will define your organization's future, or are you drowning in the urgent at the expense of the important?

The choice is yours. Being busy isn't a badge of honor. It's often a sign that you're not in control of your priorities (the one thing you ought to be able to control). Remember: your people can see that, and you set the tone for that culture.

So ask yourself: what kind of leadership behaviors do I want to model? Stupidly busy or intelligently engaged?

But it’s also where things get complicated.

We’re in a moment where the ability to ship software has been radically democratized. With LLMs, people can generate full apps with minimal technical background. Just like how Home Depot once freed homeowners from dependency on professional tradespeople, AI now empowers non-engineers to bring their ideas to life.

It’s exhilarating, it’s game-changing, and like many DIY endeavors, it can get dangerous.

Back in the day, Home Depot gave me the confidence to replace a light fixture. Then YouTube gave me the step-by-step instructions to build a custom floor-to-ceiling bookcase. Despite my Bob Villa moments, I still don’t mess with high-risk projects like gas lines and structural repairs. That’s how I think about LLMs. They enable velocity and participation, but they don’t replace wisdom or safety.

Vibe coding often gets mocked, and let’s be honest—a lot of it is warranted. But here’s what makes me uncomfortable: the smugness from some seasoned engineers, acting like LLM-driven code is inherently flawed just because it wasn’t human-written.

Let me challenge that because LLM-driven code is here to stay in some shape or form, and mocking it is not a productive use of our energy.

Years ago, I led a team of a dozen sharp, formidable engineers. Alas, we missed an obvious HIPAA compliance issue that cost us dearly—fines, war rooms, loss of trust, etc. It was so bad that it’s my go-to answer when an interviewer asks me: “When have you failed?”

Would an LLM have caught it? Maybe. Maybe not. But I can’t say with certainty it would’ve done worse.

Engineering Without Engineers

Today, companies are laying off engineers by the thousands. Microsoft, Google, Salesforce, Meta—all pivoting to “AI-first.” The narrative isn’t cost-cutting. It’s “alignment with exponential opportunity”.

But, at what cost?

Evan Armstrong puts it bluntly:

“If we aren’t careful, the cutthroat nature of startup development will mean the most popular uses of the tech won’t benefit humanity. They’ll just benefit shareholders.”

Mark Zuckerberg takes it a step further, saying AI will replace much of the work done by mid-level engineers.

“AI will let us build better products faster — and also eliminate some of the work that mid-level engineers do today.”

It might sound like a Silicon Valley fever dream—but there’s research to back it up.

In 2023, researchers released SWE-bench, a benchmark that tests whether LLMs can fix software bugs in real GitHub repos. Turns out, they can. Models like GPT-4 and Claude are already holding their own—and getting better with every release—solving issues that used to require human intervention.

Hidden Costs of Vibe Coding

We need to talk more about David Laribee’s concept of "learning debt." It’s the invisible tax we pay when engineers skip the long road of craftsmanship and go straight to generating outputs with LLMs.

“When you rely too heavily on AI to generate code without understanding the fundamentals, you borrow against your future competence.”

Vibe coding is powerful, but it flattens the feedback loop. Engineers don’t sharpen instincts. They offload decisions. Instead of learning to engineer systems, they assemble artifacts.

Here’s one of many cautionary tales that made the rounds:

This isn’t about intelligence—it’s about exposure and tacit knowledge. If you've never been burned by a rollback, how would you know to fear it? That’s learning debt.

Plot Twist: Where the New Value Lies

This chaotic moment could become a major advantage for the engineers who choose to stick around.

When the dust settles, the companies that move fast without thinking will suffer. And who will they call? The engineers who understand systems, scale, safety, and sound architecture.

Here are opportunities for engineers to earn job security and great pay:

• Engineers who can fix vibe coding or agentic coding mistakes as "firefighters."

• Those who can coach others on software craft as mentors and multipliers.

• Employing AI for the boring tasks—documentation, package management, and boilerplate code, freeing engineers to focus on meaty, meaningful work: architecture, resilience, edge cases, entropy, and innovation.

Vibe coding isn’t the end of engineering. It’s the re-leveling of it.

Just like automation reshaped manufacturing, I believe vibe coding will ultimately elevate the engineering profession, turning engineers into curators of quality, arbiters of context, and defenders of craft. That’s not just good for software—it’s great for engineers' growth (and salary).

AI won’t replace engineers. But it will replace engineers who refuse to evolve.

Remember: you can install a ceiling fan, but if your home’s foundation cracks, you'd better call someone who knows what they’re doing.

I was building a voice transcript anonymizer in Python, riding the Cursor and Claude 3.7 Sonnet melt. The flow was smooth. The code was crushing. The stoke was real.

Things started feeling strange as the agent pulled down increasingly complex models from Hugging Face—a named entity recognition model and a similarity detection one. Suddenly, my models had models, and I was LARPing as a computational linguistics expert.

Then I ran my program.

The results were... perplexing. My transcripts weren't being anonymized correctly at all. Something was off, but all those fancy ML models should work, right?

I tried the vibe coder’s way, repeatedly barking, “FIX IT!” It didn’t fix it. I kept getting the same trash output.

Forget it, Donny, you’re out of your element!

I vibed so hard I hadn't noticed we'd drifted far beyond my understanding of the problem I was trying to solve. I became a tourist on a programming trip, not the guide.

Thankfully, I had the good habit of making frequent, small commits. I rolled back to a previous version and took a different approach. I broke out of vibe mode and gave more explicit directions to use simple regex patterns and a deterministic similarity algorithm. These were techniques I understood at least well enough to prompt small and successfully.

The more straightforward solution worked adequately. More importantly, I could read, explain, and modify the code.

That moment of realization—when you notice you're getting way over your skis with AI—prompted me to write this article. The experience crystallized something I've been thinking about for a while now: the concept of learning debt.

Learning Debt

Learning debt is conceptually similar to technical debt.1 The accumulated costs of taking shortcuts in your learning journey will eventually need to be repaid, often with interest. And like tech debt, we can and should approach it as a tradeoff.

When you rely too heavily on AI to generate code without understanding the fundamentals, you borrow against your future competence. The code works today, but what happens when:

• You need to debug something the AI created, but don't understand the underlying patterns?

• Your requirements change, and you must shift your program’s behavior beyond what simple prompts can handle?

• You face a novel problem that requires fundamental knowledge to solve?

That's when the debt collector comes calling. And trust me, it’s not if. It’s when.

Need-to-know and Domain Type

Let's take a concept from Domain-Driven Design to frame the issue. In DDD strategic design, we recognize three types of domains:2

• Core domains are your competitive advantage, modeling the unique parts of your business

• Supporting domains enable your core business but aren't a primary differentiator

• Generic domains are standard stuff every business needs (like authentication)

Now think about your knowledge domains as a developer. What's core to you? What do you need a deep understanding of versus what can you outsource?

And the problem you’re solving, is it a core domain or a generic one? Knowing this informs the measure of ownership and control you might exert on the problem’s solution.

The trap many fall into is treating everything as generic—"I'll just ask AI for all of it"—without recognizing which domains should be core to their expertise and attention.

Subscribe now

Signs You're Accumulating Learning Debt

Here are some warning signs that vibe coding might be creating learning debt:

1. You can't explain the code you're using. If someone asked you to walk through how your system works without looking at the code, could you do it?

2. You find yourself repeatedly asking AI for the same patterns. Instead of the knowledge becoming ingrained, you depend on external help for routine tasks. (Side note: speaking of patterns, I’m more than OK to outsource regex to the robots!)

3. Small changes require complete rewrites. When requirements shift slightly, you must regenerate entire components because you don't understand how to modify what exists. Intentionally disposable “fast fashion” architectures might be in our future, but we’re not there yet.

4. You feel anxiety when facing problems without AI assistance. That panicky feeling when you need to write code from scratch? That's your learning debt talking.

Balancing Vibes and Learning: It's All About Context

Agents are most potent when used to amplify understanding rather than outsource it.

This balance needs to be contextual, though. Kent Beck's 3X model3 provides a helpful framework for knowing your context and how much to vibe:

• In the Explore phase, you're testing hypotheses and seeking validation. Here, vibe coding with AI can be incredibly valuable. You're trying to shorten the distance between experiment and feedback, looking for quick payoffs with minimal investment. Technical excellence isn't the goal yet. Learning whether your idea is good and worth pursuing, modifying, or rejecting is.

• As you move into the Expand phase, where you're scaling something that works, your relationship with AI tooling (it’s not a person) should evolve too. This is where learning debt becomes dangerous. The foundations must be sound as you build on them, and your understanding needs to be deeper. Fortunately, I’m finding AI to be a good teacher for new tech, so it’s more a matter of changing your grasp of the tool than the tool itself.

• By the time you reach the Extract phase, where you're optimizing a mature and likely complicated system, both feasibility and sustainability of the tech stack demand genuine expertise, not just vibes. Agents will obviously be more and more valuable here, particularly as their context window challenges get resolved. Once again, it’s about changing how you hold the tool.

Kent Beck’s model maps perfectly to Brian Tod's path to product-market fit, visualizing the journey from validating desirability to ensuring feasibility and viability.4 The Explore-Expand phases of 3X align with Brian Tod’s Product Market Fit curve.

In the early stages of a product idea, we should focus almost exclusively on desirability: Is this solving a real problem for users? But as we validate that and move toward expansion, feasibility becomes crucial: Can we actually build and scale this solution effectively?

The learning debt accumulated during pure vibe coding becomes a liability at this inflection point. What worked for quick experiments won't sustain growth when real users depend on your product. This is precisely when you need to start paying down that learning debt.

With this in mind, here's how to maintain the balance:

• Use AI as an explainer and tutor. Ask for more than features. Ask for explanations of concepts, patterns, and trade-offs. Dipping into learning mode is a nice vibe unto itself.

• Challenge yourself to modify AI-generated code. Don't just paste it in. Change it, break it, fix it, and understand every line.

• Identify your core knowledge domains and product lifecycle stage. What areas do you need deep expertise in? Invest real learning time there, even if it's slower.

• Practice retrieval, not just recognition. Test yourself by writing code without assistance to ensure you build lasting knowledge.

• Match your AI dependence to your product phase. More AI-dependence in Explore, more understanding in Extract.

Many of these tips benefit from having a programming pair to keep you honest.

The Learning Payoff

The thing about learning debt is that it compounds just like financial debt. The longer you rely on shortcuts, the harder it becomes to build understanding later.

This is why we advise our clients to explicitly preserve time for learning in their workflow and when managing their queues (WIP, capacity).

Learning isn't separate from work. It's a fundamental part of work. Deep dives into understanding how and why code works are a crucial component of what Cal Newport calls "deep work."5 The ability to focus intensely on mastering complex concepts separates truly effective engineers from bricoleurs who cobble together solutions.

With both AI and developer productivity very much in the zeitgeist, it's tempting to eliminate learning time in favor of quick outputs in the name of efficiency. And yes, that's perfectly fine in some contexts, like pure exploration. But as your product matures, that investment in understanding should shift to non-negotiable.

Here's my challenge: for your next project, identify one core concept, fundamental to your work, and commit to truly understanding it, not just implementing it with AI assistance. A good test for this would be explaining what you’ve learned to a teammate. PSA: Don’t take humans out of your self-improvement loop!

While vibe coding feels good in the moment, truly understanding what you’re building feels so much sweeter for so much longer. Learning, now that's a vibe worth chasing.

Share

Michael wrote the seminal book (one of my absolute favorites) on wrangling gnarly software, “Working Effectively with Legacy Code”.

In this conversation, we cover:

• AI/LLMs’ outsized influence on software engineering and how we’re using it in our workflows

• Design principles that get rediscovered or re-invented with new generations

• The extinct mathematics of dirigible (blimp) construction and flight

A few links worth sharing:

• Michael’s book, “Working Effectively with Legacy Code”

• R7K Research & Conveyance - Michael’s consulting firm

• Follow Michael on LinkedIn

• His new book “AI Assisted Programming” is a work-in-progress available on LeanPub

• “Where AI Meets Code” — a recent presentation from GOTO Chicago 2024

• Be sure to catch Michael at the YOW! conferences if you’re in Australia

In this first session, we tackled a topic that doesn’t get nearly enough airtime: internal products. From enabling employees to powering core operations, these products sit at the heart of how organizations deliver value but come with unique challenges.

Highlights from the session featuring and included:

• Why internal products often struggle with funding, focus, and follow-through

• How to define success when there’s no direct customer revenue

• Practical approaches for discovering and validating internal user needs

Share

We wrapped with a lively Q&A and some great real-world examples from attendees. If you missed it or want to revisit the conversation, check out the full recording right here!

We’ll be back in a couple months for our next installment of Product Ecologies.

In the meantime, subscribe to our events page for new and upcoming webinars, conversations, and more. Next up? A conversation with Michael Feathers, author of the classic book “Working Effectively with Legacy Code”.

Subscribe now

Hello! Dave here.

I want to share some community events you might be interested in and great news about our team growing at Nerd/Noir.

From growing our team and hosting conversational events featuring Michael Feathers and Anne Steiner—Read on!

Welcome to Nerd/Noir, Jess Brock!

We’re adding some real heat to our team of collaborators at Nerd/Noir. Please join me in welcoming Jess Brock!

Jess is joining us as a strategic advisor, bringing her expertise in business agility, AI, and immersive learning dojos to our clients. On that last part—she helps lead and run an active dojo at Edward Jones and wrote a useful book for immersive learning coaches, “The Dojo Coach's Pocket Guide: Maximizing Immersive Learning for Agile Teams”.

Alex and I have become pals with Jess over the last couple of years, working on some side projects here and there. Aside from her bona fides, we love her personality: a subtle and witty sense of humor, an experimenting and action bias, and a strong community orientation (she helped organize a job fair for out-of-work agilists, amongst other things). She’ll fit right in.

Welcome, Jess!

Community Events

Also, we’ve been feeling (more than a little) nostalgic for the halcyon days of David Hussman’s Jam Sessions (IFYKYK)—his unfiltered, real-talk gatherings where ideas flowed as freely as the beer. While there’s no replacing David, we’re experimenting to see if we can capture some of that magic in a digital and remote form.

We’ve got two upcoming sessions that should be right up your alley!

Product Ecologies: Working with Internal Products with Anne Steiner

Thursday, March 20th, from 12-1 PM EST | Register here or LinkedIn

Internal products don’t get the same love as customer-facing ones, but they should. Anne and I feel this area is somewhat slept on. Most product thought leader (thought lord?) content focuses on B2C or B2B SaaS scenarios.

Internal products power business operations (ERP, CRM, HR systems), enable engineering teams (platforms, APIs, shared services), and help employees deliver value (customer support tools, workflow automation). However, unlike external products, they don’t have clear market signals, often suffer from misaligned incentives, and struggle to get investment.

So we’re kicking off a new series called Product Ecologies with a conversation about what makes internal products uniquely challenging—and how to make them successful. In episode one, we’ll cover:

• Common pitfalls in internal product development

• How to define success when there’s no direct revenue

• Strategies for discovering the unmet needs of internal users

After a short talk, we’ll open the floor for discussion, so bring your challenges and insights. The event occurs Thursday, March 20th, from 12-1 PM EST. Come through!

Register Now

Software Engineering Conversations with Michael Feathers

Tuesday, April 8th, from 3-4 PM EST | Register here or LinkedIn

A look at software engineering—past, present, and where we might be headed next in the age of AI-first engineering. The event takes place Tuesday, April 8th, from 3-4 PM EST.

If you don’t know, Michael wrote the essential book on wrangling gnarly, scary, and anxiety-inducing codebases, “Working Effectively with Legacy Code”. It greatly influenced my career (and of many others), and it holds up to this day.

No slides, just a straight-up discussion. I hope to craft some unique and surprising questions and conversation-starters for Michael. We’ll also leave plenty of time for an AMA with Michael.

Over the years, we’ve gotten to know each other at various software conferences, and our technical conversations always draw on a lot of cultural references (music, art, philosophy—lateral thinking!). It’s often fun and thought-provoking for us, and we hope it will also be fun and thought-provoking for you.

Again, the event takes place Tuesday, April 8th, from 3-4 PM EST. Hope to see you there!

Register Now

Yesterday, we hosted a webinar titled From Technical Debt to Technical Investment. Thanks to everyone who signed up and came out!

As promised, we’re sharing the recording and Miro board we used. The board contains the presentation materials and our playbook for creating Technical Investment Options.

We didn’t get to go through everything in detail, so be sure to check out our open playbook framework, and don’t hesitate to get in touch if you need help getting started.

Enjoy and stay tuned/subscribe for more examples and tools coming soon!

Hey y’all – 

Before I jump right into insulting your requirements, I’d like to share some recent events at Nerd/Noir.

—

On October 16th, 12-1p EST, I’m co-hosting a webinar with Anne Steiner called From Technical Debt to Technical Investment. You can sign up here.

We’ll explore the semi-wicked problem of “tech debt” from both engineering’s and product’s perspectives. We’ll also share our playbook (did you know we created a playbook framework that’s free to use, remix, and share?) to help teams balance customer outcomes with system qualities.

And if you can’t make that date/time, go ahead and sign up, and we’ll ensure you get the recording and playbook sent straight to your inbox.

—

We’ve done a lot of Developer Experience consulting over the last few years. Our partnership with DX lets us conduct a sweet (95%+ completion rates, dozens of metrics, solid research) snapshot survey that gives everyone—leaders, engineers, product people, and us—transparency into what’s working and what’s not. 

Our clients are finding that the data from the DevEx 360 platform is driving productive conversations and, more notably, action around continuous improvement. It’s a quick and cost-effective way to create situational awareness around DevEx. Check out our Developer Experience Insights service right here.

—

This post is extracted from a talk I gave at Travelers’ internal “Enterprise Engineering Day” conference a week ago. Thanks to the good folks at Travelers for having me! If you’d like someone from Nerd/Noir to speak with your group, check out our internal talks page for a list of topic ideas. 

On to the article! 

/ Dave

P.S. To my fellow business goths out there: HAPPY SPOOKY SEASON! 💀🎃👻

—

Your Requirements Suck

“The requirements aren’t good enough.” You’ve heard it. Perhaps you’ve said it. It’s a common complaint from engineers. 

But it doesn’t tell you all that much. It describes a symptom, not the disease. What about the requirements makes them inadequate?

Why Your Requirements Suck

Unclear or ambiguous requirements are single effect with multiple causes. A few of the usual suspects:

• Game of telephone - the original intent of a requirement is misshaped through a series of point-to-point conversations.

• Unclear - the requirement is ambiguous and open to creative interpretation, perhaps with many unchecked assumptions.

• Shifting Sands - requirements change or are swapped due to insufficient discovery or moving target priorities. 

• But Why Tho - engineers working on a requirement question its purpose or value.

• Cold Handoffs - the requirement is pulled from a backlog, and backlogs aren’t great storytellers.

• Overconfidence - just because you think it’s a requirement doesn’t mean it solves a problem for a user or customer. See also: overly speculative.

Your requirements might suck because of one of these reasons or because of all of these reasons. Game of telephone frequently conspires with cold handoffs. Shifting sands and Overconfidence and But why tho are the unholy trinity of a poorly understood or empowered product management capability. 

Maybe the idea that requirements can ever be good enough needs a bit of rethinking.

System Effects

If we don’t address the causes above, what’s likely to happen? Let’s look at a causal feedback diagram illustrating one likelihood. 

In this diagram, we have three values:

• Trust is the belief that our customers and stakeholders have in us to solve problems and create value. 

• Rework is the time we spend changing what we’ve delivered because the first delivery was wrong. 

• Throughput of Value is the value we deliver to customers or stakeholders in a given period.

The arrows with the little circles with a plus or minus indicate in which direction these values travel:

• As the amount of Rework increases, perhaps due to not understanding requirements, our Throughput of Value decreases. We have to spend more time getting things right.

• As Throughput of Value decreases, the Trust our customers or stakeholders place in our ability to deliver value also decreases. This is bad.

• As Throughput of Value decreases and Rework increases, Trust erodes ever faster. 

We have a vicious circle that leads to a classic Western standoff. Customers don’t trust the team’s ability to deliver, and the team doesn’t trust the customer or product manager’s requirements. We already know how the engineers feel.

What’s going wrong here? If it’s really about crappy requirements, shouldn’t we make them better? Just requirements harder!

Questionable Assumptions

Before we start fixing our requirements practice, I have a question: Why do we think written requirements are a good idea in the first place? Let’s go digging for assumptions.

A quick brainstorm reveals several questionable, perhaps faulty, assumptions.

Are requirements even knowable up front? We know this: The highest-quality feedback comes after users have used working software. Unfortunately, engineering is an expensive undertaking. I understand why we might try to de-risk user needs by validating our ideas before starting principal engineering. Though I’m pretty sure requirements-centered activities and artifacts aren’t the answer.

It’s the product manager’s (or product owner’s or BA’s) sole responsibility to write acceptance criteria. If you believe that, you’re likely experiencing the problems of cold handoffs or game of telephone.

User stories are a written medium. You’re probably sick of hearing this (I know I am), but user stories were always meant to be placeholders for conversations. Many companies that adopted agile practices simply slapped the label “user story” on their business requirements docs and moved on with their lives.

Assigning new vocabulary to existing practices, roles, or processes never worked. Business analysts or project managers became product owners in a two-day training, program management offices were replaced by release trains, and the list goes on…

Putting too much weight (or hope) on a handoff-driven requirements process assumes you have a lot of other things in order. When requirements are unclear, you shouldn’t assign blame to the artifact or its creators. You have to look at the system.

Assumptions: Checked

Let’s unravel some of those nasty assumptions.

The idea that requirements are knowable up front is a broad, context-free statement. Many of the products we work on benefit from learning and experimentation. If this is your context, frame what you want to deliver, but don’t get it twisted. You’re not creating requirements; you’re making an educated guess. 

Hopefully, that guess will be backed by solid product discovery. In your discovery missions—also hopefully—you’re inviting technical representation to shift left, upriver in the value stream.

Creating requirements should be a joint activity. It’s not the sole responsibility of the “product person” on your team. A product manager cannot anticipate every edge case, and as the engineering work unfolds, there will be questions, what-abouts, and many small decisions to make. All good reason for inviting engineering along for the ride.

We could pick apart all these faulty assumptions and the underlying problems they hide when unchecked, but what could we do to change the system? 

One Small Step

Collaboration is the solution. Unfortunately, it’s not an easy solution. 

Real, genuine collaboration is a skill that you must relearn with every new group of people you work with. It requires that:

• Product-focused people (PM, UX) continuously engaged throughout delivery, negotiating, and refining requirements.

• Engineers take their hands off their keyboards and work with their cross-functional teammates, valuing that time.

• Stakeholders provide timely feedback in tight loops to guide what we used to call requirements (what we think) toward specifications (what is).

Notice I didn’t call collaboration a simple solution. It’s not. Effective collaboration means courting conflict and committing to making many small resolutions. Effective collaboration means navigating tricky tensions, such as the desire for delivery speed and solution quality. Effective collaboration means occasionally giving so that you may get down the line.

More than anything, we can’t collaborate if our partners don’t agree to do the same. Real collaboration doesn’t work without us taking at least one small step toward one another.

• Engineers: become co-authors of requirements. Ask to ride-a-long on a product discovery mission or design review.

• Product people: understand that engineers spend a lot of time thinking about your (y’all’s) product. They might even have something valuable to say about its direction.

• Leaders: show up and give the feedback required to shape speculative requirements into actual specifications.

Go ahead, everyone, take one step toward the center.

If you want something done right, do it together.

Share

When folks talk about a company being "product-led," we often hear how it changes things for finance, portfolio management, and product management. But we rarely discuss what it means for the engineers who build the product. And let me tell you, the impact on engineering teams is huge and shouldn’t be overlooked.

Finding Identity in Product-led Engineering

Let’s start with something simple. Ask an engineer at your company, “What do you do here?” You might hear, “I’m a Go developer,” or “I’m a frontend dev,” or maybe even, “I’m on a Scrum team.” What they’re really telling you is what they’re bonded to—whether it’s a programming language, a part of the tech stack, or even the process they follow to get their work done. They identify with the “how.”

But here’s the thing: you'd hear something different in a truly product-led company. Engineers would say, “I work on small business bond policies,” or “I work on the search team.” They’d primarily identify with the product they’re helping to build, not just the tools or processes they use.

This difference might sound small, but it’s a big deal. When engineers identify with the product they’re working on, it signals that they’re more invested in the success of that product and its users. They see themselves as part of something bigger than just writing code—they’re helping to put something into the world that real people will use. 

Asking “What do you do here?” is a quick way to test whether your company is product-led. Go on and try it. Ask your engineers what they do and see if they talk about the product or just the tools.

Purpose and Impact: The Real Payoff of Being Product-led

One of the upsides of being product-led is the connection it creates between engineers and the people who use the product. When jumping from project to project, you don’t always get to see the long-term impact of your work. But when working on a product over time, you start to understand how it works, how it’s positioned in the market, and most importantly, how it’s helping people. You’re working closer to value, outcomes, purpose, and impacts. It’s easier to understand how your work moves the needle.

As a young engineer, I remember working in a traditional, project-led environment. We followed the waterfall method and had no real contact with the customers. I couldn’t see how what I was doing was making a difference. It was frustrating because I wanted to know that my work mattered. 

After a while, I wasn’t content just writing code for the sake of it—I wanted to know how it was helping someone out there. This disconnect was a big reason I eventually left engineering for product management. If you can’t fix the problem from your current position, go somewhere where you can.

In a product-led company, engineers should never feel that disconnect. They should see firsthand how their work is making a difference. And as a result, they will be more motivated and engaged. They’re not just writing code—they’re solving problems for real people. Real people who appreciate their efforts, even if unattributed.

Better Decisions Through Product Knowledge

Here’s a red flag for me: when an engineer says, “Just tell me what to do, and I’ll do it.” That’s a sign that something’s gone wrong. Maybe they’ve been beaten down by the system. Or maybe they’ve just given up on trying to think for themselves. Either way, it’s bad news for everyone.

In a product-led organization, engineers must be part of the decision-making process. They need to know what the product is trying to achieve so they can make informed decisions every day. Engineers not only have to build things the right way, but they also have to build the right things. They’re making small decisions all the time—hundreds of them, just in how they write code. There is a compounding effect. They can't make the best choices if they don’t have the full picture and some skin in the game.

This isn’t about engineers stepping on the toes of product managers. It’s about everyone on the team sharing knowledge and working collectively to improve the product. The more engineers know about the product and the market, the better their decisions will be and the better the product will turn out.

Oh, and Product Managers, creating this environment takes a lot of pressure off of you. Many hands make light work.

Goodbye, Death Marches; Hello, Sustainable Development

Let’s talk about the dreaded “death march” for a minute. 

Back in the day, when projects were managed with waterfall methods, we’d go through grueling, months-long pushes to get something out the door. It was all-hands-on-deck, working 12-hour days, weekends… the whole nine yards. Then, once the project was done, there’d be this big dip, where work slowed to a crawl until the next death march kicked off.

It was exhausting, and honestly, it didn’t lead to great results. Often, after all that hard work, we’d find out that we built the wrong thing. The market had moved on, or we’d misunderstood what customers needed. All that effort, and it didn’t even hit the mark.

These days, with agility and product-led development, things can be different. We’re not just throwing everything into one big project and hoping for the best. We’re working iteratively, releasing smaller changes more frequently, and responding to feedback as we go. This approach evens out the workload and helps us avoid those brutal peaks and valleys. Plus, we’re more likely to deliver something that works for our customers because we’re constantly testing and adjusting. Early value and feedback for the win!

Continuous Improvement: The Long View of Product-led Development

One of the biggest shifts in thinking that comes with being product-led is the idea of continuous improvement. In the old project-led world, we’d finish a project, pat ourselves on the back, and move on to the next one. But in a product-led world, the job isn’t done until the product reaches the end of life. For successful products, that can be a decade or even more. We’re always looking for ways to improve it, whether by fixing what’s broken, improving what’s already working, or adding something new.

The pattern of financing a project and moving the bits over to keep the lights on the team is a known recipe for generating technical debt. Unchecked, systems spiral toward crisis. There’s no incentive for engineers measured on time and budget to do the right thing, and there are no consequences to taking shortcuts to make the numbers.

This kind of longer-term thinking separates product-led organizations from the rest. It’s not just about getting something out the door—it’s about ensuring the product stays relevant and useful for as long as it’s in the market.

Bringing It All Together

So, what does it mean to be product-led in engineering? 

Engineers are more than just code writers—they’re integral to the product team. They understand the purpose of what they’re building and are deeply connected to their product’s success. They feel ownership.

Engineers make better decisions because they have the information they need, and they work in a way that’s both sustainable for themselves and responsive to the market.

Product-led isn’t just a buzzword—it’s a way of working that brings out the best in your engineering team and delivers better customer results. It’s time we started talking more about what it means for the people who build the product, not just those who manage it. If we do that, we’ll see better outcomes for the product, the company, and, just as importantly, the engineers themselves.

Kurt Anderson, founder and former editor of New York Magazine and Studio 360 Podcast host, infamously created a list of “Words We Don’t Say” to discourage fluff and filler from the pages of his magazine. It’s a little snobby, but you’ve got to have standards—especially in NYC!

Exploring some words that carry emotional baggage for us in product and engineering might be interesting. These words may trigger us, causing us to cringe when using them. Some would argue they need retirement from the lexicon, while others may find them funny.

At Nerd/Noir, our collaborators meet bi-weekly to review new opportunities and existing gigs and do something creative together. I solicited their input on these words a couple of sessions back. So, thanks, collaborators! 

Oh - and I’ll ask for your input at the end of this post!

Subscribe now

#1 - “Resource”

When senior leaders talk about people, they often use the word resource. People don’t like to be called resources. It’s depersonalizing. I am not a mine to be stripped, nor a well to be drained, nor an ore to be smelted. 

Product people might cringe at the word because it harkens back to the old ways of the project model. Resources are to be controlled as one vertex of the iron triangle. 

Odd because your organization probably has a department called “Human Resources.” We’ve seen a shift from that language in that group as top HR leaders increasingly adopt the title of Chief People Officer.

I hear the word “talent” used sometimes. It’s usually a good indicator that its user is also triggered by the word resource. Listening closely is a great way to find others who share your values.'

If you’re feeling especially cute, you could also use the word “resourceful,” as I do when people share their feelings around this word. But, then again, why not just call people, I don’t know, people?! 

I’ve relaxed my policy on this word, partly because I work with executives, and it’s not my job to push my idiosyncrasies on their vocabulary. While I may point out something destructive or hurtful in a 1:1, the R-bomb doesn’t make the cut. Like many trigger words, the reaction depends on the room and its occupants.

Share

#2 - “Mindset”

Growth mindset. Product mindset. Zero defect mindset. Security-first mindset. Agile mindset. There are more mindsets than you can shake a stick at. The word is tired, overused, and anxiety-inducing (for me, at least). 

How many ways of thinking would you like me to adopt? Multiple mindsets feel like a case of split personality. 

It also smacks of agile coach pop psychology woo-woo mysticism. How exactly do you propose I adopt and leverage this mindset? Can you show me what it looks and feels like in practice? Answers to questions like these might be a better starting point.

In some meta-cognitive moments, when I take a step back and consider my mental model and way of thinking, I boil it down to thinking critically and laterally. That’s right, just two modes of thought.

Critical thinking is about tearing down a condition, statement, or hypothesis. It gets you to a place where innovation can start to happen. Why is this thing the way it is? Repeat that question until you find a root cause or some faulty assumptions. Some would call this the starting point of first principles thinking.

Lateral thinking pairs nicely with critical thinking. It involves considering multiple solutions to problems, where unconventionality, wild ideas, and creativity come into play.

Critical thinking is great for analyzing problems, and lateral thinking is great for innovating new solutions. Both are useful. Knowing when to apply which one is a skill one can develop. 

For example, a fundamental of good workshop design is to stack moments where you ask participants to think critically (generate a list of what needs improving) followed by thinking laterally (what solutions might we apply to this problem we prioritized).

The other problem with mindset is that it short-circuits action. You cannot successfully adopt any mindset without immersing yourself in the actions that align with that mindset. Mindset emerges as a side effect of doing. 

Lean management guru John Schook created a model that our team lives by:

Mindset and culture are the end states of Shook’s model. They take root and form from doing. Changing the way you do things creates new behaviors influencing values and attitudes. The collective set of these values and attitudes terraforms culture. That’s Shook’s model. You can read more about it in the famous NUMMI auto plant case study.

My problem is that certain people over-index on mindset. Awareness is a good starting point, but it alone does nothing to change behavior or the way we think.

We can find examples of this thinking in a change team's metrics: number of trainings taken, teams trained, etc. These activity metrics tell you nothing about outcomes or even new behaviors. I suppose we could call this the “Busywork Mindset.”

If all someone has to say is mindset this or that, do you think they can help you affect meaningful change? Nope. No amount of agile shaman babble or LEGO® SERIOUS PLAY® will get you to meaningful impacts.

#3 - Transformation

Transformation has so much baggage we might call it a full Louis Vuitton luggage set. 

Buzzword fatigue is a big part of it. Here come the consultants! “Big A” Agile traded under this term and still does. 

When talking to senior leaders, one of the first questions I’ll ask is, “How many transformations have happened here?” It’s not unusual for us to show up at a client to find out we’re the next in a long line of Don Quixotes. To solve the unsolvable problem! To change the unchangeable company! To dream the impossible dream!

Typical responses:

• We tried our own thing 

• Then we tried SAFe a few times

• Then we tried the Spotify model

• Now we’re back to waterfall projects

Change is scary, especially when it’s opaque and mysterious. Reactions vary:

1. Here come the consultants! How will I wait them out this time?

2. How will this top-down imposition affect me?

3. I was finally making some good progress in my job. Now that’s about to get crushed.

Transformation is a trigger word because most people have been through at least one that’s been poorly handled—crappy communication, unclear vision, surprises, a lack of enrollment, etc. One (of the many) reasons they fail is because individuals find ways of protecting themselves in difficult circumstances, undermining the change's intent.

#4 - “MVP”

Minimum Viable Product (MVP) comes to us from Eric Reis and the Lean Startup community. Every word in the sequence has its own set of triggers. A few examples:

1. Minimum - you’re just using the word to disguise “big project.”

2. Viable - you want us to get to economic viability in a few weeks?!

3. Product - we know you mean project.

The original intent of MVP has been lost. It was intended to be a form of experiment that used software delivery to validate assumptions. The big question is, “Do people want this at all?”

Many other experiments and discovery techniques are way cheaper than software delivery, which we can use to validate our ideas as good or bad. We could do research, competitive analysis, or even create a landing page with a signup form that advertises vaporware to assess demand (Oz MVP). 

At some point, you’ll start working on a new product idea or larger feature with enough confidence to place a bet requiring delivery. It will be new and big enough to need a foundation of table-stakes features and maybe one or two exciting or somehow differentiating features.

This first pass will take longer than subsequent iterations. And that’s what I call an MVP, but I always feel the need to disclaim, “I’m using that term as it was originally intended and with low ceremony, so let’s not get too hung up on it.”

Subscribe now

#5 - “Scrum Master”

Scrum has some problematic language embedded in its roles: Scrum Master and Product Owner. This language is problematic from both inclusion and anti-racist perspectives. 

If the various Git platforms changed their main branch names from “master” to “main” way back in 2020, why can’t Scrum do the same? Seems retrograde to me. Or a stubborn commitment to a privileged bias. Either way, it’s whack.

Scrum Master also sounds silly when we pair it with more contemporary contributor roles like product manager or engineer.

One company I worked for even renamed Scrum Masters to “Flow Wizards.” Clearly, some VP was a fan of the Harry Potter series. To me, it sounded like the name of a medical catheter. That company had a lot of legacy software and growth through unchecked acquisition problems, so maybe “Dungeon Master” would have been a more fitting title.

Everybody Has Choices

Consulting is a weird job sometimes. You find yourself in different cultures with different norms and sometimes similar words that mean different things. You must learn to adapt to these nuances quickly before a client’s patience with you runs out. Adaptability is a skill.

Chances are you can’t word-police everyone to your perfect, trigger-free vocabulary. You can, however, control your language and model the behavior you’d like to see from others. Personal word choices are a degree of freedom!

When leaders talk about people as “resources,” I’ll respond with the word “people.”

When I feel the “MVP” people are talking about is getting large and out of control, I’ll ask about the “first iteration” or “first chance for feedback.”

When the conversation is peppered with talk of “transformation,” I’ll ask where we can “make a small change” and “get an early win.”

What words trigger you?

I wrote this post hoping to hear from our subscribers. 

What words trigger you and why? What are your strategies for coping with these loaded words? I want to hear from you in the comments below!

Leave a comment