96 posts tagged with "engineering-management"

A VP of Engineering presents a $1.2M microservices migration to the board. ROI projection: "we save 30% on infra and ship 2x faster." The CFO asks: "Show me the math." The answer is a single number, 240%, with no method behind it. The board says no. Two quarters later, a competitor closes the same migration in eight months and starts winning enterprise deals on latency. The project was good. The math was the problem.

There is no single "engineering ROI formula." There are five distinct calculation methods, each built for a different question. McKinsey's Developer Velocity Index research found top-quartile teams generate 4–5x the revenue per developer of bottom-quartile teams. That ratio means nothing without specifying how you measured it. Pick the wrong method for the question being asked and you will lose a defensible project. This article walks through all five with worked numbers.

Google's engineering culture has a ritual: before a line of code ships for anything non-trivial, there's a design doc. Not a 40-page monument — usually 5 to 12 pages, reviewed by two peers, commented in the margins. Researchers at Google's Engineering Practices team have publicly described this as one of the cheapest quality levers the company uses.

Most teams outside Google skip this step or bolt a Confluence template onto an existing process and watch it atrophy. The template below is what actually survives contact with a distracted reviewer at 4:45 PM on a Thursday — the moment most specs live or die.

A 40-person engineering team shipped the same architectural decision twice in eight months — once in June, once in February, reverted both times. The second revert triggered the RFC process. What they discovered reviewing the commit history: the original context had been captured in a Slack thread that auto-archived after 90 days, and the engineer who owned the decision had left. An RFC document would have cost 4 hours to write and saved roughly 3 engineer-weeks of rework.

RFC (Request for Comments) processes exist because technical decisions outlive the people who made them. Stripe, Cloudflare, Oxide Computer, and the Rust project all publish their RFC formats — and the common structure is narrower than most teams assume. This article is the template they converge on, plus a review cadence that works for 10-80 person teams, plus honest numbers on when RFCs waste time.

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.

A team of 60 engineers I worked with last year had 1,400+ Confluence pages, a Notion workspace with 380 pages, a GitHub wiki in each of their 22 repositories, and a "team knowledge" Google Drive. A new hire's second-week task was to find the staging environment runbook. It took her four hours. It existed in all four systems, with three different URLs, two conflicting versions, and one correct but three-year-outdated instruction in the wiki.

This is a comparison of four knowledge-management approaches — Confluence, Notion, GitHub Wiki, and Git-native docs (Obsidian/MkDocs/Docusaurus over a repo) — and a framework for picking one. Microsoft Research's 2024 engineering-productivity report listed "can't find documentation" as the #3 friction point behind slow builds and broken tests, ahead of code review delays. Tool choice is not neutral; it shapes whether documentation gets written, found, and trusted.

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.

A 50-engineer R&D org we worked with last fiscal year set its annual budget the way most do: take last year's spend ($5.4M), add 10%, call it $5.94M. By Q3, finance was negotiating a $700K supplemental from the board. The shortfall was almost exactly $710K, 12% above the top-down number, and the postmortem traced every dollar to assumptions nobody had written down. Holiday months ran hotter on overhead. Two contractors were on-paper part-time but billed 0.9 FTE. One team grew by three heads in March, and the cost compounded for nine months instead of the four the planner had pencilled.

Gartner's 2025 IT Spending Forecast puts software R&D growth at 9-11% YoY, but the variance band on individual company budgets is much wider. Deloitte's CFO Insights: Budgeting in Volatile Times (2024) found median forecast error of 18% in software-heavy organizations using top-down methods, and the worst quartile missed by more than 30%. McKinsey's 2023 Tech Talent Tectonics report sharpens the case: top-quartile engineering organizations don't just spend less per output. They forecast more accurately, which lets them allocate aggressively where bottom-quartile organizations have to keep cash slack as a hedge against their own bad math.

A fintech team in Warsaw trimmed their average workday by 45 minutes and shipped more features. A 40-person SaaS in Singapore banned morning meetings before 11am and watched their median PR lead time drop 22%. Neither team invented anything new — they adopted protected deep-work blocks. UC Irvine's Gloria Mark has published for almost two decades (The Cost of Interrupted Work: More Speed and Stress, 2008, and follow-ups) that a single interruption costs ~23 minutes of refocus time. Cal Newport's Deep Work (2016) popularized the term for engineering leaders. The data is settled; the implementation is where teams diverge.

This piece walks through five real team schedules. The rituals that worked, the rituals that broke, and what we saw in the IDE telemetry once the pattern stabilized.

A feature is two weeks late. The product manager shrugs: "It's still in the same quarter." The engineering lead nods. The CFO never hears about it. Two weeks turn into six. By then, the enterprise customer who needed it for their procurement cycle has signed with a competitor. The total business cost of that slip was roughly $192,000. None of it appears on any engineering report.

Cost of Delay (CoD) is the most-talked-about, least-quantified concept in modern product development. Don Reinertsen built the math in The Principles of Product Development Flow (2009, chapter 2), and SAFe formalized it into WSJF (Weighted Shortest Job First). McKinsey's 2023 Developer Velocity research found that B2B SaaS leaders ship features 4–5x faster than laggards and capture disproportionately more pipeline ARR per engineer. Yet ask 10 product managers what their last delayed feature actually cost the business and 9 will say "I don't know." The math is reachable. Most teams just never reach for it.

The median tenure of a software engineer at a B2B company is 2.3 years (Stack Overflow 2025 Developer Survey). The median surprise of the engineer's manager when they resign is… also high. We matched IDE heartbeat data, Git activity, and task-tracker signals against 43 confirmed engineer resignations across 11 PanDev Metrics customer teams in 2025. Seven behavioural patterns showed up in the data 30-90 days before the resignation letter.

One of them is almost never on the standard "burnout signal" list. That's the one this post exists for.