The WAY Framework

Official source: dora.dev ↗

Everything in this field descends from DORA, the DevOps Research and Assessment program. It began as an academic-grade research effort: multi-year surveys of tens of thousands of professionals, statistical modeling, and peer-reviewable methods, culminating in the book Accelerate. Its landmark finding was that software delivery performance predicts organizational performance, and that it can be measured with four metrics:

The deep insight, often lost in dashboard implementations, is that speed and stability are not a trade-off. Elite performers in DORA’s data are fast and stable, because the same capabilities, small batches, automation, loosely coupled architecture, and a generative culture produce both. DORA was never just four numbers; it is a validated causal chain from capabilities to delivery performance to organizational outcomes.

Strengths: a decade of evidence, industry-standard definitions, benchmarkable across companies, vendor-neutral. Limits: the four keys describe the delivery pipeline, not the whole organization. They are lagging indicators, they say little about individual or team experience, and they were defined before AI-assisted development existed. DORA’s own recent research has moved into AI, defining the adoption capabilities that make AI investment pay off, which the vendor frameworks now borrow liberally.

Original paper: The SPACE of Developer Productivity, ACM Queue ↗

SPACE was the field’s course correction. By 2021, DORA’s four keys were being abused as productivity scores for individuals, exactly what the research warned against. SPACE, from many of the same researchers, is not a metric set at all. It is a rubric arguing that developer productivity is multidimensional and cannot be captured by any single number. The five dimensions:

SPACE’s operating rules matter more than its letters: measure across at least three dimensions at once, mix system data with perceptual data, and never let one metric stand alone, because of Goodhart’s law: any measure that becomes a target stops being a good measure. Strengths: the intellectual guardrails of the entire field. Limits: it deliberately does not tell you which metrics to pick, which is why every later framework, vendor or otherwise, positions itself as “SPACE, operationalized.”

Official source: DORA research & Core model, dora.dev ↗

DORA Core is the program’s answer to a decade of annual reports piling up: a consolidated, stable model of the findings that have held up across years of data. It formalizes the chain the research always implied: capabilities (technical practices like version control and CI, process practices like small batches, cultural conditions like psychological safety) drive performance (software delivery and operational performance, the four keys plus reliability), which drives outcomes (organizational performance and team wellbeing).

Why it matters in this discussion: DORA Core is the closest thing the industry has to settled science, it is public, and it belongs to no vendor. When a vendor framework tells you it goes “beyond DORA,” DORA Core is the baseline it should be measured against, and the vocabulary your board reporting stays legible in if you ever change platforms.

Official source: DX Core 4, getdx.com ↗

Core 4’s contribution was ruthless simplification with a research pedigree. It unified DORA, SPACE, and developer experience research into four dimensions, each with one headline metric an executive can hold in their head:

Two things made it land. First, credibility: it was framed as a unification of DORA and SPACE, with names from that lineage attached, not a replacement for them. Second, balance by construction: speed is always counterweighted by quality and experience, so gaming one dimension shows up in another. Limits: the DXI, the Effectiveness metric, is proprietary to DX, which is the quiet lock-in inside an otherwise portable framework, a point that matters more now that DX belongs to Atlassian. And a survey-based centerpiece inherits survey mechanics: quarterly cadence, response decay, self-report bias.

Official source: Measuring AI code assistants and agents, getdx.com ↗

The companion framework answered the question boards started asking: is the AI spend working? Its structure is a three-lens funnel, and it has become the de facto template everyone else riffs on:

Utilization. Who is using AI tools, how often, and for what: adoption breadth and depth, before anything else, because impact analysis on a team that barely uses the tools measures nothing.

Impact. What AI usage does to the metrics that already matter: the Core 4 dimensions, plus self-reported time savings. The design principle is the right one: AI should be evaluated against your existing performance model, not a parallel scoreboard of AI-specific vanity metrics.

Cost. Spend against value: licenses, tokens, and the ROI arithmetic the CFO will run whether or not engineering runs it first.

Utilization, impact, cost is a genuinely sound skeleton, and readers should notice that every vendor framework in Part III contains some rotation of it. Limits: the impact lens leans on self-reported time savings, which are systematically optimistic, and the framework’s home is now inside Atlassian, which sells an AI coding agent of its own. The methodology remains useful. The neutrality of its steward is a fair question.

Official source: DRIVE, cortex.io ↗

DRIVE measures what Cortex calls organizational health in the age of AI, explicitly positioned at a higher altitude than developer productivity: not “are developers effective” but “can the organization sustainably turn customer needs into reliable software.” Five pillars, each phrased as a leadership question:

Attached to the pillars is the OpEx review, a recurring leadership ritual borrowed from manufacturing operational excellence: treat the org as one observable system, review it against DRIVE, reallocate people and money to close gaps. That ritual is arguably the framework’s best idea, and it costs nothing to adopt with or without Cortex.

What it gets right: it is honest about its altitude. Vigilance and Initiatives are real leadership concerns that DORA and SPACE never claimed to cover, and the AI-era framing (velocity outpacing controls) is a fair diagnosis. What to watch: DRIVE is a governance framework, not a productivity or AI ROI framework: it can tell you the factory is up to code, not what the factory produced per dollar of AI spend. Its pillars map one-to-one onto Cortex’s catalog, scorecards, and workflows, several of its metrics (orphaned assets, compliance-bar coverage) are only measurable if you maintain a service catalog, and its vocabulary is one vendor’s. Adopting DRIVE as your organization’s definition of engineering health is, in practice, adopting Cortex’s data model.

Official source: The APEX framework, linearb.io ↗

APEX is the most focused of the three: an operating model for validating whether AI increases throughput without breaking delivery confidence or developer experience. Its design principle is “north stars over metric volume”: four pillars, one guiding metric each.

Its sharpest ideas are real contributions to the conversation. Measure AI in the critical path: if AI is not visible at the PR level, you cannot connect it to delivery, and PR-level attribution beats seat counts by a wide margin. Bottlenecks shift downstream: if AI cuts coding time but review queues balloon, the system did not improve, the constraint moved, so decompose cycle time. Predictability before velocity: speed that breaks commitments is chaos, not progress. And it prescribes an operating cadence, weekly for AI leverage, per sprint for predictability, monthly for flow, quarterly for DevEx, which is more practical guidance than most frameworks bother with.

What it gets right: PR-level AI attribution and constraint thinking. It also borrows honestly, crediting DORA’s AI capabilities by name. What to watch: APEX is scoped to the delivery pipeline plus sentiment. There is no business alignment, allocation, or cost dimension, so it answers “is AI making us faster sustainably” but not “what is AI returning per dollar” or “is the work pointed at the right things.” Its predictability pillar presumes sprint-style planning data, which is really Jira hygiene by another name. And LinearB states plainly that it is “the only platform purpose-built to implement APEX at scale,” which tells you what the guide is: a well-made funnel.

Official source: The WAVE Framework, uplevelteam.com ↗

WAVE frames engineering organizations as sociotechnical systems: human collaboration and environmental factors matter as much as deployment statistics, so the framework spans both. It explicitly critiques DORA as narrow and lagging, and SPACE as theoretical without a measurement approach. Four interconnected dimensions, each summarized by a lagging outcome metric driven by leading-indicator inputs:

WAVE’s genuinely valuable observations: AI inflates activity metrics, so merge and issue velocity can soar while deployment frequency and delivered value stay flat, exactly the trap executives fall into when they read raw output as ROI. Allocation reality: teams believe they spend far more time on new value than objective analysis shows. And knowledge work spends most of its life waiting, so flow efficiency, not activity, is where the leverage hides.

What it gets right: the sociotechnical framing is correct, and the leading-versus-lagging structure is more thoughtful than most. What to watch: WAVE’s signature inputs, deep work hours, meeting patterns, team health, come from calendars, collaboration tools, and surveys, which means the framework operationalizes workday measurement that works councils and privacy reviews increasingly refuse, and several of its dimensions are only measurable with Uplevel’s specific instrumentation and human interpretation layer. It is also the least benchmarkable of the three: composite proprietary scores cannot be compared across the industry the way DORA metrics can.

“A framework you cannot take with you when you leave the vendor was never a framework. It was an onboarding flow.”