Designing for Emergence
Practice-level standards and interface-level standards aren't equally risky. Designing for emergence means knowing which is which and giving practices room to evolve before they become standards.
The mapping tool is descriptive. It shows you the system — what your framework has done to the constraints your teams work under. But the reason to map is to make better choices about how to work. This is for the people making those choices: senior practitioners, leaders, coaches who can shape the design.
The core idea, in one line: frameworks and standards often place team-level practices in the high-cost-to-change or long-time-to-change quadrant, removing teams’ decision-making control over them. Anything introduced in that fixed quadrant as a standard is risky. Everything needs to take an experimental, feedback-based approach. Some things, like interface standards between teams, can be more stable — they exist for coordination, not prescription.
Standards at the Right Level of Granularity
Not all standards are equally dangerous. The risk is in practice-level standards — the things that govern how a team works internally: its stand-up format, its sprint length, its definition of done. These are decisions the team can only make well by doing the work. Prescribing them upfront assumes knowledge that doesn’t exist yet.
Interface-level standards are different. When two teams need to coordinate — when one team’s output becomes another team’s input — there has to be a contract between them. The format, the timing, the expectations. These standards can be specified upfront because coordination requires them. They’re not prescriptions of how the work should be done; they’re agreements about how the parts of the system will connect.
The mistake is treating practice-level standards like interface-level standards: locking in the how of a team’s work with the same weight as the contracts between teams. When a framework does this, it’s prescribing a team’s internal life. The team loses the ability to discover what works for them.
Design for Emergence, Not Prescription
The choice between high-trust and low-trust is foundational. A system is built as high-trust or low-trust from the start, through the standards it sets, the authority it grants, and the space it leaves for teams to figure things out.
If the goal is sensing — teams that adapt, pay attention to context, develop best practices through experience — then the design has to leave room for sensing. That means:
- Starting more fluidly. New practices and ways of working belong in the volatile, low-cost quadrant until they’ve been tested. The grid is a tool for seeing whether a practice is fluid or fixed. The principle is to keep it fluid until there’s evidence it should be otherwise.
- Giving people space to adapt. A team that knows it can change its practices will develop the muscle of changing them. A team that knows its practices are fixed will develop the muscle of following them.
- Letting best practices emerge. When a team tries something and it works, other teams can adopt it. When a pattern proves itself across multiple contexts, it becomes a candidate for standardization. The standardization comes from the evidence, not the other way around.
The evolution band is the low-to-medium range of the grid — practices that are changeable enough to adapt but stable enough to learn from. This is where teams need to stay long enough to test, refine, and discover what actually works. Promoting too early locks in untested standards. Staying too long in pure volatility means there’s nothing stable to evolve from.
What the Senior Practitioner Takes Away
If you’re a senior practitioner or leader, the mapping tool gives you a way to see the system you’re designing. The grid shows you what your framework has done. The dimensions show you why it has those effects. The argument shows you that some of those effects are choices you can make differently.
The choice is not “use a framework” or “don’t use a framework.” It’s which constraints belong in the high-cost quadrant and which belong in the low-cost quadrant. It’s how you design for the kind of team you want — one that follows standards, or one that figures things out.
The goal is to make those choices deliberately, with the people who’ll live with them, and to leave room for the system to adapt when the choices need to change.
The grid doesn’t tell you what to do. It tells you what your framework has done. The rest is judgment — but now the judgment has a map.
Malcolm Bastien
Enterprise Agile Coach
Enterprise Agile Coach helping leaders in Fintech, Banking, and HealthTech build fast flow through systems thinking and aligned autonomy, empowering teams to deliver high-performance results at scale.