85 posts tagged with "engineering-management"

Your team turned on feature flags three years ago because it felt responsible — gradual rollouts, kill switches, A/B tests. Today the flag service has 87 live flags, and nobody on the team can tell you what 34 of them do. Two of them are contradicting each other in production right now. One was meant to be removed in 2024. Airbnb's engineering team publicly described this exact failure mode in 2023 — they hit 6,000+ flags before a full audit forced a cleanup. GitHub reported 3,700 experiments running simultaneously at peak.

The problem is not feature flags. The problem is that teams treat flags as free — cheap to add, invisible to maintain. This playbook is a lifecycle framework that works for teams between 10 and 200 engineers, backed by data from 100+ B2B companies we track via IDE heartbeats. The goal: a flag count that stays roughly flat with team size, not linear with team age.

Twilio maintains 14 active API versions. Stripe pins every customer to the version active on their signup date and has supported versions going back to 2011. GitHub's REST API runs three major versions in parallel and publishes deprecation headers 12 months before sunset. Your team is probably trying to get away with one — and debating whether the version goes in the URL, a header, or the accept type.

The versioning debate is really three separate decisions stacked into one argument: where the version lives, how breaking changes are scoped, and when old versions die. Getting one right doesn't save you if the other two are wrong. This is a playbook drawn from how the companies that actually run public APIs at scale handle it, plus what we see inside PanDev Metrics customers running internal APIs with 20-200 consumers.

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 mid-size JavaScript service imports 47 direct dependencies and ends up resolving 2,500+ transitive packages. The same service ported to Go imports 12 direct modules and resolves 42 total. The pip equivalent sits near 180. These are not preferences — they are the shape of each ecosystem, and your dependency strategy has to start from that reality.

Your supply-chain exposure, lockfile discipline, and upgrade cadence should be different in each. This is a playbook for doing that well across npm, pip, and Go modules — the three ecosystems that cover about 84% of production backend code according to the 2025 Stack Overflow Developer Survey.

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 production release at a 60-engineer SaaS I worked with in 2025 went out at 16:48 on a Friday. The on-call pager fired at 17:22 — a 34-minute latent failure in a feature the release manager had approved "because CI was green." Rollback took 71 minutes because the automation had never been rehearsed with real traffic. Total cost: one customer refund, two engineers' weekends, and a policy change that should've existed from day one.

Release management is the unglamorous half of delivery. DORA's 2024 State of DevOps report ties change failure rate and mean time to restore directly to release discipline — not to engineer talent, not to test coverage. This playbook is the concrete set of rules and rituals that pushed two teams I worked with from monthly pain-releases to daily confident ones.

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 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.