85 posts tagged with "engineering-management"

Tom Preston-Werner published "Readme Driven Development" in 2010, and most engineering teams read it, nodded, and continued writing the code first. Fifteen years later, the teams in our dataset that actually practice RDD ship 22% fewer rewrites in the first 90 days of a new service and onboard new engineers to that service 3× faster than teams that write documentation after the code lands. The gap isn't about documentation quality. It's about what writing forces you to think through.

RDD is a working practice: write a credible README for the thing you're about to build, get it reviewed, then write the code. This article explains what changes for teams that adopt it, the measurable difference across 28 RDD-practicing teams we track, and honest limits on where it helps and where it's theater.

Two 30-person engineering teams, same stack, roughly the same product complexity. Team A runs async-first: one standup-alternative written dump per day, decisions in RFC threads, code review within 48 hours. Team B runs sync-first: two daily standups, an architecture sync twice a week, decisions made in meetings. We measured coding-time and lead-time on both teams for a full quarter. Team A had 2h 50m median active coding per day, lead time of 4.2 days. Team B had 48m median active coding per day, lead time of 2.1 days. Same output, different bottlenecks. Neither is "better" universally.

The async-first narrative dominated 2021-2023. GitLab's handbook, Basecamp's Shape Up, and dozens of remote-work thinkpieces framed synchronous meetings as productivity theater. The counter-correction is happening now: teams that went fully async discovered decision latency had a cost too, and are pulling some sync work back. Microsoft's 2023 New Future of Work report explicitly noted this: teams with zero synchronous time had 33% longer decision cycles, even as their individual focus time increased. This article is the tradeoffs with numbers.

Most engineering teams in 2026 have three distinct kinds of prompt users on the same payroll. There's the power user who has a 60-line Cursor rules file honed over 6 months. There's the casual user who copy-pastes "fix this bug please" and is happy enough. And there's the skeptical user who tried it twice, got bad results, and concluded AI-assisted coding is overhyped. Your team's AI productivity is dragged to the average of those three, not the top.

Individual prompt skill is a personal productivity hack. Team prompt engineering is a process — and most teams haven't treated it as one yet. We'll lay out a playbook for codifying prompts across the team, including what to share, what to keep individual, the metrics that tell you it's working, and the specific failure modes we've seen inside our customers.

A senior backend candidate I interviewed in March 2026 for a 40-person scaleup submitted a 4-hour take-home that was obviously AI-generated within 30 seconds of reading it. Not because the code was bad — the code was too good: consistent style across 14 files, docstrings on every function, and a suspiciously well-structured README covering edge cases the problem didn't require. What actually gave it away: a variable named is_applicable_within_business_context — the exact phrasing Claude 3.7 Sonnet uses when asked to write "enterprise-grade" code.

We hired someone else. Two months later, the same candidate's LinkedIn showed a new job at a competitor who didn't check. I don't know whether they passed the on-the-job bar; the industry tells stories both ways. What's certain: AI-assisted cheating is now the default, not the outlier, and hiring funnels designed pre-2024 select for the wrong thing. A 2024 Stack Overflow developer survey found 76% of professional engineers actively use AI coding tools; candidate tooling lags developer tooling by weeks, not years.

An engineering director at a 400-store regional retailer put it cleanly: "Every time we ship a feature that makes the website faster, we hear applause from marketing. Every time we ship a feature that lets a store associate do their job in half the clicks, we hear silence — and then the quarterly numbers move." Retail engineering is the discipline of serving two populations (shoppers and store associates) and two physical realities (the warehouse and the store floor) from the same codebase.

McKinsey's 2024 State of Retail report found that 73% of shoppers used multiple channels for a single purchase journey — browse mobile, try in-store, buy online, return curbside. Every one of those transitions is an engineering surface: the product-detail page has to know store availability, the BOPIS (buy online, pickup in store) flow has to reserve inventory atomically, the returns kiosk has to un-reserve it. A 2023 IHL Group study documented $1.75 trillion in global retail out-of-stock losses — many of which trace back to inventory-service latency or sync failures, not physical stockouts.

A fintech product team we work with shipped a single 400-line feature four times. The Figma file updated Tuesday. Dev started Wednesday. Design reopened the file Thursday morning to "refine spacing" and again Friday afternoon for "one more micro-interaction." The feature shipped on Monday. The engineer then spent two days fixing visual regressions caught by the PM post-ship. Total time: 7 engineering days. Total net-new code: 400 lines. The handoff killed more than the work.

The "Figma-to-code" conversation is usually about tools — Zeplin, Figma Dev Mode, Locofy, Visual Copilot. None of those fix the actual problem, which is that the design-to-code handoff is a measurement gap hiding in a process gap. We'll define the metrics that actually predict a good handoff, how to measure them without adding overhead, and where the tool choice matters (sometimes) vs doesn't (usually).

Notion passes a hidden failure threshold around 300 pages per engineering workspace. Up to that point, the tool is loved. Past it, search breaks down, duplicate pages accumulate, and the team splits into two camps: one that keeps writing, one that stops reading. Stack Overflow's 2024 Developer Survey put Notion in the top 3 non-IDE tools engineers use daily — but also flagged it as the #1 tool engineers abandoned within 18 months, mostly from exactly this collapse.

The collapse isn't Notion's fault. It's a structure problem. This is a playbook for a 7-database engineering workspace that stays navigable from 5 to 50 engineers, and the specific rules that prevent the 300-page collapse.

A 45-engineer platform team I worked with in Q4 2025 had 214 Slack channels, 82 of them active in the last 7 days. The average engineer belonged to 31 channels, got mentioned in 14 per week, and — based on our IDE heartbeat data — lost 5 hours 42 minutes of coding time per week to Slack-triggered context switches. That's over 10% of the working week vaporized before anyone gets to meeting calendars or code reviews.

Slack isn't the villain; channel sprawl plus broken norms is. UC Irvine's Gloria Mark's multi-decade research puts the recovery cost of a single interruption at 23 minutes to return to full focus. Stack for 14 Slack mentions a week and the math is unforgiving. The good news: the fix doesn't require switching tools or adopting Zen-mode software. It's a set of explicit norms any 10-500-engineer org can apply in a quarter.

Linear ships a new feature almost every week and has become the default "we're a modern startup" issue tracker. Jira has 20 years of institutional muscle memory, 3,000+ Marketplace apps, and a reputation for being slow and configurable in equal measure. Between them sit 200,000+ engineering teams making the wrong choice for six-figure sums per year.

This comparison goes past the feature-matrix surface. It looks at what breaks when a team switches, what the real cost of migration is, and where each tool's design choices quietly exclude it from certain team shapes.

A Series-B board presentation went sideways in 2023 when a director — former GitHub VPE — asked the CTO three questions in a row she hadn't prepared for. She knew deployment frequency and team size. She didn't know median lead time, hiring velocity against plan, or the engineering payroll as a share of operating burn. The board didn't defund engineering, but they added a quarterly engineering review with a different CTO on the call. The meeting became a test the team passed but the CTO didn't.

Boards are harder to prepare for than investors because they have more context and less patience. This is a question list — what a working board actually asks, what the CTO should bring without being asked, and the red flags an experienced director spots in 15 minutes. We collected it from conversations with CTOs who have presented successfully, CTOs who haven't, and two board directors who sit on engineering-heavy portfolios.