Stop Starting, Start Finishing: How Doing Less Hit Our Revenue Target

This is a story about a domain that was busy but not finishing, and what happened when we cut the number of projects in progress. I am sharing it because it changed how I think about speed.

The situation

I had just joined a new domain. The domain had a clear goal: deliver a set of new initiatives that would grow revenue.

Each initiative could be delivered on its own. So the leads had given one initiative to each engineer. On paper, this was the fastest way to get everything done.

In practice, nothing was getting done.

What was going wrong

Four problems were feeding each other.

Too much work in progress. Everyone was busy. But we were great at starting things and poor at finishing them. Busy is not the same as done.

Knowledge stuck with one person. Each initiative lived in one engineer’s head. When that person was sick or on leave, their initiative stopped. Nobody else could pick it up.

A false sense of progress. Eight initiatives at 60% looks like a lot of work. It earns no revenue. Only shipped initiatives do.

No collaboration. Our daily meeting had become a round of status reports. Each person described their own initiative in their own terms. Nobody understood anyone else’s work, so nobody could help.

The revenue target was slipping further away every week.

What we changed

I proposed something that felt backwards: do fewer things at once.

We:

1. Moved most initiatives back to the backlog. We kept only the few that would bring the most revenue if we shipped them sooner.
2. Paired engineers on those few initiatives. Two or three people per initiative, instead of one.
3. Stopped starting new work until something shipped.

The domain pushed back at first. Some engineers felt their work had been taken away. Others worried that slowing down was the wrong move when we were already behind. Those are fair concerns, and I did not dismiss them. I asked everyone to give it a few weeks and judge it by the results.

What happened

Within a few weeks, the change was visible.

• We finished things. With fewer items open, initiatives reached “done” instead of sitting at “almost”.
• The daily meeting became useful. Because people shared work, they understood each other. Status reports turned into problem-solving.
• Nobody’s absence stopped an initiative. Pairs meant at least two people knew every piece of work.
• We beat the target. We shipped every initiative we had kept. Then we pulled back some of the ones we had paused, and shipped those too. We ended the quarter ahead of the original revenue goal.
• Morale went up. Finishing feels good. The domain was more engaged than I had seen it.

The counterintuitive part is worth repeating: we did more by doing less at once.

What I took from it

Busy is not the same as done. A domain can work hard for months and move the needle by nothing, because revenue comes from what ships, not from what is in progress.

The fix felt like a step back. Pausing work, putting two people on one initiative, saying no to starting. Every one of those looked slower on the day we did it. Every one of them was faster by the end of the quarter.

And the domain was happier. Not because the work was easier, but because things got finished.

Since then, whenever a domain is busy and the needle is not moving, this is the first thing I look at.