How to Build on your Diagnosis and Design Experimental Interventions

Organizational systems usually struggle because they introduce practices without being clear about what those practices are supposed to accomplish. Take retrospectives as an example. Two teams can hold exactly the same meeting every two weeks and walk away with completely different outcomes. One team uses the time to examine difficult decisions, challenge assumptions and improve how they work together. The other treats it as another recurring calendar invitation. The difference isn't the retrospective itself. It is what the team expects the retrospective to achieve.

Principles Before Practices

The same is true for almost every organizational practice. Pair programming, Three Amigos, Architecture Reviews, Business Impact Mapping or Communities of Practice are not valuable by themselves. They are attempts to strengthen something else. Better understanding. Faster information flow. Deliberate decision-making. Learning. Trust.

In the previous guide we spent a considerable amount of time diagnosing organizations through six dimensions. The purpose of that model was never to recommend interventions directly. It was to identify capabilities that appear weak relative to the organization's objectives. Once that diagnosis exists, the dimensions stop being descriptive and become design constraints.

If the diagnosis suggests weak Understanding, there are dozens of interventions that might help. Three Amigos is one. Job Stories are another. Business Impact Mapping might be more appropriate in one organization, while direct customer conversations would be a better investment in another. The intervention itself matters far less than whether it genuinely develops the capability we identified as missing.

What we can observe from the outside are practices. We see standups, team topologies, planning rituals, documentation standards or engineering ladders. We almost never observe the capability those practices are supporting, because by the time an organization is functioning well, many of those behaviors have become unconscious. People stop thinking about why they do them.

When another organization attempts to reproduce the visible practices, they often discover that nothing much changes. Not because the practices are ineffective, but because they solved a problem the second organization never had. The real constraint was somewhere else entirely. By the time we reach the intervention stage, the question "Should we introduce practice X?" has almost disappeared. A much more useful question has replaced it.

Which capability are we trying to strengthen?

The answer to that question rarely dictates a single intervention. More often it eliminates dozens of inappropriate ones.

Every Intervention Is an Investment

Every intervention has a cost. Sometimes that cost is obvious. New tooling requires money. Training consumes time. Reorganizing teams disrupts delivery for weeks or months. Other costs are easier to overlook. Every new meeting consumes attention. Every new process asks people to make one more decision. Every additional approval slows someone down. Even successful interventions demand focus that could have been invested elsewhere.

Because of this, organizations often ask whether an intervention is worth the cost. It is a sensible question, but I have found it more useful to ask something slightly different.

What capability are we buying?

Thinking about interventions as investments changes the conversation. Suppose a team decides to introduce pair testing. If the objective is simply to find more defects during the next release, the return on investment may be disappointing. The additional coordination takes time and the first few sessions often feel awkward.

If, however, the objective is to improve how knowledge moves through the team, the picture changes completely. Every pairing session becomes an opportunity for tacit knowledge transfer. Engineers become familiar with parts of the product they rarely touch. Testers gain a deeper understanding of implementation. Junior colleagues are exposed to how more experienced people approach uncertainty. The immediate outcome is only one part of the return. The organization itself becomes more capable.

The same thinking applies far beyond testing. Business Impact Mapping is rarely justified because creating diagrams is inherently valuable. It is valuable because it helps people reason about customer value together. Communities of Practice are not established to fill calendars with recurring meetings. They exist because they allow knowledge to spread beyond individual teams. Rotating engineers between products temporarily slows delivery, but gradually removes dangerous concentrations of knowledge.

This requires a degree of patience that many organizations struggle with. Delivery metrics often reward immediate output, while capability grows slowly and is difficult to measure directly. The temptation is to postpone investments until there is "more time." There rarely is.

I have become increasingly comfortable accepting small, deliberate reductions in short-term performance when they create lasting organizational capability. A senior engineer who spends time mentoring others will probably write less code this quarter. A product manager who invests more time with engineering teams will attend fewer meetings elsewhere. A team experimenting with a new way of working may deliver slightly less while they learn.

None of this removes the need for urgent decisions. Organizations still experience outages, deadlines and crises. The point is not to avoid optimizing for today when today genuinely demands it. The point is to recognize when temporary trade-offs quietly become the permanent operating model. That is a systemic issue demanding an intervention of its own.

They are investments. Like any investment, they should still be questioned. Not every capability is equally valuable, and not every intervention produces the return we hope for. Organizations make investments all the time. Some are visible in budgets and project plans. Others are hidden inside everyday decisions about who attends a meeting, who reviews a pull request, who responds to an incident or who gets assigned the most difficult work. The important part is making the trade consciously instead of accidentally, as they quietly determine what the organization will be capable of a year from now.

Change Environments, Not People

Organizations spend an extraordinary amount of effort trying to change people. We ask engineers to communicate more. We encourage product managers to write better specifications. We expect leaders to delegate more effectively. We send people to training, organize workshops and publish guidelines describing the behaviors we would like to see. Sometimes these interventions help. More often, they produce temporary improvements before people gradually return to doing what they had always done.

People often push back against change, but I don't believe this happens because people dislike change in principle. I believe that most organizational behavior is rational once you understand the environment producing it. 

An engineer who avoids asking questions may not lack curiosity. They may have learned that every interruption is treated as a nuisance. A product manager who writes excessively detailed specifications may have spent years defending every decision in endless review meetings. A team reluctant to take ownership may have discovered that ownership simply means becoming responsible without gaining any authority.

This has fundamentally changed how I approach interventions. Whenever I catch myself thinking that a group of people simply needs to "behave differently," I stop and ask a different question.

What makes the current behavior the sensible choice?

Organizations often ask people to innovate while punishing failed experiments. They promote ownership while requiring every meaningful decision to pass through multiple approval layers. None of these contradictions are intentional, yet they quietly shape behavior far more effectively than mission statements or leadership presentations ever will.

People adapt remarkably well to the systems around them. When the environment changes, behavior usually follows.

>> Consider two teams. One team rarely experiences significant changes once implementation begins and generally delivers predictably. Other teams struggle with constant uncertainty. Features change midway through development, assumptions surface late and frustration grows.

It would be easy to conclude that the successful engineers simply communicated better. Instead, when we observe closely, we will learn that whenever uncertainty appears, the product manager makes themselves proactively available. Questions are answered quickly. Small conversations happen naturally throughout the day. Nobody waits for the next refinement session because there is no penalty for asking.

The engineers certainly contribute to this dynamic, but the environment is enabling it. If I wanted the other teams to behave similarly, asking engineers to "communicate more" would have been the hardest possible intervention. Changing the environment is considerably easier. Product managers could deliberately create opportunities for those conversations long before engineers developed the confidence to initiate them consistently themselves. <<

This is one of the reasons I have become increasingly skeptical of interventions that begin with training. Training certainly has its place, particularly when people genuinely lack knowledge or technical skill. More often, however, organizations already know what good looks like. They simply operate inside systems that make the desired behavior expensive, risky or inconvenient. Changing the environment often removes obstacles that training was never going to overcome.

This perspective has also made me more careful when evaluating successful teams. When one team consistently outperforms another, the obvious temptation is to copy their habits. Sometimes that works. Just as often, those habits are merely adaptations to an environment that nobody else shares. Understanding the environment explains far more than observing the behavior alone.

Design Experiments, Not Solutions

One of the easiest mistakes to make after diagnosing a problem is believing that you now know how to solve it. Organizations are complicated enough that multiple explanations often fit the same observations. Teams deliver late because requirements change. Or because they misunderstand the requirements they receive. Or because work is started before it is sufficiently understood. Or any number of other reasons, all producing remarkably similar symptoms while requiring completely different interventions. 

This is why I increasingly think of interventions as experiments rather than solutions. The purpose of an intervention is not only to improve the organization. It is also to learn something about it.

Suppose a team experiences frequent changes during implementation. One possible intervention is to improve specifications before development begins. More collaborative refinement sessions, stronger acceptance criteria or behavior-driven specification practices might all reduce uncertainty before implementation starts.

If those changes reduce mid-development scope changes, we have learned something valuable. If they don't, we have learned something equally valuable.

Perhaps the specifications were never the problem. Perhaps the business genuinely operates in a rapidly changing environment where decisions cannot realistically be made earlier. Those two situations may look almost identical from the outside, yet they lead to very different organizational choices.

>> A few years ago we decided to increase our deployment frequency. The intervention itself was straightforward: encourage teams to deploy more often.

The objective wasn't to deploy more often. It was to encourage smaller changes. Smaller changes reduce the likelihood of defects, limit the blast radius when something does go wrong and naturally support practices such as trunk-based development and feature flags. Deployment frequency was simply the easiest way to observe whether those behaviors were emerging. 

The intervention worked. Deployment frequency increased. Changes became smaller. Several engineering metrics improved exactly as we had hoped. One metric, however, moved in the opposite direction. Lead time increased. <<

A failed intervention is not necessarily a failed investment. An intervention that disproves a plausible explanation has reduced uncertainty. It has made the next decision more informed than the previous one.

This way of thinking also encourages restraint. When several interventions are introduced simultaneously, understanding becomes difficult. If communication improves, incidents decrease and delivery accelerates after half a dozen organizational changes, which one actually mattered? Which should be expanded? Which quietly consumed effort without contributing anything?

Organizations deserve the same discipline we routinely expect from product development. We would hesitate to release several unrelated product changes simultaneously if we wanted to understand customer behavior. Yet organizational change often proceeds exactly that way. New ceremonies, new reporting structures, new approval processes and new tools arrive together, making learning almost impossible.

Not every intervention can be isolated. Organizations are rarely tidy enough for controlled experiments. Sometimes broad organizational changes are unavoidable.

Whenever we have the choice, however, I prefer interventions that leave behind more understanding than we had before they began. Learning how the organization actually works is what makes future improvements possible.

Measure Learning, Not Just Outcomes

Every intervention should answer a question. Sometimes the answer is the one we hoped for. Sometimes it isn't. Both outcomes are useful, provided we know what we were trying to learn in the first place.

That makes measurement part of the intervention rather than something that happens afterwards. Suppose we introduce pair testing. Defect rates might decrease. They might remain unchanged. Neither result tells us very much on its own. Perhaps defects were never the primary benefit. Perhaps knowledge spreads more effectively between team members. Perhaps developers started thinking differently about testing. Perhaps conversations happened earlier. Perhaps onboarding became easier. Those outcomes are harder to measure directly, yet they may be the real reason to continue investing in the practice.

That isn't an argument against measuring outcomes or changing environments. Quite the opposite. Choosing what to measure is part of designing the intervention. This is a reminder that every intervention changes the system in more ways than we intended. Organizations adapt remarkably quickly, and sometimes the most interesting behavior is the one you never designed for.

>> After a bit of investigation, the explanation why lead time got longer on average became obvious. Engineers had started avoiding Friday deployments. If a change was ready late in the week, many simply waited until Monday rather than risk spending their weekend responding to an incident.

Nobody had told them to do this. Nobody was trying to manipulate the metric. They had simply adapted to the environment we had created.

The intervention improved several capabilities, but it also introduced a new constraint that we hadn't anticipated. <<

The temptation is to measure whatever is easiest to collect. But organizations rarely suffer from a lack of metrics. They suffer from measuring proxies without remembering what those proxies represent.

Deployment frequency is not valuable because deployments happen often. Cycle time is not valuable because work moves quickly. Escaped defects are not valuable because the number is low. They matter only insofar as they tell us something about the capability we are trying to build.

That also changes what failure looks like. An intervention that leaves every metric unchanged has not necessarily failed. It may have ruled out a plausible explanation. It may have revealed that the organization behaves differently than we expected. It may have shown that the capability we were trying to strengthen was never the limiting factor. Those are all useful results.

The opposite is true as well. An intervention that improves every dashboard while leaving the underlying capability unchanged is often a temporary success. Organizations have become remarkably good at optimizing metrics. They are considerably worse at asking whether the metric still represents what it was intended to measure.

Remove Before Adding

The usual tendency of people trying to fix a systemic issue is to add a new rule or process. A new meeting. A new approval step. A new checklist. Another dashboard. Another role responsible for coordinating everyone else.

Occasionally those additions are necessary. More often, they become permanent responses to temporary problems. They further complicate the systems.

Before introducing a new practice, it is worth asking whether something already in place is preventing the desired behavior. Organizations accumulate processes much more easily than they remove them. Every new intervention therefore competes with everything that came before it for people's attention, time and energy.

Removing something is rarely as visible as introducing it. Nobody announces that the organization successfully stopped doing something unnecessary. There is no launch meeting. No training session. No celebration. Yet some of the most effective interventions I have seen were precisely that.

A meeting disappeared because the decision had already been made elsewhere. An approval step vanished because nobody could explain what risk it was still reducing. A report stopped being produced because nobody had looked at it in months. Nothing new replaced them. The organization simply became easier to navigate.

That is one of the reasons I try to treat every intervention as provisional. If we are willing to introduce a new practice, we should be equally willing to remove it once it has outlived its purpose. Practices that once solved real problems can quietly become part of the next one.

This principle has found its way into my thinking outside of organizations as well.

>> For the past two years I have been designing a board game in my free time. More than once I found myself convinced that the experience was missing something. The natural response was always to add another mechanic, another rule or another exception. Each addition seemed reasonable in isolation, yet the game gradually became more complicated without becoming more enjoyable.

Every few months I would stop and deliberately strip the design back to its essentials. Not because the removed mechanics were bad, but because I no longer understood what the core of the game was supposed to be. Removing rules forced me to rediscover it.

After ten major iterations, the current version is also the simplest one. It captures the original design intent better than any of its more complicated predecessors. <<

That experience has reinforced a lesson I apply to organizations as well. If your instinct is to add control, challenge yourself to instead remove something first. Simplifying a system makes it easier to understand. Once the system is understandable again, deciding what truly needs to be added becomes much easier too.

Build Capability, Not Dependence

The most experienced engineer solves the hardest problem. The domain expert joins every important meeting. The manager approves every difficult decision. In isolation, these choices are often the fastest path to a successful outcome. Repeated often enough, however, they gradually shape the organization. Capability becomes concentrated. Knowledge becomes specialized. Certain people become indispensable, while everyone else has fewer opportunities to grow.

I was once told a story about a submarine returning to port. Several members of the crew were capable of docking it safely, but one engineer was exceptionally good at the maneuver. The captain could have asked that person to do it every time. Instead, different crew members took turns. Occasionally they made small mistakes. They needed guidance. Docking took a little longer. The objective was never to become better at docking that particular submarine on that particular day. The objective was to become an organization where many people could.

Organizations rarely become more capable by accident. Capability grows because someone deliberately accepts that today's performance is sometimes worth investing in tomorrow's understanding.

That investment is not limited to technical skills. Pair testing, shadowing, Communities of Practice, rotating responsibilities or deliberately assigning unfamiliar work all have something in common. They often reduce short-term efficiency while making the organization more resilient in the long run.

The temptation to optimize for today's work never disappears. Deadlines remain. Customers still expect results. There are moments when asking the expert to solve the problem is exactly the right decision. The question is whether that remains the right decision every time.

Over time, organizations become remarkably good at whatever they repeatedly choose to optimize. The only real choice is deciding what that should be.

Addendum: Since writing the previous guide, I have been asked repeatedly whether these ideas still apply in organizations increasingly built around AI agents.

So far, I believe they do.

Agents make different mistakes than humans, but they still act under incomplete understanding. They still optimize the incentives we create. They still develop specialized responsibilities, creating the same communication boundaries Conway described decades ago. They still require environments that reward admitting uncertainty rather than merely producing confident answers.

If anything, agentic development has reinforced my belief that diagnosis and intervention are fundamentally organizational disciplines rather than human ones.

I am certain we will build software differently in the coming years. I am far less convinced that we will need to understand organizations differently.