Monday, December 22, 2025

Good talks/podcasts (Dec II)

These are the best podcasts/talks I've seen/listened to recently:
  • You ONLY Get Code LIKE THIS With TDD 🔗 talk notes (Dave Farley) [Continuous Delivery, Software Design, tdd] [Duration: 00:16] This talk explores Software Design as the core of development, illustrating how test-driven development (TDD) serves as a critical design tool for achieving modularity, cohesion, and continuous structural improvement.
  • Building effective engineering teams; lessons from 10 years at Google | Addy Osmani 🔗 talk notes (Addy Osmani) [Agile, Continuous Delivery, Engineering Culture] [Duration: 00:31] An exploration of how Engineering Culture integrates Technical Leadership, Management, and Developer Productivity to optimize Teams through Agile and DevOps practices.
  • Rethinking growing engineers in the age of AI | Meri Williams | LDX3 London 2025 🔗 talk notes (Meri Williams) [AI, Engineering Career, Engineering Culture, Technical leadership] [Duration: 00:23] (⭐⭐⭐⭐⭐) Meri Williams explores the urgent need to rethink engineering growth in the age of AI, advocating for a shift from manual coding tasks toward early tech leadership, systems thinking, and a "healthy paranoia" that allows leaders to "surf" the waves of technological change rather than be overwhelmed by them.
  • The Biggest Problem With UI 🔗 talk notes (Dave Farley) [Continuous Delivery, Software Design, team topologies] [Duration: 00:15] This talk explains why UI/UX design should be treated as an integral software design choice rather than a static specification, advocating for development teams to own the UI to ensure the system accurately reflects the user's mental model.
  • Shaped by demand: The power of fluid teams | Daniel Terhorst-North | LDX3 London 2025 🔗 talk notes (Dan North) [Agile, Product Discovery, Teams] [Duration: 00:23] Daniel Terhorst-North presents demand-led planning as a framework for building fluid, autonomous teams that self-organize quarterly to balance delivery, discovery, and Kaizen based on real-time organizational demand.
  • Tidy First? A Daily Exercise in Empirical Design • Kent Beck • GOTO 2024 🔗 talk notes (Kent Beck) [Agile, Engineering Culture, Software Design, XP] [Duration: 00:57] Kent Beck explores software design as a socio-technical exercise in human relationships and economic optionality, offering a framework to balance feature delivery with a sustainable engineering culture rooted in Agile-XP principles
  • Rafa Gomez - Attacking tech Debt: A Marathon, Not a Sprint - SCBCN 25 🔗 talk notes (Rafa Gómez) [Architecture, Product, Technical leadership] [Duration: 00:41] Learn how the "Marathon" approach enables engineers to tackle technical debt by adopting a product mindset that aligns long-term technical health with business value and consistent product delivery.
  • An Ultimate Guide To BDD 🔗 talk notes (Dave Farley) [Continuous Delivery, Software Design, tdd] [Duration: 00:18] Dave Farley explains how Behavior-Driven Development (BDD) utilizes executable specifications to improve software design and collaboration, facilitating excellence in Continuous Delivery through a user-centric, outside-in approach.
  • Unit Testing Is The BARE MINIMUM 🔗 talk notes (Dave Farley) [Continuous Delivery, Software Design, tdd] [Duration: 00:20] Learn how Test-Driven Development (TDD) serves as a critical act of design to achieve high-quality software by specifying behavior over implementation and enhancing modularity
Reminder: All of these talks are interesting, even just listening to them.

You can explore all my recommended talks and podcasts on the interactive picks site, where you can filter by topic, speaker, and rating: Related:

Saturday, December 20, 2025

Radical Detachment in the AI Era: Reinventing How We Build Software

Let me start with a disclaimer. I'm an enthusiast who loves trying new things, what some might call an early adopter, a geek, and perhaps a little bit obsessed. And right now, I'm enjoying this moment in our industry immensely, like a pig in mud.

A few months ago, something shifted. I had my "wow" moment, a realization that this changes everything.

For the last couple of years, as a Head of Engineering managing teams of 25 to 37 people, I had become one of those managers who "used to code." My chances of writing anything substantial were practically zero. In all of 2024, I made maybe 40 contributions to my personal repositories: a few commits here and there, mostly small fixes or experiments that went nowhere. The kind of sporadic activity you see from someone who loves coding but has accepted the inevitable trade-off of leadership.

Then, in early 2025, something happened. While still managing the same large team, with the same responsibilities and time constraints, I suddenly found myself shipping code at a pace I hadn't seen since I was an individual contributor. Over 800 contributions in just a few months. Not toy projects. Real, ambitious systems I'd kept on a mental backlog labeled "someday when I have time." The tools that made this possible? Primarily Cursor and Claude Code, with some experimentation with Codex along the way.

That's when it hit me: "This changes everything. Nothing will be the same again." We are now entering terra incognita, unknown territory. It's a time of total uncertainty, but it's also a time of unprecedented opportunity, which is what I want to explore with you.

To Build the Future, We Must First Invent It

"The best way to predict the future is to invent it." That was the philosophy of Alan Kay and his team at Xerox PARC in the 1960s and 70s. They didn't think about building products; they focused on inventing the future itself.

Their approach was grounded in a set of powerful principles. They thought about fundamental problems, not products, aiming to solve deep human or professional challenges. They identified exponential trends and created a 30-year vision. For them, it was Moore's Law, which they used to imagine what would be possible decades later. They explored with radical freedom in intensely interdisciplinary teams, mixing computer scientists with physicists, philosophers, and ethicists, believing groundbreaking ideas came from these intersections. They followed a "demonstrate or die" principle where ideas were nothing without practical, working prototypes. They built tools to build other tools, layering their inventions to create a platform for future innovation. And they always used systemic thinking, focusing on the whole rather than just optimizing individual parts.

A perfect example is the Dynabook. In 1968, they created a cardboard prototype of a portable personal computer. They knew the hardware didn't exist yet, but they trusted Moore's Law to make it a reality within 30 years. From this long-term, visionary thinking came some of the most foundational technologies of our time: Smalltalk, laser printers, Ethernet, graphical user interfaces (GUIs), and the personal computer. They also took object-orientation, evolved it, and carried it to its extreme. Steve Jobs later famously took inspiration from their work and brought many of these ideas to the masses.

A 30-Year Glimpse into Our AI-Powered Future

Following the Xerox PARC model, let's identify the current exponential trends in AI. The capability of LLMs is constantly increasing, with more parameters and larger context windows. The cost of inference is falling exponentially. And if the trends I'm observing hold, the speed of code generation could increase 10x every 3-4 years, though this is more intuition based on current trajectories than hard data.

These trends force us to ask some provocative questions about our profession. Will the strong distinction between "programmer" and "non-programmer" continue to exist? What will our role be when 99% of the code is written by AI? Will code quality still matter, or only "verifiable correctness"?

To avoid getting bogged down in the limitations of today's AI, let's project 30 years into the future.

What will seem ridiculous in 30 years? Not working with AI agents as integral team members, coding manually or "artisanally," and remaining at the same level of abstraction (that is, typing text into files).

What will still make sense? Solving problems using software, understanding and learning a domain, and contributing our knowledge to the business.

This leads to a powerful metaphor: in the future, manual coding will be like doing Sudoku or puzzles. It will be a stimulating mental exercise, a hobby for those who enjoy it, but not a professional necessity for building the vast majority of software.

Look, I know not everyone has had their "wow" moment yet. Your mileage with AI coding assistants might vary wildly from mine. Maybe you've tried them and found them frustrating, or maybe they just don't fit your workflow. That's completely valid.

But here's why I'm making this 30-year projection: I want to sidestep the debate about whether AI "works" for programming right now. That debate is too tied to individual experience and current limitations. What I care about is the trend, and the trend seems clear and irreversible. The investment, the adoption, the sheer momentum behind this technology doesn't look like a passing fad.

So whether you've had your moment of "this changes everything" or you're still skeptical, here's what we can't avoid: the change is already here. Organizations are already restructuring around it. Budgets are already shifting. Roles are already being redefined.

Which brings us to the critical question.

A Call to Action: Who Will Reinvent Our Profession?

The shift we are experiencing is not a minor innovation like blockchain or whatever the latest hype cycle is selling us. According to the models of economist Carlota Pérez (whose work on technological revolutions analyzes patterns across centuries of industrial transformation), this is a technological revolution on the scale of the steam engine or mass production. We are at a turning point that will redefine everything.

This brings us to the central question: Who do we want to reinvent our profession?

We have two options:

  • Option A: The consultants. Firms like McKinsey, whose articles on developer productivity reveal a fundamental misunderstanding of the nature of software.
  • Option B: Us. The community of practitioners who truly understand software's nature, people who have embraced Extreme Programming, Lean, and Software Craftsmanship.

This choice is being made right now. Not in five years. Not when "AI matures." Now. Every day that passes, more organizations are adopting AI productivity metrics designed by people who've never shipped production code. More engineering teams are being restructured by consultants who think code generation is just "faster typing." More junior developers are being evaluated by KPIs that measure activity instead of impact. The window to shape this transformation according to our values is closing.

The stakes are higher than a simple preference. This is a fight for the soul of software development. If we, the craftspeople, don't lead this transformation, the consultants will define the future of our work. And I am not going to like the profession they design for us.

But choosing Option B—choosing us—means more than just declaring we're in charge. It means accepting responsibility for each other. It means the experienced developers who mastered previous paradigms must guide those entering the field during its most chaotic moment. It means creating spaces where experimentation is safe, where failure is learning, and where knowledge flows freely instead of being hoarded. This isn't optional. If we don't take care of our community, we don't deserve to lead this transformation.

Revisiting Our Core Principles: Software is a Means, Not an End

The first line of the Agile Manifesto is key: "We are uncovering better ways of developing software..." It was never a static set of discovered truths. It has always been about continuous learning and adaptation. The prime directive has always been to satisfy the customer by solving their problems.

This brings us to the most important principle to remember today: Software is the medium, not the end. Our mission was never just to write code. It was to solve problems and create impact. If coding is destined to become a hobby like Sudoku, then our professional identity must be rooted in something deeper. The over-specialization that led to rigid roles like "frontend developer" or "DevOps engineer" was a mistake, a mistake that AI now gives us the power to correct.

Consider the software development "Food Chain", which maps the workflow from Opportunity Selection to Validating Impact.

This visual tells a crucial story. The top section, outlined in red and marked with a skull and crossbones, represents the "danger zone" of siloed, waterfall-style handoffs. This is where individuals are disconnected from the customer and the problem they are trying to solve. In contrast, the bottom section, outlined in green, is the "safe zone" where integrated, cross-functional teams own the entire value stream from beginning to end.

The implication is clear: AI makes it painfully obvious that roles isolated in the "build" phase are the most vulnerable. To remain relevant, we must move closer to the beginning (understanding the problem) and the end (validating the impact).

The Mindset of Radical Detachment

To navigate this new era, we need the intellectual humility to empty our own cups. We must unlearn what we think we know to make space for new ideas.

You Are Not Your Code

Because the nature of software is to change, we must practice radical detachment from our creations. Detach from your beautiful code, your elegant designs, and your favorite patterns. Holding on too tightly creates rigidity, turning what should be flexible clay into a brittle relic. Our business is not building finished solutions; it is evolving solutions over time.

The New Dynamics of Managing Complexity

With AI, the friction to generate new ideas, experiments, and complexity is almost zero. The process of software development will no longer be a slow, incremental growth of a single snowball. Instead, it will be a rapid cycle of expansion and contraction: exploring dozens of options in parallel, then radically deleting and simplifying to keep only what works. Managing this explosion of complexity will become one of the most critical skills we possess.

The Great Multiplier: AI in the Forest vs. the Desert

Beth Andres-Beck and Kent Beck describe two contrasting environments for building software: the desert and the forest.

The Desert is characterized by constant urgency, silos, poor testing, and misunderstood practices. It's a place of chaos and anxiety. The Forest is characterized by good practices, technical excellence that enables evolution, and close collaboration with the business. It's a place of sustainable growth.

AI is an indiscriminate multiplier. Its effect depends entirely on the environment it's applied to.

In the Desert, AI multiplies chaos. It becomes a factory for producing "fast trash," turning a technical debt problem into technical bankruptcy. In the Forest, AI multiplies discipline. It creates a virtuous cycle. Good practices like TDD, clean code, and good documentation provide the AI with better context, making it more effective. In turn, the AI makes it easier and faster to apply these good practices, turning them into unprecedented velocity and quality.

This leads to a paradigm shift. For the first time in our industry's history, the economic argument for software craftsmanship is no longer a nuanced discussion about long-term TCO. It is an immediate, undeniable, and exponential driver of value. AI makes excellence profitable in the short term.

Essential Practices for the AI-Augmented Developer

Certain engineering practices become supercharged in the AI era.

Modular architecture is essential. The rapid expansion-contraction cycle of development is only manageable within a modular architecture. Modularity provides the firewalls necessary to run dozens of parallel experiments without the entire system collapsing into chaos.

Clean code is crucial. Semantic, understandable code is essential for the AI to grasp business logic and provide meaningful assistance.

Quality and automated testing is non-negotiable. It is the only way to safely validate the massive volume of code AI can generate.

Small steps remain important. The principle of working in small, verifiable increments remains, but we must be open to the idea that the "size" of a step might change dramatically.

The Developer Laziness Scale

Think of your interaction with AI on a "laziness scale":

  • 100%: You write a prompt and blindly accept the output.
  • 80%: You glance over the code for obvious errors.
  • 50%: You review every line of AI-generated code carefully.
  • 20-30%: You code mostly by hand, using AI for autocompletion.
  • 0%: You write everything manually, artisanally.

The meta-skill is to treat this scale like a gear shift, consciously choosing the right level of automation and oversight for the road ahead. This requires retaining deep, low-level knowledge even when you aren't always using it directly.

FAAFO and Radical Simplification

The book Vibe Coding by Gene Kim and Steve Yegge introduces the FAAFO framework: a style of work that is Fast, Ambitious, Autonomous, Fun, and creates Optionality. AI is the engine that makes this possible, allowing us to tackle legacy refactors or build prototypes that once seemed impossible.

However, this power comes with a critical discipline. The ability to be Ambitious and create Optionality must be balanced with an equal commitment to radical simplification and deletion. This is where the discipline of radical detachment becomes a tactical necessity. We must detach from failed experiments as quickly as we create them.

Our Evolving Roles in the New Value Chain

AI is turning the "Build" and "Test" phases of software development into a commodity. The enduring human value, and therefore career security, lies at the extremes of the value chain: deeply understanding the "why" at the beginning and rigorously validating the impact at the end.

The bottleneck is shifting to the "fuzzy front end" (Opportunity Selection, Requirements Planning) and the "validated back end" (Running the system, Validating impact, and gathering Feedback). This highlights two critical skill areas for the future.

First, a product mindset. We need to deeply understand the problem, its context, and its intended impact. The challenge is no longer "is the code good?" but "does the system achieve the desired effect?"

Second, architectural and engineering practices. The responsibility for the system's results doesn't disappear; it intensifies. Skills in architecture, security, scalability, and performance become more critical because we will be making these decisions more frequently. AI can accelerate code generation, but the system will collapse without sound modularity and simplicity.

We Are All Beginners Again

Here's the uncomfortable truth: no matter how many years you have in this industry, we are all beginners in the Age of AI-augmented software delivery.

I've been doing this for about 30 years. That experience gives me some advantages: pattern recognition, intuition about what might work, the confidence to experiment without fear. But it doesn't exempt me from the uncertainty. When I'm pair-programming with Claude, I'm learning just as much as someone who started coding last year. The difference is that I have the luxury to be wrong, to throw away experiments, to admit I don't know.

But what about the people entering our field right now? They're walking into the most turbulent period our profession has ever seen, at a moment when the rules are being rewritten in real time. We, the experienced ones, have a responsibility to them that we cannot abdicate.

We must create safe spaces where they can learn without fear: on our teams, at local meetups, in conferences. We must share our experiments, even the failures. We must run hackathons where we figure this out together, just as we did with unit testing and Agile practices in the early 2000s. The difference is that now, the experienced among us must actively lower the barriers for those just starting, because the barriers are higher than they've ever been.

This is not charity. This is survival. If we hoard knowledge, if we gate-keep, if we let newcomers drown in the chaos, we will not have a community strong enough to fight for the soul of our profession. The consultants will win by default.

Our greatest strength has always been our community. Now is the time to prove it.

Your Path Forward: An Action Plan

So, what can you do right now to prepare?

  1. Move down the food chain. Get closer to the customer and the problem. Don't just ask "what"—always ask "why." Understand the business impact you are trying to create.
  2. Evolve from specialist to generalist. The era of the generalist is here. You don't need to be an expert in everything, but you need to learn enough about adjacent disciplines to be effective. AI can fill in the deep, specific details (like framework syntax), but you need to connect the concepts.
  3. Imagine our future tools. We should be building our own AI agents, encoded with our community's knowledge. Imagine a "gardener" agent that refactors code overnight, a "garbage truck" agent that identifies and removes dead code, or a performance-tuning agent that pinpoints bottlenecks. These tools are within our reach.

Conclusion: We Can't Avoid the Storm, So Let's Surf the Wave

We have the greatest opportunity in the history of our profession to finally build software in "the forest," a place where technical excellence and business impact are perfectly aligned. This requires adopting a product mindset and being willing to reinvent our best practices. It means letting go of what we think we know about software delivery, accepting that AI agents will become teammates whether we like it or not, and leaning heavily on our community as we navigate this together.

Of course, I don't have all the answers, and it's not all sunshine. There are serious issues that we, as a community, need to confront: the addictive reward cycle of working with AI, the consolidation of power in a few large tech companies, the challenge of training junior developers, and the environmental impact. These are important topics for future discussion.

But we can't let these challenges paralyze us. The change is coming. We can't avoid the storm, and honestly, we don't want to.

I've made my choice. I'm experimenting, sharing my failures as much as my wins, and making space for others to do the same. But I can't do this alone, and neither can you.

So here's what I'm asking: will we, as a community, step up and shape this transformation? Will we create the spaces where we can learn and experiment safely? Will we build the tools that encode our values instead of waiting for someone else to define them?

Or will we let this moment slip away while we debate whether AI is "good enough" yet?

The wave is here. The question isn't whether to surf it. The question is whether we'll surf it together, or watch from the shore while others ride it for us.


About This Article

This article is based on my keynote "Desapego Radical en la Era de la IA" (Radical Detachment in the AI Era), delivered at Software Crafters Barcelona in October 2025. The talk was given in Spanish and has been expanded and adapted for this written version. You can watch the original keynote and access the slides at eferro.net.

References

Saturday, December 13, 2025

Good talks/podcasts (Dec)

These are the best podcasts/talks I've seen/listened to recently:
  • This Mental Model Changed How I Design Software FOREVER 🔗 talk notes (Emily Bache) [AI, Agile, Architecture, Mental models, tdd] [Duration: 00:09] (⭐⭐⭐⭐⭐) Applying the mental model of Test-Driven Development (TDD) as an empirical engineering approach to master software design and manage complexity alongside Agentic AI tools.
  • From here to there and back again 🔗 talk notes (Simon Wardley) [AI, Strategy, Technology Strategy] [Duration: 00:57] Simon Wardley introduces maps for strategic situational awareness, detailing how technological evolution, inertia, and the rise of AI impact decision-making and software architecture, emphasizing the challenge of deciding where humans maintain control
  • Who Does What by How Much? Customer-Centric OKRs explained with Jeff Gothelf and Josh Seiden #ccokrs 🔗 talk notes (Jeff Gothelf, Josh Seiden) [Agile, Company Culture, Management, Strategy] [Duration: 01:14] (⭐⭐⭐⭐⭐) Experts Jeff Gothelf and Josh Seiden detail how to define customer-centric Objectives and Key Results (OKRs) by focusing on measurable outcomes, encapsulated in the framework’s core question: "Who Does What By How Much?"
  • Jim Womack on Lean Thinking: Past, Present & Future 🔗 talk notes (Jim Womack) [Company Culture, Lean Manufacturing, Management] [Duration: 00:32] (⭐⭐⭐⭐⭐) Jim Womack offers a comprehensive retrospective and prospective view of Lean thinking, exploring its evolution, current relevance, and future potential for a "second lean leap".
  • Vibe coding in prod | Code w/ Claude 🔗 talk notes (Erik Schluntz) [AI, Agile, Continuous Delivery] [Duration: 00:31] A discussion on how to safely practice "vibe coding" (letting AI generate code while forgetting the code exists) in production by acting as the AI's Product Manager and focusing on verification of leaf nodes and abstraction layers.
  • Analytics for not-so-big data with DuckDB 🔗 talk notes (David Ostrovsky) [Data Engineering, Performance] [Duration: 01:02] A deep dive into DuckDB, an embedded analytical database optimized for running high-performance analytical queries on "medium data" (1-100 GB range) locally on a single machine, with seamless integration for Python and diverse data sources
  • The New Code — Sean Grove, OpenAI 🔗 talk notes (Sean Grove) [AI, Agile, Architecture, Devops] [Duration: 00:21] OpenAI's Sean Grove introduces "The New Code," arguing that specifications are the universal artifact of intent, crucial for aligning both humans and advanced AI models.
Reminder: All of these talks are interesting, even just listening to them.

You can explore all my recommended talks and podcasts on the interactive picks site, where you can filter by topic, speaker, and rating: Feedback Welcome!
Your feedback and suggestions are highly appreciated to help improve the site and content. Feel free to contribute or share your thoughts!
Related:

Custom GPTs: New Permanent URLs

Quick heads up: my Custom GPTs have new URLs after switching ChatGPT accounts. These should be the permanent ones.

All four GPTs are now available at their updated locations:

The functionality remains the same — only the URLs have changed. If you've bookmarked the old links, please update them.

You can find all my projects, including these Custom GPTs, at eferro.github.io.

Saturday, November 29, 2025

Cursor Commands Added to augmentedcode-configuration

I've just updated my augmentedcode-configuration repository with Cursor commands that codify my XP/Lean development workflows.

What's new:

Added .cursor/commands/ with 8 reusable command patterns:

  • plt-code-review — Review pending changes (tests, maintainability, project rules)
  • plt-increase-coverage — Identify and test high-value untested paths
  • plt-plan-untested-code — Create strategic plans to close coverage gaps
  • plt-predict-problems — Predict production failure points proactively
  • plt-technical-debt — Catalog, classify, and prioritize technical debt
  • plt-mikado-method — Apply Mikado Method for safe incremental refactoring
  • plt-xp-simple-design-refactor — Refactor using XP Simple Design principles
  • plt-security-analysis — Pragmatic security risk assessment

Purpose:

These commands codify recurring workflows as reusable patterns. Instead of ad-hoc prompting, they provide consistent guidance for the AI to:

  • Work in small, safe steps
  • Focus on tests and maintainability
  • Apply Lean/XP principles
  • Follow project-specific conventions

They work alongside the existing base rules, creating a more complete configuration for AI-augmented development.

👉 Check them out: .cursor/commands/

This is an update to my original post: My Base Setup for Augmented Coding with AI

Perverse Incentives, Predictable Results: When Your System Sabotages Your Teams

It's a strange paradox. It took the manufacturing industry 50 years to move past the ideas of Frederick Winslow Taylor, known as Taylorism or Scientific Management. Yet in software development, a creative, knowledge-based discipline where these ideas are least effective, we continue to apply them universally.

Taylorism in a software context is the practice of maximizing the local utilization of each individual. We treat people like resources in a factory, keeping them 100% busy with their specialized tasks. This creates a cascade of perverse incentives that actively undermine collaboration, destroy flow, and cripple the efficiency of the entire system.

This article explores the three most common traps this thinking creates and offers a practical, systemic path toward improvement.

1. The Trap of Resource Efficiency

The Core Fallacy

Most organizations are obsessed with individual performance and 100% resource utilization. The goal is to keep every person busy all the time, believing this equates to maximum productivity. However, basic queueing theory teaches us that running any system at full capacity only generates blockages, chronic bottlenecks, and massive wait times. As a wise colleague once said, "If we optimize locally, in most cases we make everything worse."

The Connection to Taylorism

This is a direct application of Taylorism: maximizing the utilization of each "human resource" locally. We decompose work, assign it to specialists, and measure them on their individual output, ignoring the devastating impact on the system as a whole.


The Consequences

When you incentivize local optimization, the negative results are entirely predictable.

  • Perverse local incentives: We reward metrics that are easy to measure but destructive to the whole. This includes rewarding a high number of commits, celebrating people for "being 100% busy," or lionizing "heroes" who constantly put out fires.
  • Predictable negative results: These incentives inevitably lead to chronic bottlenecks, constant rework (also known as "failure demand" because you're fixing things that failed the first time), and a toxic hero culture where knowledge is hoarded and collaboration is discouraged.

The Alternative: Flow Efficiency

The antidote to this trap is shifting our focus from resource efficiency to flow efficiency. The book This is Lean explains the difference well.

  • Resource Efficiency: This is a process where work is handed off between specialists in silos. To keep each specialist busy, a queue of work forms before each handoff. From the customer's perspective, this is incredibly inefficient, as their request spends most of its time waiting in a queue.
  • Flow Efficiency: This is a team-based approach where everyone collaborates to finish a single piece of work. There are no "my parts." The team owns the work from start to finish. This delivers value to the customer much faster and eliminates the immense waste and rework inherent in siloed handoffs.

2. The Trap of Disconnecting from "Why"

The "Feature Factory" Anti-Pattern

A common anti-pattern is the "feature factory," where teams operate like an assembly line. Someone defines requirements, others implement them, and no one on the team connects with the customer or the actual impact of the work. Success is measured by output, not outcome.

The Connection to Taylorism

This is another core tenet of Taylorism: the rigid separation of "thinkers" from "doers." It promotes the unquestioning execution of specifications, regardless of whether those specifications actually solve a real customer problem.

The Predictable Results

Building without a clear purpose has disastrous and wasteful consequences.

  • Irrelevant products: Features are built that nobody uses.
  • Wasted talent: People work hard on things that simply don't matter.
  • Unnecessary complexity: Technology is over-engineered without a connection to a real-world need, creating a massive maintenance burden.

Advocate for Empowered Teams

The alternative is an empowered product team that deeply understands the purpose of its work: what problem they are solving, for whom, and why. These teams don't just blindly follow specs; they adapt solutions to meet real user needs, achieving far greater impact and velocity with less effort.

The Evolution to a Product Team

The journey from a siloed, handoff-driven process to a true product team is an evolution. An effective model shows the team's boundary of collaboration expanding across the entire value stream. In a traditional Waterfall model, each step (Opportunity Selection, Design, Build, Test, Release, Run) is a separate silo. In an ideal Product Team, the entire team collaborates across the whole process, from identifying the opportunity to operating the solution and learning from its impact.

3. The Trap of Deferred Quality

The Core Myth

There's a false dilemma that pits quality against velocity. We're taught to believe there's a tradeoff: you can be "fast without quality" or "slow with quality." This is a foundational myth in our industry.

The Truth

The data is clear. As shown in years of research from the Accelerate/DORA reports, the highest-performing teams have both high quality and high speed. The truth is: Quality does not compete with velocity; it enables it. Of course, context matters. A one-shot script, an MVP, or a proof of concept have different quality constraints than a core product. But for any sustainable product development, building quality in from the start through practices like testing and fast feedback is the only path to sustainable speed. A low-quality approach leads to a progressive slowdown as technical debt and failures accumulate.

The Connection to Taylorism

This myth is a direct descendant of a Taylorist mindset. It treats productivity as a measure of immediate outputs, ignoring sustainability. Quality is seen as a separate, final inspection phase, rather than something built into the process from the beginning.

The Negative Cycle

This mindset creates a system that actively discourages quality.

  • Perverse Incentives: The system rewards behaviors that produce low quality. We celebrate heroes who fix crises (often of their own making), equate long hours on weekends with commitment, and reward improvised hacks that create future problems.
  • Predictable Results: The consequences are severe and unavoidable. Teams are trapped in a cycle of chronic firefighting. Technical debt grows relentlessly, and the organization suffers from a high rate of talent drain as good people flee the constant chaos.

4. The Path Forward: Systemic Improvement

As W. Edwards Deming taught, over 90% of an organization's performance is a result of the system, not the individuals within it. The responsibility of management is not to blame people but to change the system so that work can flow and people can grow.


Here are actionable strategies to start changing your system.

Lead by Example

As a manager, you must model the behaviors you want to see. If you want teams to write tests, you should write tests. If you want them to refactor, you refactor. Make the desired behaviors visible and celebrate them publicly. Your job is to improve the system, not to find culprits.

Embrace Blameless Postmortems

Analyze incidents and errors transparently with the sole purpose of finding and fixing systemic weaknesses. The goal is to learn and improve, not to assign blame. When the system allows a mistake to happen, the focus must be on strengthening the system.

Show Vulnerability to Build Safety

To create an environment of psychological safety where people feel comfortable highlighting problems, leaders must be the first to show vulnerability. I often share my own past mistakes like the time I took down the phone system for an entire town or made a critical DNS error. Sharing these stories openly shows that errors are a part of work and that the important thing is what we learn from them.

Hack Your Performance Reviews

Traditional performance reviews are often toxic, reinforcing the individualistic, Taylorist mindset. If you are required to use them, hack them. Sometimes you must reinterpret corporate-level mandates to create the right local incentives. Subordinate individual accomplishments to the person's contribution to the team's overall impact. Focus on how they helped the team succeed, not just what they did on their own.

Build End-to-End Ownership

Create cross-functional teams that own a problem from end to end. This often means fighting against the silo mentality. A strategy I've used is to have my team actively take on more work (like operations or QA tasks) to eliminate external dependencies. This gives the team full control, deepens their knowledge, and allows them to optimize for the entire value stream.

Redefine 'Done'

A task is not "done" when the code is committed. It's not "done" when it's deployed. Work is only truly "done" when its impact on the customer has been validated with real feedback. This reinforces a product mindset and focuses the team on outcomes, not just output.

Hire for Mindset

Prioritize mindset and attitude over a checklist of specific technical skills. You can teach someone a new programming language; it's much harder to teach them that quality is their responsibility.

  • Product Thinking: Ask product management questions in interviews, like "What products do you admire and why?" or "How would you measure the impact of this feature?" Invite product managers into engineering interviews to help assess this.
  • Collaboration: Assess real collaboration, not just talk. When possible, have candidates work with the team for a day (in a paid, respectful way) on a real problem.
  • Flexibility: Your career path must reward generalists who provide flexibility, not just specialists.

Master Your Workflow with Kanban

Many teams use Kanban boards, but few use them correctly as a pull system. The three most important rules are:

  1. Use WIP (Work In Progress) limits. This is the simplest and most powerful way to optimize flow.
  2. Read the board from right to left. During stand-ups, review the work, not the people. Start with what's closest to being "done" (validated impact) and work backward. The focus must always be on finishing work, not starting new work.
  3. Use slack to unblock. When WIP limits leave someone without an immediate task, they should not pull new work. Their job is to help colleagues with open tasks, unblocking work further down the chain.

Reducing Resistance by Turning Change Into Experiments

The status quo naturally resists change. To move forward, we need to build the capability to generate change continuously, not just through occasional big initiatives. Approaches inspired by Lean Change Management can help: make small, frequent adjustments, learn quickly, and evolve based on evidence rather than assumptions.

One powerful tactic is to present changes as experiments. Framing them this way reduces resistance, creates psychological safety, and encourages people to engage with curiosity rather than fear. Even when the goal is meaningful transformation, breaking it into small, testable steps makes progress far more sustainable.

Define clear success criteria and a limited timeframe. This lowers resistance and allows you to validate ideas with data. As Grace Hopper famously said, “It’s easier to ask for forgiveness than it is to get permission.”

Conclusion: A Better Way to Work

A bad system will always defeat a good person. The Taylorist principles so common in our industry create systems that are destined to fail, leading to wasted effort, frustrated teams, and mediocre results.

We are discovering better ways to work. Through this experience, we have learned to value:

  • Collaboration and shared responsibility over heroes and a culture of blame.
  • Global optimization over local efficiency and specialized silos.
  • Significant impact and results over occupation and "being busy."
  • Autonomy with purpose over rigid control and supervision.
  • Continuous learning and adaptation over predefined and static processes.

By focusing on changing the system instead of blaming the people, we can create environments where teams can truly thrive and deliver exceptional value.

Management frameworks and their impact on software development.

Further Reading and Resources