Home Blog Engineering Team Productivity
Engineering

Why Your Engineering Team is Losing 5+ Hours a Week (And What to Do About It)

✍ Projiq Team 📅 July 20, 2026 ⏱ 8 min read

Ask any engineering manager what their team's biggest productivity problem is. You'll hear answers like "too many meetings," "unclear requirements," or "we move too slowly." Rarely will anyone say "our project management tooling is costing us $300k a year."

But that's often exactly what's happening. A 2023 McKinsey study found that knowledge workers lose an average of 5.4 hours per person per week to tool switching, status meetings, and duplicated coordination work. For a 20-person engineering team at a $60/hr blended rate, that's over $336,000 lost every single year — not to bad code, not to bugs, but to the friction of how work is managed.

This article breaks down exactly why it happens, how to calculate your team's real cost, and five fixes that actually move the needle.

5.4h
lost per person per week (McKinsey)
$337k
annual cost for a 20-person team at $60/hr
68%
of that time lost to status meetings & context switching

Why It Happens: The 4 Root Causes

The lost hours aren't random. They cluster around four specific failure modes — each one predictable, measurable, and fixable.

01

Tool Fragmentation

Tasks in Jira. Specs in Confluence. Status in Slack. Timeline in a spreadsheet. Engineers waste 40–60 minutes daily just switching contexts and hunting for the current source of truth.

02

Status Meetings That Exist to Compensate for Bad Tooling

If your PM tool doesn't show real-time status, you schedule a meeting to get it verbally. The average team runs 3–5 of these a week. At 30 minutes each, that's 2.5 hours of every engineer's week — just reporting on things that should already be visible.

03

Manual Status Updates

When moving a ticket from "In Progress" to "In Review" requires 4 clicks, people skip it. Tickets go stale. Managers lose confidence in the board. So they ask for Slack updates instead — and now you have two places to maintain.

04

Unclear Ownership & Duplicated Work

Without clear assignment and visibility, multiple engineers sometimes work on the same problem. More often, things fall through the cracks entirely because everyone assumed someone else had it.

Calculate Your Team's "PM Tax"

Before you can fix the problem, you need to know its real cost. Here's a simple formula:

Annual PM Tax = (team size) × (hours lost per week) × (blended hourly rate) × 52

Use conservative numbers. Even at 3 hours lost per person per week — well below the McKinsey average — a 30-person team at $55/hr is losing $257,400 annually.

💡 Quick Audit Ask your team two questions in your next retrospective: (1) How many minutes did you spend yesterday looking for information that should have been in your PM tool? (2) How many Slack messages did you send or receive that were really just status updates? Multiply those numbers up and you'll have your real figure.

The point isn't the exact number — it's that the number is almost always shockingly large. And once it's visible, it becomes a business case for fixing the tooling rather than just tolerating it.

5 Fixes That Actually Work

1. Consolidate to a Single Source of Truth

The single highest-ROI change most teams can make is picking one tool that covers tasks, status, and timeline — and actually using it. Not Jira for tasks + Notion for specs + Linear for bugs. One system.

This sounds obvious, but it requires discipline. Every team member needs to trust the tool enough to look there first before pinging someone on Slack. That trust is built by keeping the board accurate — which brings us to fix number two.

2. Make Status Updates Happen as a Byproduct of Work

The best PM tools make status updates trivially easy — drag a card, press a shortcut, change a dropdown in one click. When updating takes longer than 10 seconds, adoption breaks down.

Even better: integrate your PM tool with your code. When a PR is opened, the linked issue automatically moves to "In Review." When the PR merges, it moves to "Done." Suddenly, engineers don't need to manually update tickets at all — the work itself drives the status.

Status Update MethodTime per UpdateWeekly Cost (20-person team)
Slack message to manager~3 min (compose + reply)~10 hrs
Manual ticket update (4 clicks)~45 sec~2.5 hrs
One-click drag on board~5 sec~17 min
Automated via PR/commit hook0 sec0 hrs

3. Kill the Status Meeting — Replace It With Board Reviews

The daily standup was designed to surface blockers, not report status. But when the board isn't trusted, standups drift into status recaps. Engineers go around the room saying what they're working on — information that's already supposed to be on the board.

Once your board is accurate and real-time, the standup changes character entirely. Instead of "what is everyone working on?" the question becomes "who's blocked and what do we do about it?" That's a 10-minute conversation, not a 30-minute meeting.

⚠️ Common Mistake Don't cancel the standup before the board is trusted. Engineers will feel disconnected and you'll just shift the status-reporting problem to async Slack threads. Fix the board first, then reduce the meeting frequency.

4. Set Up Explicit Role Assignment at the Sprint Level

Duplicated work and dropped balls both come from the same root cause: unclear ownership. Every ticket should have one owner. Not a team, not a sub-team — one person who is accountable for it moving forward.

This doesn't mean one person does all the work. It means one person is responsible for making sure the work gets done — escalating if blocked, updating the status, splitting the ticket if it's too large. It's the difference between "AUTH-441 is owned by the platform team" and "AUTH-441 is owned by Sarah and she knows it."

5. Run a Quarterly Tooling Audit

Tool sprawl accumulates gradually. A new Notion doc here, a Loom folder there, a shared Figma board that became the de facto spec library. Every quarter, audit your team's actual workflow:

  • Where does information actually live vs. where it's supposed to live?
  • Which tools are being used by everyone vs. only a few people?
  • What information needs to exist in two places because the tools don't talk to each other?

Each item in that third category is a manual sync tax on someone's time. Eliminate it either by consolidating tools or by building an integration.

What Teams Actually Get Back

Teams that go through this process — consolidating tooling, making updates frictionless, and replacing status meetings with board reviews — typically report getting back 3–5 hours per person per week.

That's below the McKinsey average of 5.4 because not all of the lost hours are recoverable through tooling alone. Some of it is organizational culture, meeting habits, and communication norms that take longer to shift.

But 3 hours per person per week is still significant. For a 20-person team, it's 3,120 engineering hours per year. Directed at product work, that's the difference between shipping 2 major features and shipping 5.

See the difference a better PM tool makes

Projiq is built for engineering teams who've felt this pain — real-time boards, one-click status updates, and PR-linked issue tracking that makes manual updates unnecessary.

Start Free Trial — No Card Required →

How Projiq Addresses Each Root Cause

Root CauseWhat Projiq Does
Tool fragmentationTasks, sprints, timelines, and team management in one platform — no Confluence, no separate spreadsheets
Stale ticket statusReal-time board updates via Socket.io — every move reflects instantly for all team members
Status meeting overheadManager dashboard shows live sprint progress, blockers, and team workload — no meeting needed to get this view
Unclear ownershipEvery issue has a single assignee; sprint assignment is visible at the org and project level simultaneously
Onboarding friction5 clear roles (Viewer → Admin), no permission schemes, new engineers are productive on day one

Frequently Asked Questions

How many hours do engineers really waste on project management tasks?
McKinsey research found that knowledge workers lose an average of 5.4 hours per person per week to tool switching, status meetings, and duplicated coordination work. For software engineers specifically — who context-switch between code, tickets, Slack, and documentation — the real number is often higher. The best way to get your team's actual number is to run a quick retrospective exercise: ask everyone to estimate how long they spent yesterday on coordination tasks that weren't directly writing code or reviewing PRs.
What is the annual cost of poor project management for an engineering team?
For a 20-person team at a blended rate of $60/hr, 5.4 wasted hours per person per week equals $336,960 lost annually. For larger teams or higher hourly rates, the number climbs fast: a 50-person team at $80/hr loses over $1.1M per year. This is only direct labor cost — it doesn't include the opportunity cost of delayed features, slower time-to-market, or customer churn from slower delivery cycles.
Can you really eliminate status meetings?
Yes — but only after your PM board is consistently accurate. The standup exists to compensate for invisible work. Once the board is trusted as real-time truth, managers can get status by looking at the board, and standups can shift entirely to blocker resolution. Most teams that make this transition reduce standup frequency from daily to three times per week, and duration from 30 minutes to 10 minutes. The key is getting board hygiene right first — cancel the meeting prematurely and you just shift status reporting to Slack threads.
How long does it take to see productivity improvements after switching PM tools?
Most teams see measurable improvements within 2–4 weeks of fully adopting a new tool. The first week is adjustment — people are still in old habits. By week two, the board starts to stay current. By week four, managers report that they're spending significantly less time chasing status updates, and engineers report fewer interruptions. The biggest gains come from standup reformation, which typically happens naturally once the board is trusted — usually by the end of the first sprint cycle.
What's the most important feature to look for in a PM tool for engineering teams?
Adoption — specifically, whether engineers actually keep the board updated in their daily workflow. The most powerful PM tool in the world is worthless if your team treats it as a reporting tool they update once a week for the sprint review. Look for tools where the default action (moving a PR, closing a branch, deploying a build) also updates the ticket automatically. The less manual effort required to keep the board current, the more accurate it will be — and accuracy is what unlocks all the downstream benefits.