96 posts tagged with "engineering-management"

Sprint 47, 8-person team. The standard retro narrative would be: "Velocity dropped 20%, lots of bug fires, we'll prioritize better next sprint." Same vibe as Sprint 46. Same vibe as Sprint 45. Now add one number to the same retro: total sprint cost was $32,800, of which $11,600 (35%) went to bug-fix tickets versus $14,200 (43%) to features. The team's rolling-average bug share is 18%. That single line, "we doubled our usual bug spend this sprint," moved the team from "we'll do better" to "Sprint 48's first three days are bug-prevention only, full stop."

This article shows how to wire one financial number into a 30-minute retro so it produces decisions, not vibes.

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 sprint-planning meeting scheduled "at 10am so everyone can attend" is the fastest way to lose engineering time in a distributed org. The math is simple: with engineers in Americas, EMEA, and APAC, there is no "everyone can attend" slot — at least one timezone loses 3+ hours to meeting at the wrong end of their day. Microsoft's 2022 Work Trend Index, based on 61,000 employees, found meetings scheduled outside local 9am-5pm windows reduce participant engagement by 52% and increase follow-up misunderstandings by 2.4×.

This is a checklist — not a philosophical discussion — for how to run sprint planning for a team spread across more than two timezones. It's built from the patterns we see in our IDE heartbeat dataset, specifically the 62 teams in our data that work with ≥ 3 timezone sprint planning.

Frederick Brooks published The Mythical Man-Month in 1975. His core claim, "adding manpower to a late software project makes it later", survived five decades of methodology fashion: waterfall, agile, DevOps. In 2026, AI coding assistants have lifted individual engineer throughput by 30-55% in controlled studies (GitHub/Microsoft Research, 2024-2025). The natural question: did AI finally break Brooks's Law?

Short answer: no. Slightly longer answer: AI accelerated the part of engineering work that was never the bottleneck, and barely touched the part that actually is.

The most common myth in our industry: an Engineering Manager is a senior developer who got admin rights in GitHub and the authority to approve pull requests on Fridays. Two reasons that's wrong. First, the median EM on the 100+ B2B teams we measure writes code for roughly 18 minutes per day, and that's the healthy number. Second, the highest-leverage thing an EM does has nothing to do with the IDE. It's the conversation that prevents a senior from quitting. The spec rewrite that saves a quarter. The hiring loop that finds an engineer one level above what the team thought it could afford. Will Larson, who built engineering at Stripe, Calm, and Carta, puts it bluntly in An Elegant Puzzle: an EM's job is to make the team output more than the sum of its parts. You cannot do that with your hands on a keyboard.

This is a plain-language definition. Who an EM is, what they do during a week, how the role differs from Tech Lead, the path from senior engineer, and how to measure whether one is doing the job well.

The average engineering manager spends 4 hours per week shuffling Jira tickets. Not planning, not 1:1s — triaging, reminding, closing stale, and chasing down fields people forgot to fill. We surveyed 31 EMs across our B2B customers; 27 of them named Jira as their single biggest time sink after meetings.

Atlassian ships a reasonably capable automation engine in every Jira plan (yes, even Standard). Teams ignore it. Or worse, they use it for one rule — auto-close on "Done" — and miss the 11 that matter. What follows is a set of 12 rules that, together, cut the EM's Jira admin load from 4h/week to around 40 minutes. We've used variants of these at PanDev Metrics in our own engineering org and across three on-prem customer deployments.

A 40-engineer fintech I spoke to last month was paying $960/month for GitHub Copilot Business across their team, but their legal department had just blocked it after a compliance review flagged code-completion telemetry flowing through Microsoft's cloud. Their CTO asked me a deceptively simple question: "Can we self-host something equivalent?"

The answer is "yes, but only if you pass three filters." Stack Overflow's 2024 Developer Survey found 76% of developers use or plan to use AI tools, but adoption in regulated industries lags by 20-30 points. The gap isn't skepticism — it's infrastructure. Most engineering teams want private inference but underestimate what "self-hosted" actually costs in GPU capex, SRE time, and model-quality compromise.

This is the decision framework we hand teams considering the switch: when self-hosted LLMs beat the cloud, when they don't, and the three breakpoints that tip the math.

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.

An Engineering Director who led a 50-person org well is usually the wrong person to lead a 500-person org well. Not because they lack talent — because the role at 500 is a different job, not the same job at higher intensity. Research from First Round Review's survey of 300+ engineering leaders consistently finds that the transitions at ~80, ~150, and ~300 engineers are where the most senior leader burnouts and quiet departures cluster.

This is a data-grounded guide to the four transitions an Engineering Director faces as the org grows from 50 to 500 — what to let go of, what to pick up, and what our IDE heartbeat data says about the warning signs of a Director who didn't make the shift.