Founder's Desk
When a team that used to ship quickly starts slowing down, most managers reach first for a people explanation: motivation, skill, effort. In our experience diagnosing this across many engagements, the honest answer is almost always systemic rather than personal, and finding it requires looking at data, not vibes.
Why the instinct to blame people is usually wrong
When a team's output slows down, the instinctive question is usually about the people: are they working hard enough, are they skilled enough. That's rarely where the actual answer lives. Productivity issues are usually systemic, rooted in process, tooling, or unclear requirements, and treating them as a people problem first tends to waste time and damage trust before the real cause gets addressed.
Lines of code, commits per day, and even story points closed all measure activity, and activity is a poor proxy for actual value delivered. A team can look highly productive by these numbers while shipping features nobody uses, or while quietly accumulating the kind of technical debt that slows the next quarter down.
The more useful question isn't "how much did the team do" but "how much friction did the team fight through to do it." That reframing points you toward the actual levers: how long code sits waiting for review, how often a deploy gets rolled back, how many context switches an engineer absorbs in a day.
Cycle time is the honest signal
Context switching is one of the least visible productivity killers, because it doesn't show up in any single metric. An engineer pulled into three unrelated Slack threads and a production incident before lunch will look, on paper, like they simply had a slow day. The actual cost is the ramp-up time lost every time they have to reload context after each interruption.
The invisible cost of context switching
Cycle time, the time from starting work on something to it being live, tends to expose the real bottleneck faster than almost any other single number. A long cycle time with fast individual coding usually points to slow review, unclear requirements, or deployment friction, not to engineers writing code too slowly.
Breaking cycle time into its component stages, coding, review, waiting for a deploy window, QA, usually reveals that one specific stage is eating most of the time, and that stage is almost always where the fix belongs.
Start with the data you already have
Before concluding a team has a productivity problem, pull the cycle time breakdown for the last month and look at which stage has grown. In most cases the diagnosis is sitting in that data already, waiting to be looked at, rather than requiring a new dashboard or a difficult conversation about effort.
