Understanding DevOps Culture
This domain tests whether you can separate cultural change from toolchain adoption. Exam items ask you to identify the Three Ways, the CALMS framework, blameless postmortems, the Westrum typology, the DORA four keys, and Conway's Law, then apply them to a scenario and pick the systemic answer over the blaming answer.
The Three Ways
- Flow - small batch sizes, limited work in progress, no handoffs between dev and ops, visible queues.
- Feedback - telemetry and automated tests loop back fast; anyone can pull the andon cord and stop the line.
- Continual learning - deliberate experimentation, blameless retrospectives, shared risk between teams.
Culture models the exam leans on
- CALMS: Culture, Automation, Lean, Measurement, Sharing. Culture is listed first because tools fail without it.
- Westrum: pathological organisations punish messengers, bureaucratic ones follow rules, generative ones optimise for the mission and surface bad news early.
- DORA four keys: deployment frequency, lead time for change, change failure rate, time to restore. They are team- and system-level outcomes, never individual performance ratings.
- Conway's Law: system architecture mirrors organisational communication paths, so team structure is a design decision.
Worked example
A payments service suffers a Sev-1 after an engineer pastes a debug flag into a production config. The manager proposes a written warning. In a generative-culture retrospective the question becomes: why could a debug flag reach production at all? Findings: no config schema validation in CI, the hotfix path bypassed branch protection, and a two-person on-call rotation paged the engineer at 3 a.m. Remediation is config validation, a break-glass approval that still needs a second reviewer, and a practiced rollback. The warning letter is the pathological answer - it suppresses future reporting and pushes the next incident underground, which is exactly what the exam wants you to reject.
Traps that cost marks
- Portraying DevOps as a job title or a separate team; it is a way of working spanning dev, ops and security.
- Confusing CALMS Measurement with vanity dashboards; outcome metrics win.
- Claiming "blameless" means "no accountability" - accountability moves to systems and process owners.
- Equating a tool purchase (Kubernetes, Jenkins, a pipeline rewrite) with transformation.
- Using lead time or deployment frequency to rank individuals; that destroys the metric's validity.