Team reality

8 Engineers, Zero Ships, Six Months

Thirteen people, two roadmap reviews, nothing shipped to a customer in two quarters. How teams go busy and idle at once.

8 Engineers, Zero Ships, Six Months
Illustration · Deimar Gutiérrez

8 engineers. 3 product managers. 2 designers. 13 people. Two roadmap reviews. Zero customer-facing changes in two quarters. On paper the roadmap looked the part: detailed PRDs, clean mockups, a backlog of ambitious bets that had quietly become the roadmap. Then the question that mattered landed. When did anything last reach a customer? A pause. The most recent ship was a small UI tweak, six months earlier, buried in an initiative still in flight.

The team had been busy the whole time. Standups, all-hands, quarterly reviews. The internal numbers looked healthy: commits, story points, PR throughput. The external number, the one a customer could feel, sat at zero. Busy and idle at the same time.

Three initiatives got built over those months. None shipped. One was deprioritized halfway. One got redesigned twice on customer feedback that arrived after the design was finished. One was done and waiting on a launch date that kept sliding. Net output to the outside world: nothing. Net effect on the team: frustration, and a few people quietly updating their resumes.

This is one of the most common failure modes in a growth-stage org, and it's structural, not a people problem. The team accumulated decision-makers. Each PM, designer, and lead holds real authority to hold a release back for polish, or research, or alignment. Every single delay is defensible. Stacked together, they raise the bar for shipping so slowly nobody notices it moving. Small changes start needing the coordination that used to move a big one.

The internal metrics hide it. Code is committing. Specs are written. Mockups ship to Figma, not to customers. Sprint completion looks fine. Every inside signal says the team is working. The only signal that counts, did anything reach a user, says otherwise. Teams report on internal velocity because internal velocity is what they control.

The morale cost runs deep and stays invisible. An engineer who hasn't shipped anything real in half a year loses the line between the work and its point. The work turns theoretical. Retros get more cynical than useful, the same action items every time. The strongest engineers leave first, because they want to ship and the company has quietly stopped letting them.

The intervention has no sentiment in it. Ship something within two weeks. Anything. The smallest customer-facing change on the board. The deadline drags the blockers into daylight. The PM who wants more research has to defend the delay out loud. The designer who wants one more pass has to price it. The lead worried about tech debt has to weigh it against the morale debt already stacking up.

The first ship will feel wrong. The bar climbed for months; dropping it back to healthy reads like a regression, and the team will push back. Ship anyway. That first one is the hinge. The second is easier. Four ships in four weeks, and the cadence the last six months erased is back.

If your team hasn't shipped in two months, stop reading the internal dashboard. Pull the changelog. Ship something this week.