Organisations carry their past in the form of constraints. Some guide and protect. Others linger: unexamined, unnecessary, and increasingly harmful to learning and innovation. Restraining constraints are persistent norms, rules, structures, or habits that are cultural or procedural scar tissue, formed from past injury.

Scarring is a natural protective and restorative mechanism in the body's healing process but is not fully regenerative. Scars leave a mark that inhibits growth, can be painful, and limit function. A restraining constraint has the following scar tissue-like properties:

  • It blocks flexibility (new ideas, tools, or processes).
  • It masks underlying issues (we fixed the symptom, not the cause).
  • It reinforces fear-driven behaviour (caution over creativity).

Whether initially introduced preventatively or in response to a failure event, constraints will become normalised in the organisation as standard, unexamined practice. Over time, the landscape changes. New capabilities and practices emerge that could relax or remove the need for a constraint.

However, if the constraint is left untouched in a changing landscape, it may prevent nascent capabilities and practices from succeeding. Perhaps the underlying risk that the constraint mitigates is still present, but could be better handled elsewhere. Or, more insidiously, when a bureaucracy forms to manage and enforce the constraint, there is an additional socio-technical dynamic to consider when relaxing, removing or repurposing a constraint.

Let's focus on three typical examples found in software development enterprises:

Change Advisory Boards (CABs)

Originally designed to assure safety through oversight, CABs risk becoming compliance rituals that do not positively impact the quality of deliveries, their success rates, or restore times.

Research presented in Accelerate shows that:

"Change advisory boards are negatively correlated with software delivery performance."

In high-performing organisations, peer review plus automated deployment pipelines, with embedded testing and monitoring, achieve safer and faster outcomes than CABs ever could.

No Release Fridays

Avoiding deployments near weekends made sense when rollbacks were manual and incidents hard to detect. Modern engineering practices like blue/green deployments, feature flags, observability, and auto-rollback substantially reduce risk. The cultural constraint of never deploying on Fridays often signals a lack of confidence in tooling, rather than inherent danger. That said, don't do DNS changes on a Friday. Life's too short.

Long Lead Times

Batching changes into release windows may be necessary when change activity is manual, error-prone, and difficult to perform. In low-risk environments with safe, repeatable, and automated delivery mechanisms, lead times on change have a significant negative impact. Waiting time delays feedback, and quality suffers. Agile teams embracing continuous delivery reduce risk by releasing more frequently, not less.

These examples show how constraints that once offered safety and structure can become friction points. But rather than removing constraints outright, we can evolve them.

A Reinterpretative Approach Towards Enabling Constraints

Goldratt's Theory of Constraints and frameworks such as Cynefin remind us that effectively functioning constraints are context-sensitive and must be re-evaluated as things change. Not all constraints are restraining. Some can be enabling:

  • WIP limits in Kanban help teams focus.
  • The Pomodoro Technique provides a time-box for creativity, counteracting procrastination.
  • Principles help us evaluate whether a decision is in alignment with our values.

Enabling constraints prevent an organisation from "tripping over itself" through protective and preventive guardrails that retain stricter controls where risk appetite is lower or capabilities are still developing. Enabling constraints work in the service of the team, not against them.

A reinterpretative approach evolves constraints to the current operating context:

  • Recognise - What problem did the constraint initially address?
  • Reassess - Is that problem still relevant? What's changed?
  • Redesign - Can we encode safety through automation or feedback loops?
  • Re-anchor - How do we update culture and roles to reflect the new way?

Changing constraints isn't just technical - it's political. When a dedicated bureaucracy manages a constraint, the livelihood and authority of real people may depend on its continued existence. This turns the constraint into a self-preserving system. To evolve the constraint, we must also evolve the role. Involving the custodians of the old process in the design of the new one is key, not only to avoid resistance but to preserve valuable knowledge.

Conclusion

Enabling constraints don't just restrict; they create a safe environment that focuses attention and action on value-producing activities. If we don't refine operating constraints, they will keep us solving yesterday's problems tomorrow.

Like scar tissue, some constraints serve as reminders of old wounds. But healing isn't the same as growth. If we want our organisations to thrive, we must learn to shed the old protections that now hold us back and build anew.

References and Further Reading

  • How Do Committees Invent? - Conway
  • Accelerate: The Science of Lean Software and Devops: Building and Scaling High-Performing Technology Organizations - Forsgren, Humble, Kim
  • The Goal - Goldratt
  • Team Topologies - Pais, Skelton
  • Strategy as Enabling Constraints - Scotland
  • The Cynefin Framework - Snowden, et al