Building an Enabling Engineering Organisation Through Policies, Standards and Practices

Digital engineering conversations have shifted from what we build to how we build it responsibly. But to build well, and build sustainably, we need more than good intent - we need clarity.

I've been piecing together a framework of sorts to provide just that: one that aligns teams to shared principles, supports adaptive governance, and enables autonomy at the point of delivery. At its core are three interconnected components: policies, standards, and practices.

This is not a compliance mechanism. It’s an enabling system. One that blends organisational alignment with team-level freedom - underpinned by the principles of minimum viable compliance and supported by a living control plane.

---

Policies: Defining What We Believe and Why It Matters

Policies define the what and the why. They are the organisation’s non-negotiable principles - the beliefs we collectively lean into to shape our engineering culture, ways of working, and technical systems.

Policies don’t prescribe implementation. Instead, they articulate why something is important and what must be true. Examples include:

• Psychological Safety First: We believe high-performing teams depend on trust, openness, and blameless reflection.

• Developer Experience Matters: We prioritise the productivity, flow, and wellbeing of our engineering teams.

• Invest in Differentiators: We focus our efforts on what makes us unique, automating the rest.

Policies are mandatory. Every team is expected to align with them - but how they do so is up to them. Policies set the direction of travel, not the vehicle.

---

Standards: Describing What Good Looks Like

Standards are the expected outcomes teams work towards. They describe what good looks like in specific, observable terms - and form the foundation for maturity, measurement, and reflection.

Unlike policies, standards are not mandatory, but they are expected. Teams can diverge from a standard if they have a strong rationale - but that decision must be deliberate and aligned to context, not accidental.

Some of the standards we are working towards include:

• Major incidents are followed by timely, blameless reviews

• Technical debt is actively reduced over time

• Decision-making authority follows the work, not the hierarchy

Each standard is supported by a maturity model, inspired by CMMI. This allows teams to understand where they are today, where they could improve, and what steps might help them grow.

Importantly, the maturity expectation is contextual. A team in the early explore phase of a product may justifiably be at a different level than a team operating a product at scale in the exploit phase.

Standards give us a common vocabulary - not to enforce conformity, but to align on outcomes and support teams in their progression and growth.

---

Practices: Enabling Autonomy Through Recommended Activities

Practices are the approaches, techniques, or behaviours teams choose to apply to improve their maturity against a standard. These are recommended, not required - and represent the space for autonomy, experimentation, and self-direction.

There are no universal “best practices.” Instead, we provide intelligent defaults - effective starting points that teams can adopt, adapt, or replace.

Examples:

• A newly formed team may start with out-of-the-box Scrum as a delivery practice, using it as a structure to build rhythm and team habits. Over time, they may evolve into leaner, more flow-based models.

• A team building a high-risk new product might use lightweight observability to move quickly. That same team, once the product matures, would be expected to have full observability with mature monitoring, alerting, and automated recovery mechanisms.

Practices such as TDD, value stream mapping, feature flags, or mob programming are catalogued not as rules, but as options. Teams own their maturity journey. Practices simply help them get there more effectively.

---

Balancing Control with Autonomy

This three-tier model - mandatory policies, expected standards, and recommended practices - provides a structure that balances alignment and autonomy.

It ensures that:

• Teams align to organisational beliefs and responsibilities (policies),

• Outcomes are clearly defined and observable (standards),

• Teams are free to choose how they reach those outcomes (practices).

We apply a principle of minimum viable compliance. This means we govern only what’s necessary to protect quality, safety, and strategic alignment - and leave the rest to team discretion.

---

Guardrails and the Role of the Control Plane

A guardrail is not just a standard - it is the combination of a standard, potential measures, and a control mechanism (manual or automated). Guardrails are designed to make it hard to do the wrong thing, and easy to do the right thing.

Guardrails provide safety, speed, and guidance - especially at scale.

However, they must be supported by a control plane: the infrastructure through which governance is made visible, actionable, and continuous.

This includes:

• Automated controls (e.g. deployment policies, code scanning, compliance checks)

• Self-assessment tools (e.g. maturity scorecards, dashboards)

• Manual assurance (e.g. architectural reviews, post-incident learning forums)

• Social systems (e.g. communities of practice, internal tech radars, coaching programmes)

Together, these mechanisms ensure that governance is embedded, not imposed - always in service of better engineering outcomes.

---

Inspired by Proven Frameworks

This thinking draws heavily on frameworks such as DORA, SPACE, and the DevOps Capability Model. These offer valuable perspectives on both technical excellence and human factors - helping frame standards that address not only delivery and quality, but also team health, cognitive load, and empowerment.

I’ve also taken significant inspiration from the book Sooner Safer Happier, which has had a meaningful impact on how I’ve approached the separation of policies, standards, and practices (along with content articles) across the five outcome areas: Better, Value, Sooner, Safer, and Happier (BVSSH).

Each policy, standard, and practice is now consciously mapped to at least one of these five themes. This gives provides a consistent way to think about why something matters, what it improves, and how it connects to the outcomes we want to see across the organisation.

For example:

• A policy like Developer Experience Matters aligns to Happier.

• A standard such as Technical debt is actively reduced over time maps to Better and Sooner; either directly or contributing to higher policies that reside in the varying outcomes.

• Practices like Security is considered from the start and Teams understand the threat models relevant to their domain align to Safer; both of which contribute to the policy of Secure by Design.

By organising our system this way, helps to avoid local optimisation in favour of shared value. It becomes easier to prioritise improvement, understand trade-offs, and spot tensions between delivery, safety, and wellbeing. The BVSSH framing ensures we’re not just moving fast - we’re moving responsibly.

These models and inspirations all encourage us to hold healthy tensions: speed vs safety, autonomy vs alignment, delivery vs learning. Our standards reflect these tensions — helping teams navigate trade-offs with awareness and intent.

---

In Summary

We need to build an enabling system - one that supports teams, not constrains them. This model of policies, standards, and practices provides both clear expectations and space for growth.

• Policies define our shared commitments and direction.

• Standards define what good looks like and how to measure it.

• Practices enable teams to reach maturity in ways that work for them.

With well-defined guardrails and a responsive control plane, we are designing an engineering organisation that combines trust with rigour, alignment with agility, and autonomy with accountability.

This concept is not fully there yet - but this is the system I think is worth nurturing for a bit longer. And if you’re exploring similar ideas, I’d love to hear from you :)

#DigitalEngineering #Enablement #Governance #EngineeringMaturity #MinimumViableCompliance #TeamAutonomy #PolicyToPractice #DevOps #TeamTopologies #DORA #SPACE #BVSSH