Where Developers Spend Time (vs. Where They Should Be)

Every so often, a piece of research lands in your inbox that makes you pause and think, “Yeah, this is exactly what I’ve been seeing, but couldn’t articulate.”

Microsoft’s recent study, “Time Warp: The Gap Between Developers’ Ideal vs Actual Workweeks in an AI-Driven Era” is that kind of read. It maps a disconnect I’ve heard developers vent about in 1:1s and retro meetings: the constant struggle between what they’re doing and what they wish they were doing.

In this article, we talk about that exact gap. And more importantly, what we as product leaders can learn from it.

Where Developers Actually Spend Their Time

Let’s start with the uncomfortable truth. Developers are spending a surprising amount of time not developing. Microsoft’s study shows:

• Only a fraction of their week is spent writing code, designing systems, and shipping features.
• The majority is consumed by meetings, Slack messages, tool wrangling, and waiting for approvals or unblockers.

None of this is shocking if you’ve worked with engineers up close. But seeing it quantified is a reality check. We’ve built org structures and workflows that slowly chip away at the flow state.

The Ideal Week (And Why It Matters More Than We Think)

When developers talk about their “perfect week,” it’s surprisingly consistent.

They want more time for deep work, heads-down coding, solving real problems, and making architecture decisions that actually move the product forward.
They want collaboration, but the kind that’s quick, intentional, and actually helps, not an endless stream of pings, meetings, and status updates. They’re not asking to go off into a cave. They still value teamwork. But the ask is simple: less noise, more impact.

When there’s a big gap between how their week actually goes vs. how they wish it would, satisfaction drops. It’s not just about efficiency, it’s about identity. Developers want to feel like builders, not just operators moving tickets from “In Progress” to “Done.” That’s what’s really at stake when we talk about developer experience.

The Promise (and Pitfalls) of AI

One of the most interesting parts of Microsoft's research is how it frames AI not as some future disruption, but as a tool developers are already leaning on today to reclaim their time. Developers who regularly use AI tools (like GitHub Copilot, code assistants, and auto-summarization tools) are seeing a closer match between how they want to spend their week and how they actually spend it. Not because AI is doing their jobs for them but because it’s helping clear the clutter.

That’s the real product insight: AI isn’t just another feature you bolt onto a dev tool. When it’s done right, it acts as a force multiplier. It automates the repetitive, low-value work that usually derails focus so developers can stay in their flow state longer. But the flip side is just as important: if AI adds complexity or noise, it becomes another source of interruption. We have to be deliberate about where and how we apply it.

So... What Should We Actually Do?

It’s really tempting to jump straight into solution mode. But the first move isn't to fix it. It’s to understand.
‍Before we throw new tools, new processes, or new initiatives at the problem, we need to take a real, honest look at what the developer experience actually feels like today.

Here’s a simple way to break it down:

People

• Are developers overwhelmed by communication overload?
• Are code reviews and approvals turning into bottlenecks?
• Are roles, responsibilities, and ownership clear or does every task feel like a game of telephone?
  

Tools

• Are our tools genuinely helping or just adding more clicks, tabs, and overhead?
• Is constant context-switching draining more energy than it’s saving?
• Are our integrations automating real work, or just creating new layers of friction?
• Can our tools’ value be measured and proven?
  

Process

• Are meetings amplifying impact or just eating up time?
  Are workflows making work visible or are they quietly creating hidden, invisible tasks that pile up?
• Can we measure the impact of our people, processes and tools on business initiatives and overall outcome?

We recommend starting with a simple 3-step approach.

Step 1: Get the Right Data

Start with the basics. You don’t need “N” number of dashboards   what you need is a few key signals that reveal where energy is leaking:

At Harness, we believe in anchoring to DORA metrics first because they tell you whether your team is predictably delivering value:

• Deployment Frequency: How often is working software reaching production?
• Lead Time for Changes: How quickly can you move from idea to deployable code?
• Change Failure Rate: When you ship, how often do you cause issues?
• Mean Time to Restore: How fast can you recover when things break?

DORA gives you the high-level outcomes but not the full story. Once you establish that baseline, you drill deeper into flow metrics to uncover where energy is leaking day-to-day. Specifically, track:

• Cycle Time: How long does it take to move work from “start” to “done”?
• Pull Request Review Duration: How long are PRs sitting idle? Where do reviews get stuck?
• Deployment Delays: After the code is merged, how long until it’s actually shipped?

And just as important: Pair quantitative metrics with qualitative feedback.

• Run anonymous developer experience surveys.
• Capture how developers feel about their day-to-day not just how fast they’re moving tickets.

Look for the early warning signs: Long review queues. Increased context-switching. Meetings that nobody wants but everyone attends. Friction shows up before velocity drops; you just have to know where to look.

Step 2: Understand the Context

Numbers alone aren’t enough. Metrics tell you what’s happening but they’ll never tell you why.

You might see a spike in pull request cycle times.

Is it because teams are slacking off?
Or because reviewers are spread across too many projects?
Or because no one knows who’s responsible for the next action?

You need real conversations. You need to hear the "why" directly from the people living it every day.

Treat data as a conversation starter, not a final answer. The goal isn’t just to measure experience, it's to understand it.

Step 3: Act with Insight

Once you understand the landscape, act deliberately.

• Prioritize bottlenecks that drain energy, not just those that slow throughput. (Developer burnout is a bigger threat than a slow sprint.)
• Be intentional with AI and automation. Focus on automating repetitive, mentally draining tasks, not the meaningful ones developers actually enjoy solving.
• Design for deep work. Protect focus time. Build workflows that amplify heads-down problem-solving, not constant multitasking.

The goal isn’t more activity, it's more effective workweeks.

How Harness Software Engineering Insights can help you here?

This is exactly the problem we built Harness Software Engineering Insights (SEI) to solve.

• We help you track the very foundational delivery metrics like DORA (Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Mean Time to Restore).
• It surfaces where flow is breaking down across tools, across people, across processes.
• It goes beyond vanity dashboards to provide actionable insights you can actually do something with.

We don’t believe metrics alone fix anything.

Our real North Star isn’t a better report card. It’s a better developer week.

Metrics are just the starting line. The real value comes from creating environments where developers spend more time building, solving, and innovating and less time stuck in endless loops of coordination and rework.

The North Star: Rebuilding the Developer Week

Building great products isn’t just about shipping roadmaps and features faster.
It’s about building environments and systems where people can do their best, most meaningful work.

If our developers feel stuck in a “Time Warp” consumed with a week full of meetings, blockers, and busy work, then no amount of AI, velocity tracking, or sprint burndowns will fix morale.

The next frontier isn’t just shipping faster. It’s about helping developers reclaim better weeks. And this is where leadership plays a critical role. With Harness SEI, we empower leaders with crystal-clear visibility into how their teams actually work, highlighting where flow is breaking down, where friction builds, and where leaders can step in to remove barriers. The goal isn’t just to optimize metrics it’s to free developers to do what they love best: building, creating, and solving meaningful problems.

Helping developers close the gap between the real and the ideal week isn’t just about improving productivity metrics. It’s about restoring a sense of purpose, ownership, and flow of the very things that make engineering such a creative, energizing craft. And I think that’s a future worth obsessing over.