One of the most demoralizing things a founder can experience: you've hired genuinely talented people, you're paying market rates, and you're still not shipping fast enough.
The temptation is to blame the people. Resist it.
In almost every case we've seen, the problem isn't the people. It's the system the people are working inside. Talented individuals can be made dramatically unproductive by bad processes, unclear ownership, and constant context-switching.
Here's how to tell the difference, and what to do about it.
The System vs. The Person Test
Before you conclude that someone is underperforming, answer these questions:
- Can they articulate exactly what they're responsible for? Not a vague job description: a specific list of outcomes they own.
- Do they have everything they need to do their job without asking for permission or information? Access, context, authority.
- How much of their day is unplanned interruptions vs. planned focused work?
If the answer is no to #1, no to #2, or "most of it" is interruptions on #3: the system is broken. Fixing the person won't help.
The Five Productivity Killers We See Most Often
1. The "Who Owns This?" Problem
When two people think they own something (or nobody does), work slows to a crawl. Engineers wait for clarification. Meetings get called to resolve ambiguity that should never have existed. Decisions get made twice.
This is almost always a root cause when teams feel "slow despite working hard." Everyone is busy; nobody is making progress.
Fix: Create an ownership map. For every product area, system, and function: one name. One person who makes the call, who is accountable if it goes wrong, who doesn't need permission to move.
2. Context-Switching
Deep work requires sustained, uninterrupted focus. Context-switching (moving between tasks every 30 minutes) has a real cost: each switch means rebuilding the picture of the problem, and a study of interrupted work found that interrupted people work faster to compensate but report more stress and frustration.
Most startup engineering teams are absolutely terrible at protecting focus time. Slack is always on. Standups are mid-morning. Questions get answered immediately because responding fast feels like being helpful.
Fix: Protected focus blocks. No meetings before 11am. Async by default. Response time SLAs that give people permission to not be instantly available.
3. The Dependency Chain
Engineer A is blocked waiting on a decision from Product. Product is waiting on data from Analytics. Analytics is waiting on a schema change from Engineering.
These chains are invisible until you map them. But they're often the real reason sprints overrun.
Fix: Map your critical paths for every major initiative. Identify dependencies before the sprint starts, not when they hit.
4. Unclear Definition of Done
How many times have you seen a ticket marked "Done" that then generates 3 rounds of revision because "done" meant different things to different people?
This is especially common in teams where product and engineering don't have shared standards.
Fix: Write acceptance criteria for everything above a certain complexity threshold. This feels slow. It is dramatically faster.
5. Interruption-Driven Work
The founder who walks over to ask for a quick favor. The urgent Slack message that requires a context switch. The emergency that takes 4 hours because the underlying system is fragile.
Interruption-driven work is the enemy of predictable velocity. It's also almost always a symptom of upstream problems (poor planning, fragile systems) that cause downstream chaos.
Fix: Categorize your interruptions for one week. What kinds of things are breaking the flow? Those are your process gaps to fix.
How to Run a Productivity Audit
Here's a lightweight version of what we do in the first week of an engagement:
1. Time tracking (3-day sample)
Ask each engineer to track how they spend time in 30-minute buckets for 3 days. Not for surveillance, for diagnosis. The goal is to understand: what is actually consuming time vs. what should be consuming time?
In the teams we have audited, planned work is usually well under the full day. The rest is interruptions, meetings, waiting, and coordination overhead.
2. Blocker log
For 2 weeks, maintain a shared doc where anyone can log: "I am blocked because ___." Review it weekly.
The patterns that emerge tell you exactly what's slowing people down. They're also a forcing function: blockers become visible and therefore get fixed.
3. Meeting audit
Count every meeting on the calendar. For each one: Is this decision-making or information sharing? Could this be async? What would break if this meeting didn't happen?
Most teams we work with can cut a large share of their meetings without any loss of alignment.
The Honest Truth
If your team has talented people and slow output, you have a process problem. The good news: process problems are fixable. The bad news: they require deliberate effort to fix.
You can't solve a systems problem by working harder. You solve it by redesigning the system.
Want a structured way to audit what's actually slowing your team down? Let's talk.