Metrics That Tell You an Engineering Org Is Healthy

I'm Tom Lang — I've built and scaled engineering organizations for three decades, from startups to 250-plus engineers and through multiple acquisitions, and I work as a fractional and interim CTO for growth-stage companies, with particular depth in regulated and integration-heavy environments.

If you want to know whether an engineering organization is actually healthy, you have to start from an uncomfortable truth: every dashboard can be gamified. Engineers are, by profession, optimizers. Tell them their bonus depends on shipping more tickets and they'll slice every ticket into three meaningless sub-tasks and triple their "velocity" by Friday. It isn't dishonesty; it's exactly what you hired them to do, pointed at the wrong target.

So when I walk into a company, I ignore the vanity metrics. Here's what I actually look at to find the truth — the numbers that resist gaming, the human tells a dashboard can never show, and the one question that cuts through all of it.

The handful of metrics I actually watch

I watch four, split evenly: two lagging indicators that tell me what already happened, and two leading indicators that show me where the bottlenecks are forming right now.

Change failure rate (lagging). Out of every ten deployments, how many cause a bug, an outage, or need a hotfix? Above about 10%, the team is moving faster than their testing infrastructure can support — they're buying speed by borrowing against reliability.

Lead time for changes (lagging). From the moment an engineer writes the first line of code, how long until it reaches a customer? This one exposes the bloat in the CI/CD pipeline and the deployment red tape — all the waiting that isn't work.

PR review latency (leading). How many hours — or days — does a pull request sit waiting for a peer review? If it's routinely more than 24 hours, the team is hoarding work, siloing, or drowning in technical debt. It's a leading indicator because the delay shows up before the missed deadline does.

Time to first production commit (leading). When you hire a new engineer, how many days until they push something — even a one-line text change — to production? If it takes three weeks, your onboarding is broken and your local dev environment is a nightmare, and every future hire will pay that tax.

The human tells a dashboard can't show

Here's the real gold, and it's why I don't trust a metrics tool to do this job for me. The strongest signals of health are behavioral, and you can only see them by watching.

The pushback test. I sit in a sprint-planning meeting and watch what the engineers do. If they just nod and accept every ticket the product manager hands them — no arguing about scope, no flagging edge cases — the culture is already dead. A healthy engineering team negotiates. It pushes back. Silence isn't agreement; it's the sound of people who've given up and become order-takers.

The vacation test — the hero check. I look at what the lead engineers are doing on Slack when they're supposed to be on PTO. If someone's jumping in to answer questions and review PRs from a beach in Hawaii, that's not dedication — it's a warning. It means the system is so fragile, or the knowledge so siloed, that the company can't function without that one person. (That's the hero-developer red flag, caught from a different angle.)

The cross-pollination of code reviews. I look at who reviews whose code. If the database engineer only ever reviews database PRs and the front-end lead only touches UI code, you don't have a team — you have a collection of independent contractors sharing a Jira board. Healthy teams review across boundaries, because that's how context and ownership actually spread.

The metric founders brag about that hides rot

The one founders love to show me is velocity — specifically, hitting "100% sprint completion" every single cycle. It sounds like the picture of a well-run team. It's the opposite.

If a team hits 100% of its estimated story points every sprint, they're not hyper-efficient — they're sandbagging. They're padding their estimates heavily to protect themselves from management, or they're simply afraid to miss. Real engineering involves genuine unknowns. A healthy team should occasionally miss a sprint goal — because they took a real risk, uncovered a deep architectural flaw, or chose quality over an artificial deadline. Perfect predictability isn't a sign of speed; it usually means the team is buying certainty by lowballing everything they commit to. 100% completion tends to mean 100% predictability at the cost of actual velocity. (Same trap as the red-flags post: the metric a founder is proudest of is often the one I trust least.)

The single best metric — and the golden question

If you forced me to track only one number, it would be cycle time: the exact lifespan of a piece of work, from the first commit to running live in production. It's the ultimate lie detector, because it resists every form of gaming. You cannot have a fast cycle time if your code is messy, your tests are manual, or your team is quietly at war. Everything wrong with an org eventually surfaces as a slow cycle time.

But the single most revealing thing I do isn't a metric at all. I sit down with an engineer and ask one question:

"If you deploy a critical bug to production at 2:00 PM on a Tuesday, walk me through exactly what happens next."

The answer tells me everything.

The unhealthy answer: "I'd panic, try to write a hotfix, wait for the tech lead to approve it, and hopefully get it live before the CEO notices." That single sentence reveals a blame culture, manual rollbacks, and fear.

The healthy answer: "The automated monitoring would catch the error-rate spike, it would roll back to the previous version within about three minutes, and I'd get a Slack alert telling me to investigate." That reveals psychological safety, elite tooling, and systemic resilience — a team engineered to survive failure rather than fear it. (That healthy answer is exactly the automatic-survival reliability I build toward.)

The honest goal

So the honest read on an engineering org's health isn't on a dashboard — it's in the cycle time that can't be faked, the behaviors you have to watch for, and the answer to a single what-happens-at-2pm-Tuesday question. The numbers matter, but only the ones that resist gaming, and never as much as the human signals underneath them.

If you're not sure whether your engineering org is genuinely healthy or just looks healthy on a status report, that's a core part of what my Diagnostic actually measures. Book a call and I'll give you the unvarnished read.