73 posts tagged with "engineering-metrics"

A delivery platform's engineering team runs a fundamentally different workload from a B2B SaaS team. The courier mobile app pings location every 3-5 seconds. The dispatcher console expects sub-200ms order assignments. Route-optimization jobs crunch combinatorial problems overnight and need to finish before dawn shifts start. A 2024 McKinsey report on last-mile logistics pegged the cost of a single hour of dispatcher downtime at $12,000-$35,000 for a mid-size regional carrier.

This shape of work changes what engineering metrics actually matter. DORA four keys still apply, but the team-health and delivery-performance picture shifts. Here's the metric stack that fits logistics platform teams — and the places where "copy a SaaS DORA dashboard" misleads you.

A marketplace CTO told me the line I keep hearing: "My supply team ships fast, my demand team ships fast, and GMV still stagnates." The DORA dashboards were green on both sides. The matching engine was not. Two-sided products have a metric gap that single-sided SaaS doesn't: engineering output on one side of the marketplace only creates business value if it's matched by output on the other side.

Andreessen Horowitz's marketplace framework ranks liquidity — the probability that a listed item actually transacts within a window — as the single best predictor of marketplace health. That probability is an engineering outcome, not a marketing one. When search latency rises by 200ms, listed-item conversion drops measurably. When seller onboarding takes 14 days instead of 4, supply growth curves flatten within a quarter.

A mid-sized automotive supplier I consulted for in 2024 had a production bug land at 03:15 on a Tuesday. The fix took 8 minutes to code and 19 days to deploy — because it required a software update to PLCs on 14 production cells, each of which could only be updated during the 4-minute changeover window between shift batches. The engineering team's average lead time on the office-IT side: 31 hours. On the shop-floor side: 14 days. Same team, same repository, two different universes of delivery constraint.

Manufacturing software engineering is Agile meeting hardware. The practices that work at a SaaS startup — deploy-whenever, feature flags, canary releases — collide with regulated plant-floor reality: OEE targets, changeover costs, OT/IT separation, and production lines that cannot pause for a deploy. A 2023 Deloitte Smart Factory study found 73% of manufacturers cite "IT/OT integration" as the top barrier to digitization. The problem isn't technology; it's that metrics and rituals designed for pure software break when the software touches a physical process.

A VP of Engineering walks out of a Q1 review and announces an 8% raise for 12 backend engineers, effective March 1. It's now May 18. Three months of finance reports already shipped to the board with the old rates baked in. HR has two options: pretend the raise started today, or retroactively update March, April, and May. Most engineering finance tools force option one. PanDev Metrics supports option two, and the Sarbanes-Oxley Act of 2002 is the reason it has to be done carefully.

This is one of the few areas where our product genuinely diverges from LinearB, Jellyfish, and Code Climate Velocity. Those tools were built around forward-only rate models. PanDev's UserRate table is bitemporal: every rate has a startPeriod and endPeriod, and the OverheadCoefficientFullRecalcCronJob will replay activity events through new rate × overhead K when historical rows change. That's powerful. It's also exactly the kind of capability that auditors look at twice.

A PropTech team I worked with last year ships 4.2 deploys per week across their flagship product. Their CEO benchmarks that against a reference SaaS portfolio and concludes velocity is "mediocre." It's not. A fintech of similar headcount ships 7.1; a pure B2B SaaS ships 9.4. PropTech lives at the intersection of regulated data, geospatial complexity, and 1990s MLS integrations — the raw deploy-frequency number hides what engineering is actually fighting.

Stack Overflow's 2024 Developer Survey places real-estate software in the bottom third of all industries for reported build and integration-testing speed. Microsoft Research's 2024 DevEx benchmarks show regulated industries losing an average 23% of engineering throughput to compliance friction alone. PropTech layers geospatial complexity on top of that.

A team shipping a battery-powered agricultural sensor runs a CI pipeline that takes 38 minutes to build a firmware image, flash it to hardware-in-the-loop, run a 12-minute on-device test suite, and publish artifacts. Their web-app teammates push to main and see green checks in 7 minutes. When both teams get measured on deployment frequency, the firmware team looks like they're underperforming by 5×. They're not. They're doing harder work with a longer feedback loop, and the metric isn't reading it.

Most engineering metrics were built for web software: fast builds, reversible deploys, observability from day one. IoT and embedded teams inherit these metrics and look bad against them. The DORA framework acknowledges this explicitly — the 2023 Accelerate State of DevOps report noted that "teams shipping embedded or regulated software face a different distribution and should not be compared to web teams on deployment frequency alone". This article is what you track instead.

A 30-day Q1 2026 dataset from a 14-engineer team: 187 tickets touched a legacy authentication component over the year, average cost $1,820 per ticket at 18 hours each. The same team's greenfield onboarding component handled tickets of comparable type and severity at $640 per ticket in 6 hours. The gap is the tech debt tax. Multiplied through, that single legacy component leaks $220K per year the CFO has been signing off on without ever seeing it as a line item. Stripe's Developer Coefficient report (2024 update) puts engineer time lost to "bad code" at roughly 17 hours per week per developer, about 42% of declared work. That's the global average. The number above is what it looks like when you finally measure it locally.

This article is for the engineering manager whose CEO has asked for "the business case to refactor" and who has nothing concrete to put in the spreadsheet. Formula is dull. The data plumbing is the actual work.

You open the Q3 Plan-vs-Actual report. Planned engineering spend: $1.8M. Actual: $2.34M. Variance: +30%. The CFO wants to know why by Friday.

The textbook answer says "investigate any line where |actual − plan| > 10%". That's where most engineering variance reviews stop, and where they go wrong. A 30% gap on engineering cost has at least 5 distinct causes. Each one leaves a different signature in the data. If you don't decompose the variance, you end up firing the project manager when the real culprit was a retroactive raise round in August.

CIMA's variance analysis framework treats variance as a tree: rate variance × volume variance × mix variance. Engineering cost is messier, because labor isn't a uniform commodity. Below is the version that actually fits how dev teams burn money.

A team of 6 engineers, 60 working days, 8 hours each. The PM walks into the planning room with 2,880 dev-hours of capacity on the slide. Q3 roadmap fits in 2,400. Comfortable buffer. Three months later 40% of the roadmap is late and the postmortem blames "scope creep."

There was no scope creep. The capacity number was wrong on day one. Stanford economist John Pencavel's hours-and-productivity study shows output per hour starts collapsing past 49 hours per week, long before you hit 60. Microsoft Research and UC Irvine's Gloria Mark added the second blade: every interruption costs an average 23 minutes 15 seconds to fully recover focus. Stack those two findings on top of any 8-hour calendar and you get something far less than 8 productive hours of real output.

Two engineering orgs of identical size shipping at the same pace. Org A: every file has a named owner, PRs need their approval. Org B: anyone can merge to any part of the codebase after a peer review. Org A has 40% fewer bugs per KLOC. Org B recovers from a senior engineer leaving 3× faster. Microsoft Research (Bird et al., 2011, Don't Touch My Code: Examining the Effects of Ownership on Software Quality) ran this experiment across 3,000+ files in Windows Vista/7 and showed that files with a strongly-identified owner had significantly fewer post-release failures — but they also showed that high-ownership files were more likely to become a bottleneck.

This article compares three real ownership models — strong ownership, collective ownership, and the hybrid pattern — using the Microsoft data, Google's 2018 internal study on code review, and 100+ companies in our own IDE dataset. The goal: pick the model that fits your team's stage and work, not the one that fits the blog post you read last week.