38 posts tagged with "leadership"

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.

Your best senior engineer just got promoted to "lead." Nobody wrote down whether that means Tech Lead or Engineering Manager, so now she does both. She's reviewing every PR, running every 1:1, planning every sprint, and still expected to ship her own code. Three months in, her output collapsed and so did team delivery. A 2024 Stack Overflow Developer Survey found that engineers in hybrid "lead" roles report 1.6× higher burnout than those on either a pure IC or pure management path. Merging the roles is the single most common — and most expensive — leadership mistake we see.

Tech Lead and Engineering Manager are different jobs with different success metrics, different time allocations, and different failure modes. Pick one per person, or pick both and hire two people.

A newly hired VP of Engineering has three things the org watches closely: what they cut, who they keep, and how fast they announce a plan. Get the sequence wrong and credibility is gone by week 4 — the org decides you're either a reorganiser or a lame duck before you understand the codebase. Michael Watkins' The First 90 Days is the foundational reference, but it's written for general executives. Engineering orgs have specific traps.

The counter-intuitive move: announce less in the first 30 days than you think you should. Not "listening tour" theatre — an actual measured pause while you read the org's calendar, incident history, and deploy pipeline.

A CFO usually sees engineering on one line of the P&L: salaries. A headcount column, a loaded-cost multiplier, a big number growing faster than revenue. That's it. Deloitte's 2024 Global Technology Leadership Study put the gap at its starkest: only 31% of CFOs said they could tell whether their engineering investment was producing returns proportionate to cost. The other 69% were flying blind on roughly the largest discretionary spend in the company.

This is not a tooling problem. It's a question problem. The numbers exist. Your CFO peers just haven't learned which five questions extract them.

McKinsey's 2023 developer productivity report found that engineers spend only 25-30% of their time writing code. The rest vanishes into meetings, context switching, and waiting. If you're an Engineering Manager relying on gut feeling, you're blind to where 70% of your team's capacity actually goes.

Here are 10 metrics that will sharpen your decisions. No fluff, no "track everything" advice — just the ones that separate informed management from guesswork.

Gallup research consistently shows that manager quality is the single largest factor in employee engagement — yet most engineering managers run 1:1s the same way: "How are things going?" followed by an awkward silence, then a pivot to project status updates. That's not a 1:1 — that's a standup with extra steps. Real 1:1s should be the most valuable 30 minutes in your developer's week, and data makes them dramatically better.

A Harvard Business Review analysis found that over 90% of managers admit their company's performance review process does not produce accurate results. In engineering, the problem is even worse: managers write vague paragraphs based on what they remember from the last two weeks. High performers who are quiet get overlooked. Loud underperformers get rated higher than they should. And everyone walks away feeling like the process was arbitrary. Data fixes this — but only if you use it correctly.

Stripe's "Developer Coefficient" report estimated that companies worldwide lose over $300 billion annually due to developer inefficiency — much of it from understaffed teams fighting technical debt instead of shipping features. You need more engineers. Your team is overloaded, deadlines are slipping, and technical debt is piling up. You know this intuitively. But your CFO doesn't care about your intuition — they care about numbers, ROI, and risk. The reason most headcount requests fail isn't that they're wrong. It's that they're argued in the wrong language.

Gartner estimates that fewer than 30% of engineering leaders have effective visibility into their team's actual performance. Every CTO has a dashboard — most of them are useless. They're either crammed with dozens of charts that nobody reads, or they're a single graph of velocity that tells you nothing actionable. A good CTO dashboard answers three questions: Are we delivering? Are we healthy? Are we improving? Here's how to build one that actually works.