Organisational readiness
Readiness is not enthusiasm. It is the measurable distance between how an organisation works today and what a DevOps operating model requires. This standard defines what we measure and how.
What readiness means
An organisation is ready for DevOps when four conditions hold:
- Teams can own a service end to end. Development and operations share responsibility for running what they build, rather than handing off at a boundary.
- Decisions can be made quickly. Approvals for routine change do not require escalation through several layers.
- Information flows across boundaries. Engineering, security, finance and the business have a working way to exchange requirements and constraints.
- People have the skills and are given the time. Training is scheduled, not assumed.
None of these are tooling conditions. All four can be assessed before a single pipeline is built.
Assessment areas
Culture
How the organisation behaves under pressure, and whether people are safe to surface problems.
- Is the culture hierarchical and siloed, collaborative, or resistant to change?
- Are people encouraged to share ideas and feedback?
- Is there trust and transparency between departments?
- When something fails, is the response blame or learning?
Team structure
Whether the org chart helps or hinders delivery.
- Are teams functionally split — development, testing, operations — or cross-functional with shared responsibility?
- Does the current structure facilitate collaboration?
- Where do handoffs create queues?
- Is there a platform or enablement team, or is everyone doing everything?
Communication
Whether information reaches the people who need it.
- Which channels are actually used — email, chat, meetings, project tools?
- Are those channels effective for collaboration?
- Does engineering learn about business priorities early or late?
- Are decisions recorded and discoverable?
Workflow and process
The current software delivery lifecycle, documented as it is rather than as it is described in policy.
- Waterfall, agile, or a hybrid in practice?
- Where are the approval gates, and how long do they take?
- Are requirements written down and stable, or discovered mid-build?
- How are production changes tracked?
Skills and training
Capability present versus capability required.
- Do people feel equipped to adopt DevOps practices?
- Has anyone received formal training on cloud, containers, IaC or CI/CD?
- Is there a documented onboarding path for new engineers?
- Is there a hiring plan that closes the gap, or an intention to train?
Automation
The factual state of the delivery toolchain.
- What proportion of services deploy through a pipeline rather than manually?
- Is infrastructure defined in code, and is that code the only way it changes?
- Is test automation present, and at what level?
- Are environments reproducible?
How the assessment runs
Instrument
A short structured survey issued to a cross-section of staff, supplemented by interviews and workshop observation.
Population
Engineering, operations, security, product and at least one business function. Sampling only management produces a confident and wrong answer.
Anonymity
Responses are aggregated. Individuals are not identified unless they opt to be interviewed.
Output
A readiness profile across the six areas, with strengths, constraints, and the specific organisational changes required.
Reading the result
Readiness findings drive sequencing. The common patterns:
| Pattern | Signal | Recommended sequence |
|---|---|---|
| Siloed but capable | Strong engineering, slow approvals, low cross-team trust | Start with a single product team, prove the model, then expand. Focus on decision rights early. |
| Collaborative but manual | Good culture, no automation, heavy manual release | Automate the release path first. Culture already supports adoption. |
| Compliance-constrained | Heavy regulatory obligation, conservative change control | Bring Legal and Risk into the design phase. Build policy as code to satisfy control requirements. |
| Low capability | Enthusiasm without skills | Pair delivery with a training plan. Do not outsource the work without transferring the knowledge. |
| Burned before | Previous failed transformation | Start with a narrow, visible win and publish the evidence. Rebuild credibility before scope grows. |