46 posts tagged with "guide"

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.

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

A 6-person engineering team running a 15-minute daily standup costs you 7.5 person-hours a week in scheduled time alone. Add context switching cost — UC Irvine's Gloria Mark measured ~23 minutes to refocus after an interruption — and the real cost is closer to 15 hours a week. For a team running 10 weeks on one feature, that's 150 engineering-hours. That's not a meeting. That's a part-time engineer you hired and immediately deployed to talking.

Standups aren't inherently bad. They solve a real problem: surfacing blockers before they rot. The question is whether the daily synchronous format is the only way — or even the best way — to solve it. The State of Agile 2024 report shows 32% of teams actively experimenting with async-first alternatives, and the cleanest data we have from IDE telemetry suggests these alternatives recover 1-2 hours of focus time per developer per week without harming delivery.

This is a comparison of 5 standup alternatives, when each fits, and how to decide which one your team needs.

Most "remote rituals" are synchronous meetings wearing a remote costume. A daily standup at 9 AM UTC that five engineers across four timezones reluctantly attend isn't a ritual. It's office cosplay. GitLab's 2024 Remote Work Report found 71% of remote engineers cite "too many synchronous meetings" as the single biggest productivity drain of distributed work. The problem isn't remote; the problem is importing colocated rituals whole.

This is the list of 7 rituals that actually survive on remote engineering teams we've measured: teams where the telemetry shows they're not just happier but also shipping faster.

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 finance lead at a 12-person engineering team opens the cost dashboard. Total monthly burn: $58,000. Four full-time engineers on monthly salary, five contractors on hourly rates, three more outsourced through a vendor invoiced monthly. The dashboard shows a single average cost per developer. It is the wrong number, and every per-feature decision built on top of it is also wrong.

The conventional fix is the 160-hour conversion: divide a monthly rate by 160 to get an hourly equivalent, then compare. The US Bureau of Labor Statistics tracks average annual hours actually worked per employee at 1,791 hours. That is 149 hours per month, not 160. In Kazakhstan, a statutory 24-day vacation entitlement plus 13 paid holidays brings the effective figure closer to 144 hours. The 160 number is a hand-me-down from a country that no longer matches its own data.

A senior backend engineer in Almaty earns $5,000/month gross. A CFO scoping a new project does the obvious math: $5,000 ÷ 160 = $31.25/hour. That number lands in a spreadsheet, then in a board deck, then in a quote sent to a customer.

The real cost of that engineer's hour, after overhead, is closer to $46/hour. That's a 48% gap. The 2024 DORA State of DevOps Report puts non-coding overhead at 35–55% of engineering payroll across high-performing organizations. McKinsey's Developer Velocity Index (2023) lands in the same range. Most companies never multiply through. They quote, scope, and forecast on the naive number, then wonder why the books don't close.

Most non-technical CEOs I've met treat engineering as either a black box or a theater. Black-box CEOs ask "how's engineering?" at the executive meeting, accept "we're on track" as an answer, and act surprised four quarters later when the senior architect resigns and the product roadmap stalls. Theater CEOs become amateur engineering managers — they learn to recite DORA metrics, mispronounce "Kubernetes," and inadvertently turn every roadmap discussion into a technical argument they can't follow.

Neither failure mode is about intelligence. It's about the absence of a short, non-technical vocabulary for engineering health. First Round's 2023 State of Startups survey found 68% of first-time CEOs rate themselves "somewhat" or "very" dependent on their CTO for all engineering judgment calls — which is fine until the CTO leaves or disagrees with the board on direction.

This guide is the minimum CEO vocabulary: 6 questions that let you test whether engineering is healthy without pretending to be technical.