Finishing is the only work that matters.
While that sounds obvious, nearly every organization I have worked in has a graveyard of projects that made it to eighty percent and no further. And a longer list of good ideas that never made it out into the real world.
This post is about the unglamorous discipline of closing the gap between idea, almost done, and done.
The ideas that don’t see the light of day.
Founders and leadership teams notoriously generate ideas constantly. We should integrate with this platform. We should build this capability. We should demo the product at that community event. We should hire this expertise. The ideas are often great.
Unfortunately, idea generation and idea execution are very different skill sets, and many founding teams lean heavily toward the former and struggle with the latter. While one idea is still being worked on, a new one arrives at the table and threatens to derail the team. The result can be a widening gap between what has been envisioned and what has been shipped.
As an operator, the temptation might be to act on every new idea, allowing what is in flight to derail. Or to push back on every new idea, spending relationship capital arguing against what was often just a thought said out loud.
In my experience, the right response is to simply capture those great ideas without debate. Use a kanban board, a set of stickies, a spreadsheet, or a slide, whatever works. But every year (or quarter), review the list, pick the top ones for execution, and let all the others go. The year on the shelf lets time do the sorting: passing enthusiasms fade quietly while the ideas that keep resurfacing reveal themselves as real. And the annual release keeps the list from becoming what most idea backlogs become: an ever-growing monument to things nobody will ever do. No one has to actively kill any single idea; time does it for them.
An idea returns nothing until it is completed, implemented, and operationalized. Spoken is not started. Started is not finished. Only finished counts. The list, and the discipline of clearing it, is how you keep the space between those states honest.
The anatomy of the stall.
Project and dev teams consistently get things eighty to ninety percent done and then stall.
Sometimes the stall happens because the client hesitates to move to production, and the team drifts to other work. Sometimes the team declares work is “basically done,” which is the most frightening phrase in software development, because it means no one really knows what is still left to be done. Sometimes it comes in the form of a perfectionist: I once watched a build take two years to travel from eighty percent to done as an otherwise talented dev tinkered endlessly.
And underneath all of these is the truth about the last stretch of any project: it is boring. It is a slog of testing, cleanup, edge cases, more testing, documentation, training, and last-minute fears surfacing as must-have requirements as reality looms. The exciting part of the work ended weeks ago. What remains is effort without any fun, and the kind of effort teams are worst at supplying to themselves.
That is where the operator comes in.
The finishing move.
Dragging something across the line is not a talent. Rather, it is a sequence of unpleasant activities executed tightly.
- Define what finished looks like, concretely. “Code complete” or “ready for review” are not finished states. Finished for a project can mean everything is in production and a real payment has moved through the system. It sounds obvious, but teams often interpret finished as getting their own work done, not the software working as intended for a client.
- Create a list of every minute task standing between here and finished. The list will be longer than anyone expects, but it becomes a rallying document, giving the team hope that things are actually winding down.
- Manage the list relentlessly. Follow up with people. Manage the back and forth between client and team. Test, and then test again. All of it is the difference between almost done and actually done.
The judgment call.
An obvious objection to all of this: surely not everything at eighty percent deserves to be finished. Some projects should be killed, not closed.
My position is that if work made it to eighty percent, there was a real need behind it, and the better call is almost always to finish. The operator’s job at this stage is simply to clear space so the team can close it out.
However, finishing can be the wrong call if a project was a mistake in the first place. Early in my journey as an operator, I watched a quick-and-dirty integration that should never have been built get partially completed and then eventually abandoned. The lesson was not that we killed it too late. The lesson was that we never should have started it in the first place. Most projects that deserve to die at eighty percent deserved to die at zero.
The necessary evil
The last ten to twenty percent of a project is not enjoyable. I certainly don’t enjoy it, and probably no one does. The excitement left the room long ago, everyone has emotionally moved on to the next thing, and what remains is follow-ups and test cases and the same conversation about production readiness.
But that last stretch is where success lies. It is the toll between all the work that came before and any of the value it was supposed to create. Anything worth having requires effort, which is why supplying it is one of the most valuable things an operator does.
The operator guards both ends of the pipeline: the idea list keeps new thinking from derailing work in flight, and the finishing move carries that work the last hard stretch to done.
The operator ensures the team finishes the current thing before moving on to the new thing. In that order, always.






