Andrew Schaefer and I presented this talk at VelocityConf because we kept running into the same question: if DevOps is about collaboration between dev and ops, how do you actually measure that collaboration? You can measure deployment frequency and mean time to recovery, but those are outcomes. We wanted to measure the process itself.
We started with a warning about gaming metrics. The moment you attach incentives to a number, people optimize for that number instead of the underlying goal. Goodhart’s Law applies ruthlessly to DevOps metrics. Measure deployment frequency and you get tiny meaningless deployments. Measure uptime and you get teams afraid to deploy at all. The units of measurement matter, and choosing the wrong ones creates perverse incentives.
The monitoring-to-human-resources parallel was deliberate provocation. System availability maps to timesheets – are people present? Capacity planning maps to hiring – do you have enough people? Performance monitoring maps to productivity metrics. The parallel breaks down quickly, but it exposed how crude most organizational measurement was compared to what we already did for our systems. We measured our servers in milliseconds but our teams in quarterly reviews.
We proposed four levels of team interaction: cooperation (working side by side without interfering), coordination (synchronizing activities), coalition (temporary alignment around a shared goal), and collaboration (deeply integrated work with shared ownership). Most organizations claiming to “do DevOps” were at cooperation or coordination at best. True collaboration – where dev and ops genuinely shared ownership of outcomes – was rare.
The talk closed with Schneider’s culture model as a diagnostic tool: is your organization driven by control, competence, cultivation, or collaboration? Understanding where you are determines which DevOps practices will actually stick. We also borrowed from design thinking – empathy mapping, journey mapping, prototyping – as tools for understanding the current state before prescribing solutions. Technical debt became our metaphor of choice: it’s “vendor lock-in to your past decisions,” and organizational debt accumulates just as invisibly as code debt.
Watch on YouTube — available on the jedi4ever channel
This summary was generated using AI based on the auto-generated transcript.