56 posts tagged with "developer-productivity"

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.

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.

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

Your 40-engineer team maintains 34 repositories. Sound reasonable? We see this shape often. A typical developer in that configuration triggers 11.4 context switches per day between repositories — almost all invisible to the EM, each costing roughly 23 minutes of refocus time, per UC Irvine's Gloria Mark (The Cost of Interrupted Work, 2008) and subsequent replications. The same team post-monorepo migration: 3.2 switches per day. The productivity math is obvious; the cost math is where it gets interesting.

Both architectures work. Google runs the largest known monorepo (2 billion+ lines of code, ~85,000 engineers). Netflix runs thousands of polyrepos. The question isn't which is better in the abstract — it's which fits your team size, your CI budget, and your tolerance for coordination overhead.

Copilot wrote 420 tests for your payments module in two days. Coverage went from 58% to 84%. Release confidence? Unchanged, maybe worse. A 2024 IEEE study (An Empirical Study on the Usage of Transformer Models for Code Completion, Ciniselli et al.) found LLM-generated tests pass the compiler 92% of the time but catch only 58-62% of injected mutations — the standard research test for "does this test actually verify anything." Human-written tests in the same study scored 78%. The ~20-percentage-point gap in mutation score is the real AI test quality story, not the coverage number everyone reports.

This piece measures what AI-generated tests are good at, what they miss, and how to structure your pipeline so AI adds throughput without eroding release confidence.

The AI coding tool market fragmented into four serious contenders by early 2026: GitHub Copilot, Cursor, Claude Code (Anthropic CLI), and ChatGPT with Code Interpreter. Marketing decks from all four claim "40% productivity boost" — the number is identical, and it's meaningless without measurement. We pulled IDE heartbeat and session data from 112 engineers across 14 B2B teams in Q1 2026 to see what actually saves time.

The punchline: Claude Code users ship 54 minutes of saved time per day; Copilot users ship 28. But the distribution is not what marketing implies — the best tool depends on the kind of work, not the team's "AI maturity".

HRTech engineering teams ship software that pays people on the wrong day if you get it wrong. A failed deploy on the 14th of the month is not a Slack-apology situation — it's a wire-transfer reversal, a legal letter, and in the EU a GDPR notification to the Data Protection Authority. Deloitte's 2024 Global Human Capital Trends report found that 73% of HR leaders cite their technology platform as a top-three operational risk — above hiring itself.

Most engineering-productivity articles written for SaaS or e-commerce teams don't translate. The metrics that matter for a payroll engineer or an HRIS platform team look different. This guide covers what actually deserves tracking, why, and how the PanDev Metrics dataset for HRTech customers compares to general B2B SaaS.