13 posts tagged with "leadership"

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.

The Stack Overflow Developer Survey consistently shows that developer autonomy and trust are among the strongest predictors of job satisfaction — yet most metrics implementations ignore this entirely. On one side, leaders who want to understand and improve their teams' performance. On the other, developers who hear "we're implementing metrics" and immediately think "Big Brother." Both sides have valid concerns. The question isn't whether to measure — it's how to measure without destroying the culture you're trying to improve.

As Matthew Skelton and Manuel Pais document in Team Topologies, the communication overhead between engineers grows quadratically: at 10 people there are 45 potential communication channels; at 100, there are nearly 5,000. At 10 engineers, you know everyone, you hear every conversation, you review most PRs. Things just work — because you're the glue holding it all together. At 100, that's impossible. The CTO who tries to manage 100 engineers the way they managed 10 will burn out, create bottlenecks, and watch quality collapse. The transition from 10 to 100 is the hardest organizational challenge a startup CTO faces, and data is the only way to navigate it without losing your mind.

McKinsey research on engineering effectiveness found that the highest-performing organizations share one trait: their engineering goals are explicitly connected to business outcomes. Yet most engineering teams write OKRs like "Improve code quality" with a key result of "Increase test coverage to 80%." That's not an OKR. That's a task with a number next to it. Good engineering OKRs connect technical work to business outcomes, and the right metrics make them actually measurable.

Every quarter, CTOs face the same uncomfortable meeting. The CEO asks: "We spent $2.4M on engineering last quarter. What did we get for it?" And the answer is usually a list of shipped features — not a financial return.

Engineering is the largest cost center in most technology companies, yet it's the one with the least financial accountability. Marketing can show customer acquisition cost. Sales can show revenue per rep. Engineering shows... velocity points? McKinsey's analysis of software developer productivity highlights this gap: engineering output is measurable, but most organizations haven't built the systems to do it.

It's time to change that.

It's budget season. The CTO submits an engineering budget request: $8.2M for next year, up 18% from this year. The CFO asks for justification. The CTO points to headcount growth, salary inflation, and a list of planned projects. The CFO pushes back: "Can we do it for $7M?" The CTO says no. They compromise at $7.5M.

Neither number is based on data. The CTO added a buffer to last year's spend. The CFO cut it by a round number. The compromise has no analytical basis. Both sides walk away slightly unhappy. A Deloitte CFO Survey found that technology spending is consistently one of the hardest budget categories for finance teams to evaluate — largely because the inputs are opaque.

This is how most IT budgets are built. It doesn't have to be.