In 2018, Basecamp published a detailed account of how their team had been quietly losing speed on their Hey email product during early development. The culprit wasn’t scope creep or unclear requirements. It was something subtler: a growing pile of work that was technically complete but hadn’t been fully closed out. Features that worked but hadn’t been documented. Decisions that had been made but not communicated. Tasks that were marked done in the project tracker but still occupied mental space because someone, somewhere, hadn’t fully let go of them.
Basecamp called these “open loops.” Psychologists had a name for the underlying mechanism long before that.
The Setup
In the 1920s, Soviet psychologist Bluma Zeigarnik ran a series of experiments on memory and interrupted tasks. She found that people remembered incomplete tasks roughly twice as well as completed ones. The brain, it turns out, keeps a background process running for anything unresolved. It’s useful for survival. It’s terrible for knowledge work.
The Zeigarnik effect isn’t just about tasks you haven’t started. It fires for tasks that are technically done but haven’t been closed in any meaningful sense. You sent the email but you’re waiting on a reply. You finished the feature but the pull request is sitting in review. You wrapped the project but the post-mortem is still in someone’s draft folder. These are all open loops, and your brain treats them as unfinished business.
For an individual contributor, this creates low-grade cognitive drag. You’re not paralyzed, but you’re also not fully present. For a team, the effect compounds.
What Happened at Basecamp
The Basecamp team’s approach to this problem is documented in their book “Shape Up,” which they’ve made freely available online. Their diagnosis was specific: the traditional to-do list, and the agile sprint backlog it resembles, is structurally optimized to accumulate tasks rather than close them. You can add a task in seconds. Closing one, truly closing it, requires deliberate effort that the system doesn’t enforce.
Their solution wasn’t a new tool. It was a new mental model. They introduced the concept of “scope hammering,” the active, ongoing process of deciding what a feature doesn’t need to ship. And they built their six-week cycles around a hard deadline that forced closure, not just completion.
The distinction matters. Completion is finishing the work. Closure is the act of definitively removing that work from the list of things your brain needs to track. A shipped feature with three unresolved threads in Slack is complete but not closed. A cancelled feature that’s been formally removed from the roadmap, with all stakeholders notified, is neither complete nor done, but it is closed.
Teams that only optimize for completion end up carrying an invisible backlog of half-closed items. Individually, each one is minor. Collectively, they create the sensation that there’s always more to do, even on days when you’ve technically finished everything on your list, which is a feeling most teams recognize immediately.
Why It Matters More Than You Think
The cost isn’t just psychological. Open loops have concrete operational consequences.
First, they contaminate prioritization. When you’re deciding what to work on next, partially-closed items compete with genuinely new work for attention. Because they feel urgent (the brain is pinging you about them), they often win, even when they shouldn’t. You end up doing micro-work on things that are 95% done instead of making progress on things that matter more.
Second, they create coordination overhead. An open loop in one person’s head is invisible to everyone else unless they explicitly surface it. This produces the pattern you’ve probably seen: a standup where someone says “I’m still wrapping up X” for three days in a row, not because they’re slow, but because “wrapping up” contains a dozen small closure tasks that nobody accounted for in the original estimate.
Third, they accumulate technical and organizational debt in ways that are hard to audit. The to-do list that’s built to grow is the symptom; the open loop is the disease. Every item that gets added to a running list without a clear closure criterion is a liability.
What You Can Learn From This
The Basecamp model suggests three practical changes you can make to how you and your team handle work.
Define closure explicitly, not just completion. For any significant piece of work, write down what “closed” looks like before you start. This isn’t just “feature is shipped.” It might be: feature is shipped, documentation is updated, team is notified in the relevant Slack channel, and the corresponding ticket is archived. If you don’t define it, you’ll default to “completion” and leave the closure work as an implicit afterthought.
Schedule closure time as real work. Most teams plan for the work itself and treat wrapping up as overhead that happens automatically. It doesn’t. Budget time for it. This is especially true at the end of project phases, when the urge to immediately start the next thing is strongest. Rushing straight into new work before fully closing the previous phase is one of the most reliable ways to build a cognitive debt that slows you down for weeks.
Do a weekly open-loop audit. Once a week, spend fifteen minutes asking a single question about everything currently in flight: is this closed, or does it still have an open thread somewhere? Not “is it done,” but “is there anything about this that still requires my attention or anyone else’s?” If yes, either schedule the closure work explicitly or make a conscious decision to abandon it. Both are valid. What’s not valid is leaving it in a state of ambiguous incompleteness.
This last point is important. Sometimes the right answer is to formally close something by deciding it won’t be finished. A decision to abandon something, clearly communicated and recorded, is a form of closure. It releases the loop. It’s the decision to neither abandon nor complete it that costs you the most.
The Practical Test
Here’s a useful way to pressure-test your own workflow. Look at your project tracker or task list right now and find five items you’d describe as “basically done.” For each one, ask: if you were hit by a bus tomorrow, would someone else know exactly what the remaining state of that item is, and what (if anything) needs to happen next?
If the answer is no, the loop is open. The work isn’t done, even if you’re done working on it.
Basecamp’s insight wasn’t that teams need to work harder or use better tools. It was that teams need to be more deliberate about the act of finishing. Completion is a milestone. Closure is a practice. The teams that treat it as one see the difference in their velocity within a month.
