21 posts tagged with "engineering-management"

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.

Most DORA adoption efforts fail not because of tooling or data — but because they become 6-month projects that die in committee. The Accelerate research (Forsgren, Humble, Kim, 2018) showed that organizations with visible delivery metrics improve faster. The key word is visible: a dashboard nobody looks at is worse than no dashboard, because it creates the illusion of measurement. Here's a day-by-day plan to go from zero to live DORA dashboards in two weeks — fast enough that the momentum doesn't dissipate.

Gloria Mark's research at UC Irvine found that it takes an average of 23 minutes and 15 seconds to refocus after a single interruption. Now consider a typical developer morning: 9:07 Slack pings, 9:15 standup reminder, 9:45 a "quick question" from a PM. By 10:30, they've been "working" for 90 minutes but written exactly 11 lines of code. Three interruptions consumed roughly 70 minutes of cognitive recovery time.

This isn't a productivity problem. It's a focus time problem. And the data shows it's costing your team far more than you think.

Nobody quits on a Monday. The resignation email you receive on a random Thursday was written — emotionally — six weeks ago. The disengagement started three months ago. And the data saw it coming the entire time.

The 2023 Stack Overflow Developer Survey found that over 70% of developers reported some level of burnout symptoms. Replacing a mid-level software engineer costs an estimated 50-200% of their annual salary when you factor in recruiting, onboarding, and lost institutional knowledge. The SPACE framework (Forsgren et al., 2021) explicitly includes "Satisfaction and well-being" as a core productivity dimension — recognizing that burned-out developers aren't just unhappy, they're materially less productive. But the signals are visible in activity data long before the resignation letter.

Here are five patterns that show up in IDE activity data weeks — sometimes months — before a developer burns out or leaves.

Your senior developer is assigned to three projects. You assume they're giving each project a third of their time. Gerald Weinberg calculated the real math in Quality Software Management (1992): with three concurrent projects, each project gets about 20% of a developer's time — and the remaining 40% evaporates into context switching overhead.

This isn't speculation. It's a well-documented cognitive phenomenon, confirmed by our platform data across B2B engineering teams and consistent with Gloria Mark's research at UC Irvine showing 23 minutes of recovery time per interruption. Context switching is one of the most expensive invisible costs in software engineering.

According to McKinsey's research on developer productivity, software engineers spend only 25-30% of their time actually writing code. So where developers work should matter far less than how their time is structured. Yet the remote vs. office debate has been running for six years, with CEOs citing "collaboration" and developers citing "focus" — both arguing from conviction, not evidence.

We have thousands of hours of tracked IDE activity across 100+ B2B companies. The data tells a more nuanced story than either side wants to hear.

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.