Conscious Agility

If lean is no longer adequate as the default operating model for a business, the natural next question is what should actually replace it, and Conscious Agility is the answer I have ended up working with for some years now. I originally developed the framework in 2019, as part of the wider Sensandu project, and it predates the Conscious Collaboration whitepaper by a few months. The underlying mechanics have changed surprisingly little in the time since I first sketched them out.

The framework is essentially an attempt to answer a specific question that comes up rather often in my conversations with senior leadership teams: how does a business actually become adaptable, not just in the parts of it that happen to be running software teams, but at the organisational level as a whole, and without losing the operational discipline that has been built up over the preceding years of work?

This isn’t really the same thing as “Agile”

It is probably worth clearing this up at the start, because the two get conflated rather often. Agile, with a capital A, was developed back in 2001 as an approach to software development specifically, and the opening line of the original Agile Manifesto is rather revealing on the matter: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” It was never intended as a general-purpose business operating model; it was essentially a way of building software in small teams that could respond more quickly than the heavyweight waterfall projects which had dominated the previous decade.

A number of businesses adopted Agile anyway, applied it more widely than its authors had intended, and were eventually disappointed by the results. The reason for this is fairly visible in the manifesto itself once you read it carefully. Agile assumes a single team working on a single product for a single customer, and its operating mechanics, sprints, stand-ups, retrospectives, product owners and so on, do not really translate cleanly to a marketing function, or a procurement function, or a senior leadership team trying to set strategy. Deploying Agile, in other words, does not necessarily make your organisation agile.

What businesses actually need is adaptability at the organisational level, which is what Conscious Agility is designed to provide. The software teams in the business can carry on using Agile if it suits them, and Conscious Agility is essentially the layer above that, the level at which the rest of the business needs to be operating with comparable responsiveness in order to keep pace with the software teams it is trying to direct.

The four capabilities the framework introduces

Conscious Agility introduces four capabilities that are intended to work together, and that between them make a business genuinely responsive without breaking the operational efficiency it has already managed to build up. Each one of the four has its own corresponding process underneath it, along with a way of measuring whether the capability is actually functioning in practice or merely declared.

Sensing is the deliberate, structured scanning of the wider environment for signals that genuinely matter to the business, and this is rather broader than the conventional definition of market research. It needs to cover customers, competitors, regulators, technology, suppliers, the geopolitical landscape, the talent market and the academic frontier of whatever domain the business happens to operate in. In most businesses I have seen, sensing of this kind is left as the implicit job of whichever senior leaders happen to read the news regularly, which used to work tolerably well in calmer environments but reliably does not now.

Prioritisation is the discipline of deciding what to do with a signal once you have one, on the basis that not every change in the environment actually matters and some changes that matter enormously to one part of the business will not be relevant at all to another. The hard part of prioritisation is preventing the loudest signal in the room from drowning out the most consequential one, and the Cynefin framework is one of the cleaner tools I have come across for sorting that question out in a structured way.

Collaboration is the structured way that diverse teams work together to produce a response to whatever signal has been prioritised, and the Conscious Collaboration framework essentially lives inside Conscious Agility at this point in the flow. Collaboration is what turns “something significant has happened” into “here is what we are going to do about it,” and without it the rest of the pipeline produces signals that lead nowhere actionable.

Realisation is the business of actually executing the chosen response, with the same operational discipline that the lean parts of the business already use. The aim here is not to break operational excellence in the name of being more agile; the aim is to give that operational excellence work that is genuinely worth doing.

How signals flow through the organisation

The pipeline starts at the boundary between the organisation and its environment, and the eyes and ears at this point are the people, dashboards, partners and sensors that pick up signals from outside the business. One of the more common mistakes I see is putting all of these capabilities into a single function, typically a strategy team or a market-intelligence group, with the rest of the business positioned as the eventual recipient of curated reports produced by that one team.

This pattern tends to fail for two distinct reasons that compound each other. It is slow, because every external signal now has to pass through a translation layer before anyone with operational authority sees it, and it is also biased, because the translation layer naturally selects for the kind of signals that it already knows how to describe rather than the ones that don’t fit its existing vocabulary. A genuinely adaptable business distributes the eyes-and-ears function across customer-facing staff, technologists, finance, partners and leadership, with the collaboration layer underneath playing the role of stitching their observations back together into something coherent.

In the original Sensandu work I called the discipline that operates at this boundary “crystal boundaries”, and the image behind the term is of a permeable but structured surface. Signals pass through it, but they pass through carrying the structure that makes them usable on the other side, not a wall, which would prevent signals passing at all, and not a sieve, which would let them through but strip away their context on the way. In practice the crystal-boundary discipline means having an explicit format for how an observation moves from the person who originally saw it to the team that has the authority to act on it. Without that format in place, signals either die at the boundary or arrive on the other side without enough context to be useful.

The next stop is the collaboration tool, by which I mean both the digital platform itself and the human structure that sits around it. Distributed teams need somewhere they can compare what they are each seeing, and the flow needs to be bi-directional in nature; the information consumers cannot simply be passive recipients, they need to be able to flag, question and amplify the signals they are receiving. The point of doing this work in the open, rather than behind closed leadership doors, is to surface the relevant assumptions before they have time to harden into convictions that the team feels it cannot walk back from. Which signals are we ignoring because they don’t happen to fit our existing model? Which signals are we over-weighting precisely because they happen to confirm it?

The “does it matter?” step is where Cynefin earns its place in the framework. The same signal can land in rather different problem domains depending on what the business happens to be doing at the moment it arrives. A regulatory change might be obvious in nature (here is the new rule, comply with it), or complicated (here is how it interacts with our existing structure, and we will need some time to work the implications out), or genuinely complex (it changes the strategic landscape underneath us, and we will need to run experiments to discover the right response), or chaotic (we have to act this week or we lose the licence to trade). Knowing which of these we are looking at is what makes the eventual response appropriate to the situation rather than reflexive.

Decisions tend to come out the bottom of the pipeline in one of two directions: either to respond, or to watch for trends. The watch-for-trends path is, in my experience, the one most easily neglected, and that is a problem in itself, because a single signal that does not individually appear to matter may turn out to be one of three signals that together describe a structural shift in the environment. Without an explicit organisational place for that kind of patient observation, a business tends to oscillate between over-reacting to noise and missing real signals until they have become urgent and harder to address.

The innovation pipeline behind the responses

Once a signal has reached the respond path, it flows through a five-stage innovation pipeline that gives the response itself some structure. The objective-setting stage answers what the business is actually trying to achieve in response to the signal, before any specific solution is allowed onto the table. Problem and opportunity exploration investigates the landscape around the signal, looking at where the real space for action might lie. Idea mining, which I describe in detail in its own piece, extracts candidate ideas from the knowledge base the business already has access to. Idea refining is the smelting step in which those candidates get ranked, viability-checked and costed properly. And idea realisation is the actual execution of whichever response has been chosen.

The reason the pipeline matters at all is that innovation efforts in my experience tend to fail at the boundaries between stages rather than at the underlying activities themselves. Exploration tends to wander without a clear objective in place; the mining stage produces ore that nobody bothers to smelt; refined ideas pile up because nobody has clear authority to land them in the operating business. Naming the stages explicitly is what allows a leadership team to diagnose which boundary is actually broken in their particular case. Almost every “our innovation function isn’t working” complaint I have investigated has turned out to be a boundary problem rather than a creativity problem.

The maturity stages a business grows through

Conscious Agility is not really a switch you flip on a particular day; a business grows through a sequence of maturity stages, each of which builds on the one before it.

1. Collaborative mindset. The starting point. People work together openly, listen actively, and treat diversity as a resource rather than a source of friction. Without this stage in place, nothing else in the sequence really lands.
2. Conscious collaboration. The point at which structured process snippets, supporting technology and a shared vocabulary make the collaboration repeatable and scalable across the business.
3. Conscious co-creation. The level at which collaboration actually produces work that genuinely combines the contributions of multiple parties, rather than merely consulting them in turn. New ideas at this stage come from the interaction itself, rather than from any single individual involved.
4. Conscious agility. The final stage, in which the business can re-form teams, re-prioritise objectives and re-shape responses faster than the surrounding environment changes around it. Adaptability has become structural rather than heroic.

Plenty of businesses sit at stage one or stage two without really realising it, and the leap that matters in practice is the one between stages two and three, which is the transition from well-run collaboration to genuinely shared creation. That particular leap is mostly about trust between team members and rarely about technology, however much technology gets blamed when the transition fails to happen.

The boundary between lean and adaptable is the hard part

The most common practical failure mode of Conscious Agility, in my experience, is the one I describe in more detail in Lean is Dead. The lean-operations parts of the business absorb the adaptable parts because the adaptable parts tend to look chaotic from the outside, and the adaptable parts then atrophy under the pressure of being assessed against operational metrics that don’t suit them. Three moves help to keep this from happening in practice.

Make the boundary explicit at the operating-model level. Some functions in any given business are deliberately lean, supply chain, financial controls, compliance, platform reliability and so on. Others are deliberately adaptable, including product strategy, partnerships, innovation, R&D and most of what counts as strategy. Letting both groups run from the same playbook is essentially what happens when the operating-model template doesn’t leave any space for the difference between them, and the result is reliably that one set of behaviours quietly drives out the other.

Use different metrics on each side of the boundary. Lean metrics, such as cycle time, defect rate and cost per unit, will reliably punish the adaptable functions for behaviours that are actually necessary in their particular domain. Conversely, adaptable metrics like sense-to-decision time, options generated or experiments completed will be essentially meaningless when applied to a lean function. Using a single set of metrics for both sides effectively tells the organisation that one of the two regimes is wrong, even when neither of them is.

Staff the boundary itself deliberately. The people who can operate effectively at the boundary, translating between the two regimes, are genuinely rare and worth retaining at some cost. They are usually leaders who came up through one side of the boundary but happen to have spent enough time on the other side to understand its underlying logic from the inside. A good CTO tends to be one of these people, and so does a good operations director.

The situations where I tend to use this most

There are two situations that come up rather often in my work where Conscious Agility turns out to be particularly useful. The first is the turn-around, and the second is the growth transition.

A business that has plateaued for reasons nobody can quite explain has almost always lost its sensing layer in some way; it is essentially responding to the environment it had when it was last growing, rather than to the environment it now lives in. A scale-up that is bumping into its operational limits has almost always lost its collaboration layer, in a different way; the founders used to be the connective tissue holding the place together, and there are now too many people for that to keep working without something more structured being put in place.

In both situations the diagnosis tends to come from the pipeline diagrams above. Where is sensing actually failing? Where is the “does it matter” conversation no longer happening? Which stage of the innovation pipeline has broken down? Once the failure can be named precisely, the intervention itself is usually not particularly hard to design and execute. The hard work, in practice, is the naming, which is why having a framework with explicit language for every step turns out to be more valuable than it might appear.

Conscious Agility is an unglamorous framework in its own way. It does not promise transformation by Tuesday, and it does not lend itself to a particularly compelling keynote. It does, however, promise that a business can be both efficient and responsive at the same time, and in the operating environment we now find ourselves living in, that particular combination is the one that decides which businesses are still around in a decade and which are not.

Related: Conscious Collaboration · Cynefin and Conscious Collaboration · Idea Mining · Lean is dead · all writing