Frederick Brooks published The Mythical Man-Month in 1975. His core claim, "adding manpower to a late software project makes it later", survived five decades of methodology fashion: waterfall, agile, DevOps. In 2026, AI coding assistants have lifted individual engineer throughput by 30-55% in controlled studies (GitHub/Microsoft Research, 2024-2025). The natural question: did AI finally break Brooks's Law?

Short answer: no. Slightly longer answer: AI accelerated the part of engineering work that was never the bottleneck, and barely touched the part that actually is.

DORA metrics are the four numbers that predict how well a software team ships code. Not opinions, not surveys — four hard signals: how often you deploy, how long changes take to reach production, how often deploys break things, and how fast you recover. The 2023 DORA report by Google Cloud, built on 10 years of research and 36,000+ respondents, is the largest dataset ever assembled on software delivery — and it keeps finding the same pattern.

This glossary explains each metric in plain English, with formulas and the benchmarks that separate elite teams from low performers. Read it once, keep it as a reference.

The most common myth in our industry: an Engineering Manager is a senior developer who got admin rights in GitHub and the authority to approve pull requests on Fridays. Two reasons that's wrong. First, the median EM on the 100+ B2B teams we measure writes code for roughly 18 minutes per day, and that's the healthy number. Second, the highest-leverage thing an EM does has nothing to do with the IDE. It's the conversation that prevents a senior from quitting. The spec rewrite that saves a quarter. The hiring loop that finds an engineer one level above what the team thought it could afford. Will Larson, who built engineering at Stripe, Calm, and Carta, puts it bluntly in An Elegant Puzzle: an EM's job is to make the team output more than the sum of its parts. You cannot do that with your hands on a keyboard.

This is a plain-language definition. Who an EM is, what they do during a week, how the role differs from Tech Lead, the path from senior engineer, and how to measure whether one is doing the job well.

A team of 8 engineers logged 1,280 hours in March 2026. That is exactly what a 160-hour-per-FTE month should produce. The spreadsheet looked clean. Two engineers were three weeks from quitting. The hours number hid that completely; FTE utilization showed it on day five.

This is the gap between an attendance metric and an engagement-against-baseline metric. Microsoft Research's 2022 WorkLab study on the "triple peak workday" documented a third evening productivity spike pushing knowledge workers past sustainable hours, and that signal stays invisible if you only count totals. Hours don't tell you who is sprinting and who is coasting. FTE utilization does.

The average engineering manager spends 4 hours per week shuffling Jira tickets. Not planning, not 1:1s — triaging, reminding, closing stale, and chasing down fields people forgot to fill. We surveyed 31 EMs across our B2B customers; 27 of them named Jira as their single biggest time sink after meetings.

Atlassian ships a reasonably capable automation engine in every Jira plan (yes, even Standard). Teams ignore it. Or worse, they use it for one rule — auto-close on "Done" — and miss the 11 that matter. What follows is a set of 12 rules that, together, cut the EM's Jira admin load from 4h/week to around 40 minutes. We've used variants of these at PanDev Metrics in our own engineering org and across three on-prem customer deployments.

Roughly 80% of the engineering teams I've reviewed in the last year report a "Lead Time" number that DORA wouldn't recognize. They measure ticket-creation-to-release. DORA measures something narrower and harder to game: first commit to production. The gap between those two definitions is often 5–10 days, and it's the difference between an honest delivery metric and a dashboard that flatters the wrong people.

This guide pins down the strict DORA definition, gives you the formula, separates Lead Time from Cycle Time (they're not synonyms), and shows the 2026 elite/high/medium/low bands you can benchmark against.

Two production outages, same root cause: a bad config push that crashed a payments service. Team A spent 2 hours 14 minutes restoring service. Team B was back in 6 minutes. Team B's MTTR wasn't lower because they had smarter engineers. They had a one-command rollback rehearsed monthly, a runbook pinned in the on-call channel, and write access to production already granted to the responder. That 134-minute gap is what MTTR measures, and what separates the DORA 2023 State of DevOps Report elite cluster from everyone else.

Forrester named "Engineering Intelligence" a distinct software category for the first time in 2024. Eighteen months later, we count at least 40 vendors competing for the same buying committee — VP Engineering, CTO, CFO, sometimes a Chief of Staff. The pitch is identical across all of them. The data quality, deployment model, and pricing transparency are not.

We tested 15 of them. Some are excellent. Some are expensive wrappers around git log. This is the buyer's guide we wish we had when we built our own platform.

A 14-minute CI pipeline isn't just 14 minutes of waiting. GitHub Octoverse 2024 reported that the median enterprise repository now runs a pull request through CI 4.2 times before merge: retries, pushes after review, fixing flaky tests. That's nearly an hour of compute per PR. On a team shipping 200 PRs a week, the CI bill buys you nothing and the context-switch tax costs you a senior developer's Thursday.

This is a how-to. Six steps that consistently cut GitHub Actions CI time by 50%+ on real repos we've helped optimize. No theory; each step has a patch you can adapt.

A 50-person engineering org we instrumented in February 2026 had a monthly overhead coefficient of K = 0.37. That means every $1 of direct development work was shadowed by 37 cents of indirect cost: meetings, code review, ramp-up, and a slice of CTO/EM/DevOps salary spread across the team. The CFO had been modelling overhead at a flat 30% loaded multiplier for three years. The actual number was 23% higher, and almost nobody in the company knew.

The bigger problem was not the gap. The bigger problem was that the 30% number was a single bucket, so even after you discovered the gap, there was nothing actionable inside it. Boston Consulting Group's 2024 report on G&A allocation in software firms made the same observation at industry scale: companies that report overhead as one line item find it nearly impossible to trim, while companies that decompose it into three components reduce it by 8–15% within two quarters.