We track sprint velocity but ignore that engineers spend 68% of time NOT coding. Are we measuring the wrong thing?

product_david · March 28, 2026, 1:21am

I had a moment of clarity last week during quarterly planning. We were celebrating our velocity improvements—story points up 18% quarter-over-quarter. The engineering team nodded. Then someone asked, “So why didn’t we ship more features?”

Awkward silence.

Here’s what I discovered when I actually dug into the data: our engineers spend only 30-32% of their time writing code. The rest? Meetings (20%), context switching (20%), and coordination overhead (the remaining ~28%). And this isn’t just us—research from 2026 shows this is the norm across the industry.

The Productivity Paradox

We’ve been obsessing over coding productivity. AI tools save our developers 3.6 hours per week. GitHub Copilot, Cursor, Claude Code—all impressive. But here’s the uncomfortable truth: our organizational delivery speed hasn’t improved.

Individual developers are faster. The organization isn’t.

Why? Because we’re optimizing for 32% of the problem.

What We’re Actually Measuring

Sprint velocity: Story points completed per sprint
PR merge rate: How many PRs get merged per week
Cycle time: Time from first commit to production

What we’re NOT measuring:

Time spent waiting for decisions: How long engineers sit idle while product, design, or leadership debates direction
Context switching cost: Each switch costs 20-30 minutes of recovery time to regain focus
Coordination overhead: The exponential tax as teams scale without structural changes
Meeting quality: Are we in “necessary alignment” or “status theater”?

The Business Impact

From a product perspective, this matters because our customers don’t care about our sprint velocity. They care about when their feature request ships. And right now, the gap between “code is written” and “customer has access” is growing.

Our competitors have the same AI tools. Coding speed is no longer a differentiator. Decision speed is.

A Different Framework

What if we measured “time to unblocked” instead of story points?

What if we tracked “necessary collaboration time” vs “low-value meeting time”?

What if we designed our organization to reduce friction instead of just increasing throughput?

Some research suggests that self-service infrastructure can make developers 3-5x faster—not because they code faster, but because they spend less time asking for permissions, waiting for approvals, or coordinating across teams.

The Real Question

Are we solving the wrong problem?

We’re investing in AI coding assistants to speed up the 32%. But the 68%—meetings, alignment, context switching—that’s where the real bottleneck lives. And unlike coding, that problem gets WORSE as you scale, not better.

I’m curious: What are other teams tracking beyond velocity? Are you measuring coordination overhead? Meeting quality? Decision latency?

And more importantly: are you doing anything about it?

eng_director_luis · March 28, 2026, 1:21am

David, this resonates deeply. We’re living this exact pattern with my 40-person team in fintech.

The coordination tax is real, and it compounds as you scale. Here’s what we discovered:

Our data looks similar to yours:

Cross-team dependencies increased 3x as we grew from 20 to 40 engineers
Context switching is even worse in financial services—every feature touches compliance, security, and operations
Engineers report spending 45% of their week in “coordination activities” (meetings, Slack threads, waiting for approvals)

We tried an experiment: “Focus Fridays”

No meetings. Slack on Do Not Disturb mode (emergencies only). Everyone knew not to interrupt unless production was literally on fire.

Results after 8 weeks:

15% increase in deployment frequency
Developers reported it as their “most productive day of the week”
Code review velocity improved (fewer interruptions = deeper reviews)

But here’s the uncomfortable part:

It didn’t solve the fundamental problem. Customer-facing issues still create interruptions. Business urgency doesn’t respect “focus time.” And honestly? Sometimes those “interruptions” are actually valuable collaboration.

The real tension:

Product teams (understandably) optimize for responsiveness and iteration speed. Engineering teams need deep focus time. These aren’t bad priorities—they’re just in conflict.

The question I keep coming back to: How do product teams balance urgency vs flow?

When you say “decision speed is the differentiator,” I agree. But fast decisions still require engineer input, which means interrupting someone’s focus. How are you thinking about this tradeoff at your company?

What I’m learning: The problem isn’t meetings vs coding time. It’s low-value coordination overhead vs high-value collaboration. But measuring the difference? That’s the hard part.

vp_eng_keisha · March 28, 2026, 1:22am

Both of you are hitting on something critical: this is fundamentally an organizational design problem, not a developer productivity problem.

At 80+ engineers, I’ve seen coordination overhead become exponential. Here’s what that looks like in practice:

The scaling trap:

At 20 engineers: Everyone knows what everyone else is working on
At 40 engineers: You need sync meetings to stay aligned
At 80+ engineers: You have meetings to prepare for the sync meetings

The coordination overhead doesn’t scale linearly. It compounds.

What actually worked for us: Team Topologies

We reorganized around stream-aligned teams with clear boundaries:

Each team owns an entire value stream (not a layer of the stack)
Platform team exists to reduce “ask for permission” bottlenecks
Explicit interaction modes: collaboration, X-as-a-service, or facilitation

Results after 6 months:

Reduced cross-team sync meetings by 40%
“Time to decision” dropped from 4 days average to 1.5 days
Developer satisfaction scores improved 23%

But here’s what the data really shows:

Psychological safety matters MORE than meeting reduction.

We measured this. Teams that felt heard and valued in fewer, high-quality meetings outperformed teams with more “focus time” but lower trust. The metric that mattered wasn’t “hours of uninterrupted coding”—it was “confidence in team decisions.”

The metric shift Luis mentioned is real:

We stopped tracking:

Lines of code
PRs merged
Story points

We started tracking:

Decision velocity: How fast can a team make and act on a decision?
Dependency wait time: How long does a team spend blocked on another team?
Context preservation: How much time is spent re-explaining context because it wasn’t documented?

David’s question about what we’re measuring beyond velocity?

We track “organizational friction time”: The delta between when code is ready and when it ships to customers. That gap is almost never about coding speed. It’s about:

Waiting for architectural decisions
Waiting for design review
Waiting for security approval
Waiting for deploy window

The uncomfortable truth:

AI tools are making individual contributors faster, but they’re exposing that the real bottleneck is organizational design, not typing speed.

Self-service infrastructure is part of the answer, but it’s not just about provisioning environments. It’s about architecting autonomy—giving teams the authority and capability to ship without constant coordination.

What would it look like if we designed organizations for flow instead of control?

cto_michelle · March 28, 2026, 1:22am

I’m going to take a contrarian position here: Maybe 30% coding time is optimal, not a problem to solve.

Hear me out.

Software engineering is knowledge work, not factory work. The best code often comes from:

Thinking deeply about the problem
Understanding customer needs through conversation
Alignment on architectural direction
Reviewing others’ approaches and learning

The romantic notion of the “10x engineer” with headphones on, cranking out code in isolation—that’s not how complex software gets built.

The real problem isn’t meetings. It’s low-value meetings.

I spent the last year ruthlessly categorizing our meetings into two buckets:

Necessary alignment: Architecture reviews, cross-functional planning, incident retrospectives
Status theater: Daily standups that could be async, update meetings that repeat what’s already in Jira

We killed the status theater. We doubled down on necessary alignment.

Results:

Meeting time reduced by 35%
But collaboration time (pairing, architecture discussions, design reviews) actually INCREASED
Deployment frequency up 28%
Critical bug rate down 19%

Here’s what changed:

We stopped treating “heads down coding time” as the ideal state. Instead, we optimized for informed decision-making velocity.

Example: We killed daily standups entirely. Instead, engineers write a 2-minute async update 3x per week. If there’s a blocker, there’s a Slack channel specifically for “I need unblocking” requests, and someone responds within 2 hours (SLA we measure).

But we KEPT architecture review sessions. And we ADDED dedicated pairing time for complex problems.

David’s point about decision speed is spot on.

But I’d add: The quality of those decisions matters more than the speed. A fast bad decision costs you weeks. A slightly slower good decision saves you months.

Luis’s question about balancing urgency vs flow?

My team uses explicit “interrupt protocols”:

Red (production down): Interrupt anyone
Yellow (customer escalation): Interrupt the on-call rotation
Green (everything else): Respect focus time, use async

Engineers can set their own status, and we measure whether interruptions match the protocol. Turns out, 73% of interruptions were Green being treated as Yellow.

Keisha’s organizational design point is brilliant.

But I’ll add: Sometimes the problem isn’t structure—it’s culture.

If your culture treats “typing code” as the only valuable work, engineers will feel guilty about spending time on design, architecture, or mentoring. And that’s where the real leverage is.

Are we romanticizing “heads down coding” as the ideal state when the reality is that software engineering is a team sport played on the field of organizational systems, not individual productivity?

maya_builds · March 28, 2026, 1:23am

Reading this thread as a designer, I’m having major déjà vu. We face the exact same thing.

Design reality check:

25% of my time is actual design work (Figma, prototyping)
35% is meetings and feedback sessions
25% is context switching between requests
15% is documentation and handoff

Sound familiar?

The “can you mock this up real quick?” problem

Engineers optimize for uninterrupted flow. Designers live in a world where everyone thinks design tasks take 5 minutes. “Can you just change the color?” “Can you mock up this feature idea?” “Quick question about this button…”

Context switching for creative work is BRUTAL. It takes me 30-45 minutes to get into the flow state where I can do my best work. One Slack ping kills that.

What actually worked: Design systems

We built a component library with clear documentation. Now when someone says “can you design a form?” I point them to the form patterns. 60% reduction in “quick design requests.”

But here’s what I learned: That only works because we invested heavily in async documentation.

Every component has:

Usage guidelines
When to use it (and when NOT to)
Accessibility notes
Code examples

Michelle’s point about “status theater” vs “necessary alignment”—we did the same thing. Killed the “design review meetings” where we just showed screenshots. Replaced with:

Async design uploads with written context
Figma comments for specific feedback
Live sessions ONLY for complex decisions or brainstorming

But here’s the uncomfortable truth from my startup failure:

My previous company failed partially because we optimized TOO much for individual flow and not enough for team alignment.

We were a fully remote team. Everyone had tons of focus time. We shipped features fast. But:

Features didn’t connect into a coherent product
No one understood the full picture
Architectural decisions were made in isolation
When we realized we were building the wrong thing, we’d already wasted 3 months

The balance is hard.

David’s framing of “are we solving the wrong problem?” hits different when you’ve watched a company die from too much isolation.

Engineers romanticize the myth of the lone genius coder. Designers romanticize the solitary artist having a creative breakthrough. But the best products come from messy, imperfect collaboration.

Here’s what I think we’re missing:

The question isn’t “coding time vs meeting time.”

The question is: Are we distinguishing between flow work (deep focus) and collaboration work (shared context building)?

Both are valuable. Both are necessary. But they need different structures:

Flow work needs protection (time blocking, async-first communication)
Collaboration work needs intention (clear outcomes, right people, documented decisions)

The problem is when we treat ALL meetings as bad and ALL coding time as good. That’s just… wrong.

What if we measured “alignment quality” instead of “meeting time”? What if we tracked “decisions made per hour of collaboration” instead of “hours of focus time”?

Maybe the real metric is: Can your team ship the RIGHT thing efficiently? Not just ship things efficiently.