8 posts tagged with "metrics"

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.

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.

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.

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.

Developer Experience — DevEx or DX — has gone from a niche concept to a boardroom topic. Companies like Google, Spotify, and Shopify have dedicated DevEx teams. Job postings for "Developer Experience Engineer" have tripled since 2023. The JetBrains Developer Ecosystem Survey now includes DevEx-specific questions, signaling that the industry treats this as a measurable dimension, not a buzzword.

But what is Developer Experience? How do you measure something that feels inherently subjective? And why should a VP of Engineering care?