Deliberate Design

Outcomes Do Not Create Their Own Conditions

Organisations spend an enormous amount of time discussing outcomes. Better customer satisfaction. Better culture. Faster delivery. Stronger collaboration. Fewer incidents. Higher retention. Lower costs. The desired destination is usually clear. What receives far less attention is the environment required to make arrival likely.

A leadership team may announce that it wants greater ownership while retaining approval structures that punish independent judgement. It may ask teams to collaborate while rewarding local targets that make cooperation irrational. It may demand innovation while treating every failed experiment as evidence of poor performance. It may promise customers a more proactive relationship while funding only the work that becomes urgent enough to appear on an escalation report.

In each case, the organisation has described an outcome without creating the conditions that support it. The language may change, but the system continues producing roughly what it produced before. People adapt to the environment around them more reliably than they respond to slogans. They learn which decisions are safe, which behaviours receive recognition, which rules can be bypassed and where accountability eventually lands.

Leadership is the deliberate creation of the conditions that make the desired outcome the most likely outcome.

This definition matters because leaders rarely control the final result. They cannot guarantee that a transformation will succeed, a customer will renew, a deployment will work perfectly or a talented employee will remain. Enterprise environments contain too many dependencies, competing priorities and human decisions for certainty. Leadership does, however, influence probability.

A leader can clarify ownership before an incident. They can create governance before pressure arrives. They can fund learning before new responsibilities are assigned. They can make the right action easier than the convenient one. They can ensure that risks are visible, decisions are documented and the people affected by change help define what success means.

That is Deliberate Design. It is not a framework, a methodology or a demand for more process. It is a way of thinking about leadership. The desired outcome comes first. The next question is not simply what people should do, but what conditions would make that behaviour reasonable, repeatable and sustainable.

Every organisation has been designed. Some parts were designed intentionally. Others accumulated through years of temporary decisions, inherited tools, emergency workarounds and compromises that outlived the circumstances that created them. A process may exist because one customer once needed an exception. A reporting line may reflect a leader who left years ago. A control may have been removed to accelerate one project, while nobody noticed that it had also protected ten others.

The relevant question is therefore not if design exists. It is if the design is deliberate. Does the operating environment support the outcome leadership says it wants, or has the organisation become a collection of conditions that quietly pull in another direction?

When Governance Becomes Optional

One of the clearest examples I encountered involved production and pre-production deployments. We had defined requirements for changes moving through the Change Advisory Board process. My role included acting as the final gatekeeper for deployments affecting the customers I supported. When a change did not meet the agreed conditions, I did not approve it.

The purpose was not to create delay. Maintenance windows were one of our largest sources of severe incidents. Roughly four out of five Sev1 incidents were connected to changes made during those windows. Every failed deployment could bring hours of downtime, technical bridge calls, executive updates, customer disruption, rollback activity and a formal root cause investigation. The approval requirements existed because the organisation had already learned that preparation mattered.

Yet a rejected change often created an immediate inconvenience. The customer wanted to proceed. A project team had committed to a date. Someone now had to explain that testing, rollback preparation, staffing or another requirement was incomplete. Rather than have that conversation, the decision was sometimes escalated to someone more senior.

The escalation could eventually reach an owner or a senior vice president with little detailed knowledge of the deployment. A decision that had been reviewed by people close to the work could then be overridden in a minute. The change was approved, the awkward conversation disappeared and everyone appeared to have moved faster.

Until the Sev1 began.

At that point, the organisation had not gained the benefit of the rushed decision. It had spent twelve hours troubleshooting, disrupted the customer, exhausted technical teams, created an RCA workload and rolled the environment back to where it had started. The shortest approval had produced the longest path to the intended outcome.

What frustrated me most was that everyone understood the pattern. The relationship between maintenance windows and Sev1 incidents was not hidden. We repeatedly tried to reduce it. Yet customers learned that escalation worked. Senior leaders learned that approval ended the immediate disagreement. Account Directors learned that saying yes avoided personal friction, while saying no created another escalation they would have to defend.

Eventually the rational decision for the individual became the wrong decision for the organisation. In the United States, every Account Director eventually approved changes they believed should have been rejected. Stuart and I continued refusing in EMEA because we believed bypassing the requirements was wrong and because the consequences cost the company money. But the system made that position unnecessarily difficult to sustain.

People rarely ignore governance because they misunderstand it. They ignore it when the organisation rewards bypassing it.

The governance process had not failed technically. The surrounding conditions had undermined it. The organisation had created an escalation path where persistence could replace readiness. That taught customers not to resolve the issue that caused rejection, but to search for a person willing to approve it.

Senior overrides are sometimes necessary. A regulatory deadline, urgent security exposure or significant commercial commitment may justify accepting greater risk. Deliberate Design does not eliminate judgement by forcing every situation through an inflexible rule. It requires the exception to remain conscious. The people overriding the control should understand the risk, document the decision and own the consequences rather than treating approval as a way to avoid discomfort.

Governance is not the existence of a board, process or approval field. Governance is the organisation's willingness to respect why those mechanisms exist when doing so becomes inconvenient.

One Article That Changed Ownership

The recurring deployment problem became one of the reasons we created customer-facing knowledge articles. The first article documented the requirements customers were expected to meet before a deployment could be approved.

At first glance, this sounds like a modest knowledge-management task. One article in a larger programme. Yet if that had been the only article we produced, I believe the entire project would still have been worthwhile.

The article did not solve the behavioural problem. Customers could still escalate, and senior leaders could still approve an exception. What it changed was the quality of the decision trail. We could point to official, published requirements rather than relying on an Account Director's opinion or an internal message that the customer had never seen.

When a deployment failed to meet the standard, we rejected it and referenced the article. If the customer chose to escalate and insist on proceeding, we documented the override in our internal notes. The record showed the applicable requirement, why the deployment had been rejected, the risk that had been identified and the decision to continue despite that warning.

If the change succeeded, the record disappeared quietly into normal operations. If it failed and downtime became expensive, the governance discussion no longer began with competing memories. We could show that the requirement had been published, the deployment had been rejected and the customer had consciously chosen to override the recommendation.

Ownership and cost therefore landed with the party that had accepted the risk rather than automatically transferring to us after the incident.

The article was not merely documentation. It was a deliberately designed governance mechanism.

This distinction matters. Knowledge programmes are often measured through volume: articles written, pages viewed, search success or contributions per team. Those measures can be useful, but they do not capture the full value of a piece of knowledge that changes how the organisation operates.

That single article reduced time spent reconstructing decisions, arguing about responsibility and defending actions months after the event. It protected commercial positions, clarified customer expectations and made accountability visible at the moment it mattered. Its audience did not need to be enormous. It needed to exist, be official and connect directly to a decision process.

In another industry, the artefact might be a surgical checklist, an engineering tolerance, a signed risk acceptance, a quality specification or a safety procedure. Its value does not come from the number of words. It comes from the decisions it changes and the ambiguity it removes.

This is why Deliberate Design should not be mistaken for creating more paperwork. Poor documentation can add friction without improving outcomes. Good design places the right information inside the decision path. It clarifies expectations before pressure arrives, records exceptions when they occur and preserves enough context for accountability to remain fair afterwards.

The article could not force the customer to make the safer choice. It did something leadership can realistically achieve: it created better conditions for an informed decision and ensured that the ownership of that decision did not disappear when consequences arrived.

Slow Is Fast, and Fast Is Slow

One of my former managers often said, “Slow is fast, and fast is slow.” The phrase stayed with me because it describes a pattern that appears throughout enterprise work.

Approve the deployment immediately, then spend twelve hours troubleshooting a Sev1 before rolling back and returning to the starting point. Avoid the difficult customer conversation, then spend six months repairing trust. Skip testing to protect a release date, then delay the release by three weeks. Remove a proactive team to improve the current budget, then spend the following year firefighting incidents that capability once prevented.

On paper, every decision looked faster. In reality, every decision slowed the organisation down.

The problem is usually not speed itself. Fast execution is valuable when the route is sound. The problem is optimizing for the first visible milestone rather than the full outcome. Approval is treated as progress, even when readiness has not improved. A restructuring is declared complete when names disappear from the organisation chart, even though work, knowledge and customer obligations remain. A difficult conversation is postponed because the relationship feels calmer today, while the unresolved issue quietly becomes more expensive.

Experienced leadership takes a longer view of time. It asks not only how quickly an action can be completed, but how quickly the organisation can reach the desired outcome without repeatedly paying for avoidable failure.

The deliberate route may appear slower at the beginning because its investment is visible. Testing takes time. Clarifying ownership takes time. Training takes time. Challenging an unrealistic date takes time. The reactive route hides much of its future cost. It appears efficient until the failure, rework, customer recovery and management attention are counted.

This pattern is not limited to technology. A rushed patient discharge can lead to readmission. A skipped manufacturing quality check can lead to rework, scrap and recall. A construction team that accelerates foundation work can lose months correcting structural problems. An airline that treats a checklist as optional may save minutes while creating consequences that cannot be repaired on the same scale.

Deliberate Design does not argue that every activity should move slowly. It argues that leadership should distinguish speed from haste. The fastest organisation is not the one that approves everything immediately. It is the one that reaches worthwhile outcomes with the least avoidable rework.

That often requires leaders to tolerate small amounts of discomfort early. They must support the person who says a deployment is not ready, challenge the plan that has no realistic learning capacity and explain to a customer why an agreed control still matters. If leadership consistently rewards the people who remove immediate friction, the organisation will eventually become very efficient at creating larger friction later.

Designing Capability, Not Just Structure

The same principle becomes visible during organisational change. A financial target may require lower operating cost, but removing roles is not the same as redesigning the organisation.

I have seen reductions planned geographically, with each country expected to remove a similar proportion of employees. The spreadsheet was clear, but the customer experience was not organised by national headcount. Removing a Support Manager in one country did not remove the customers, approvals, escalations, knowledge and relationships that person carried. Those responsibilities moved to someone else, often without the time or support required to absorb them.

One colleague inherited responsibilities across several regions. On paper, positions had been consolidated. In practice, workload had multiplied beyond any sustainable level. The organisation had reduced roles while preserving almost all of the work. It had changed structure without deliberately redesigning capability.

That distinction matters because organisations measure roles while customers experience capability. A regional architect may appear as one line in a cost plan. The customer experiences familiarity with its environment, awareness of previous incidents, trusted relationships and the judgement to recognize when a situation is unusual. Remove the role without recreating those capabilities and the organisation may not see the loss until the next severe incident.

Knowledge transfer is often presented as the solution. Documentation is collected, handover meetings are scheduled and shared repositories are created. Those are useful activities, but knowledge transfer is not knowledge absorption. A person whose workload has doubled does not gain the capacity to read hundreds of pages simply because those pages now exist.

You can transfer documentation overnight. You cannot transfer judgement overnight.

Deliberate Design therefore asks a more complete set of questions. Which capabilities must survive? Who will own them? What knowledge is required? When will the new owner learn it? Which existing work will be removed to create that capacity? What customer relationships need an intentional transition? Which approvals, emergency decisions and invisible workflows depended on people who are leaving?

Without those questions, a cost reduction can follow a predictable sequence: people leave, workload rises, learning is postponed, capability declines, service slows, customer confidence weakens and the organisation eventually recruits again to rebuild what disappeared. The original savings may remain visible in one budget period while the replacement costs appear later across incidents, attrition, delayed delivery, service credits and lost renewals.

A deliberately designed reduction can begin with the same financial objective and produce a different path. Leadership can identify the work that no longer creates value, simplify approvals, redesign workflows, preserve critical capability, sequence transitions and create time for learning. The target may still involve difficult decisions and fewer people. Deliberate Design does not make those choices painless. It makes them more likely to achieve the intended result.

Culture operates in much the same way. A new leader cannot announce greater accountability, confidence or collaboration and expect the organisation to adopt it through willpower. People work inside the conditions leadership creates. If mistakes are punished inconsistently, information will be hidden. If speaking up slows careers, silence will become rational. If high performers receive only additional work, performance will eventually feel like a penalty.

Leaders do not simply implement change. They create the conditions under which change can succeed.

The Industry Changes. The Principle Does Not.

Deliberate Design is not an IT principle. Technology provides useful examples because deployments, incidents and controls make cause and consequence visible, but the underlying idea appears anywhere people depend on systems.

In aviation, checklists, crew communication protocols, maintenance schedules and incident investigations create conditions that make safe flight more likely. In healthcare, medication controls, surgical timeouts, clinical handovers and escalation paths create conditions that protect patients. In manufacturing, quality gates, production layouts, maintenance routines and tolerances create conditions for consistent output. In financial services, segregation of duties, risk committees, controls and audit trails create conditions that reduce exposure and preserve accountability.

The implementation differs because the work differs. A hospital should not copy an enterprise software CAB, and a software company should not copy an operating theatre. What transfers is the train of thought.

What outcome are we trying to create? What conditions make that outcome more likely? Which conditions currently pull against it? Who is affected by the design? How will ownership remain clear when pressure arrives?

Frameworks such as ITIL, ISO, Lean, COBIT and established clinical or engineering standards can support this work. They provide patterns developed through accumulated experience. But the framework is not the principle. A certification does not guarantee that leadership understands why a control exists, and a process copied without context can become bureaucracy.

Deliberate Design sits above the framework. It is the leadership judgement that selects, adapts, funds and protects the mechanisms appropriate to the outcome. It also knows when a process no longer serves its purpose and should be redesigned rather than defended because it once appeared in a policy.

This is why the principle remains useful across industries. It does not prescribe one answer. It requires leaders to stop treating desired outcomes as instructions and begin examining the environment that makes them possible.

The same applies beyond formal operations. Trust requires conditions of consistency, honesty and fair ownership. Recognition requires leaders to notice impact that may not advertise itself. Customer Success requires alignment around the outcomes that justified the customer's investment. Responsible AI adoption requires clear boundaries, human accountability, useful training and work redesigned around the strengths and limitations of the technology.

Different destinations require different routes. The compass remains the same.

Making Deliberate Design Commercially Visible

Leadership principles often remain trapped in the language of good intentions. Trust is good. Governance is good. Learning is good. Thoughtful design is good. Boards and executives, however, must also decide what deserves investment.

Deliberate Design does not need a universal financial formula. Its value will appear differently in an airline, hospital, manufacturer, public body or enterprise software company. It does need to be discussed commercially.

Poor design already creates measurable costs. Failed deployments produce downtime, overtime, service credits and RCA work. Weak handovers produce delays and duplicated investigation. Unclear ownership consumes executive attention. Poorly designed restructures increase attrition, recruitment cost and customer disruption. Incentives that reward local success over shared outcomes create rework and internal conflict. Knowledge that exists outside the decision path leaves teams repeatedly solving the same problem.

These costs may be spread across different budgets and appear at different times, which makes the connection easy to miss. The team that removes a control may record the immediate saving. The support organisation absorbs the incidents months later. Customer Success manages the damaged relationship. Finance sees a service credit. Recruitment replaces exhausted employees. Sales encounters renewal resistance. Each function sees part of the consequence while no single line item is labelled “poor design”.

This fragmentation is one reason the value should not be defined by one person. Finance may see operating cost. Operations may see failure demand and recovery time. Customers may see downtime and confidence. Employees may see workload, clarity and learning capacity. Product teams may see rework and delayed delivery. The appropriate measures should be agreed by the stakeholders who understand and live with the outcome.

The purpose is not to manufacture an exact return where evidence cannot support one. It is to promote a more useful train of thought: if this principle changes how the organisation performs, where should that value become visible?

Examples may include fewer severe incidents, lower downtime, reduced service credits, less duplicated work, faster onboarding, lower unwanted attrition, stronger renewal, shorter recovery, fewer executive escalations or more predictable delivery. The relevant combination will depend on the outcome being designed.

The important step is not selecting one perfect metric. It is recognising that the design of the conditions is worth measuring at all.

The KB article from the deployment example illustrates the point. It would have looked insignificant in a report focused only on publication volume. Yet it saved time, protected commercial ownership and prevented expensive arguments after failures. Its value became visible through reduced ambiguity and better governance rather than article views.

Deliberate Design should therefore be treated as an investment in probability. It cannot promise that every deployment will succeed, every employee will remain or every customer will renew. It can reduce avoidable failure, make accountability fairer and create an environment in which the desired outcome has a stronger chance of becoming normal.

The measures will differ. The stakeholders must decide them together. The leadership responsibility comes earlier: to recognise that outcomes do not create their own conditions and to design those conditions with enough care that success is not dependent on luck.