Bram Cohen, the inventor of BitTorrent and one of the more iconoclastic minds in software engineering, has a piece of advice that will make every project manager twitch: don’t do it now. Do it mañana.
In a recent essay on his Substack blog, Cohen lays out what he calls the “Mañana Principle” — a deliberate, counterintuitive strategy for managing software development tasks that amounts to systematic procrastination. Not the lazy kind. The strategic kind. The kind where you look at a task, decide it doesn’t need to happen today, and push it to tomorrow’s queue with full intentionality.
The core idea is deceptively simple. When something comes up that needs doing — a bug fix, a feature request, a refactor — you don’t drop everything and do it immediately. You don’t even add it to today’s task list. You add it to tomorrow’s. Today, you work only on what was already queued up yesterday. Tomorrow handles tomorrow’s problems.
This sounds like procrastination dressed up in a productivity framework. Cohen argues it’s the opposite.
The principle, as Cohen describes it, solves one of the most persistent pathologies in software development: the constant interruption cycle. A developer sits down with a plan for the day, starts executing, and then something urgent arrives. A Slack message. A production alert. A stakeholder request. The original plan dissolves. By the end of the day, the developer has responded to twelve things and finished none of them. Sound familiar? It should. This is the default operating mode of most engineering teams in 2025.
Cohen’s framework draws a hard boundary. Today’s work was decided yesterday. Full stop. Anything new goes into tomorrow’s bucket. The effect, he argues, is that you actually complete things. You get the psychological satisfaction of finishing tasks. You stop context-switching. And critically, you create a natural buffer that lets you evaluate whether incoming tasks actually matter — because by tomorrow, a surprising number of them won’t.
That last point deserves emphasis. One of the underappreciated costs of immediate-response culture in engineering organizations is that teams spend enormous effort on tasks that turn out to be irrelevant. The bug that resolves itself. The feature request that gets withdrawn. The “critical” issue that nobody mentions again 24 hours later. By imposing a one-day delay, the Mañana Principle acts as a natural filter. Only the things that still matter tomorrow get done.
This isn’t a new observation in the abstract. Cal Newport has written extensively about the cost of context-switching and the value of deep work. The Basecamp team — now 37signals — has long advocated for calm, interruption-free development cycles with their Shape Up methodology. But Cohen’s formulation is more granular and more mechanical than most productivity advice. It’s not a philosophy. It’s a rule: if it came in today, it goes on tomorrow’s list. No exceptions. No “just this one quick thing.”
The discipline required is non-trivial. Cohen acknowledges this. The gravitational pull of immediacy in modern software culture is enormous. Agile methodologies, for all their virtues, have trained teams to be responsive — sometimes pathologically so. Stand-ups, sprint adjustments, and real-time collaboration tools all create an implicit expectation that developers should be available and reactive throughout the day. The Mañana Principle pushes back against this with blunt force.
There’s an interesting tension here with how most Silicon Valley engineering organizations actually operate. The prevailing model at companies from Google to mid-stage startups emphasizes rapid iteration and fast feedback loops. Ship quickly. Measure. Adjust. The idea of deliberately delaying action by even a single day feels heretical in that context. But Cohen would likely argue — and his essay implies — that speed of shipping and speed of responding to interruptions are different things. You can ship fast if you’re focused. You can’t ship fast if you’re constantly derailed.
Cohen’s credibility on matters of engineering discipline is considerable. BitTorrent, which he created in 2001, was one of the most elegantly designed protocols of its era — a system that solved the problem of large-scale file distribution with a minimum of centralized infrastructure. More recently, he founded Chia Network, a blockchain project that uses proof of space and time rather than proof of work. Whatever one thinks of the crypto space, the underlying technical work reflects a mind that thinks carefully about systems design and resource allocation. When Cohen says something about how to structure engineering work, the field tends to listen.
The essay also touches on a subtler psychological point. Developers who are constantly reactive develop a kind of learned helplessness about their own schedules. They stop planning because plans never survive contact with the inbox. Over time, this erodes both productivity and morale. The Mañana Principle restores a sense of agency. You decided what today looks like. Yesterday. And you’re going to execute on that decision.
Not everyone is convinced. Critics of delay-based productivity systems — and there are many — point out that some things genuinely can’t wait. A production outage affecting paying customers. A security vulnerability. A deployment that’s blocking ten other people. Cohen’s essay doesn’t spend much time on these edge cases, which is either a weakness in the argument or a deliberate choice to keep the principle clean and uncompromised. Probably both.
The practical reality is that most teams would need to carve out exceptions for genuine emergencies while applying the Mañana Principle to everything else. This is harder than it sounds. “Emergency” is one of the most abused words in corporate vocabulary. Every stakeholder believes their request is urgent. Every product manager thinks their bug is the one that can’t wait. Without strong cultural norms about what actually constitutes an emergency, the exception swallows the rule.
Still, the underlying insight is sound and supported by decades of research on task-switching costs. A 2001 study by Joshua Rubinstein, David Meyer, and Jeffrey Evans, published by the American Psychological Association, found that switching between tasks can cost as much as 40% of productive time. More recent work by Gloria Mark at the University of California, Irvine has shown that it takes an average of 23 minutes to return to full focus after an interruption. These aren’t small numbers. For a team of ten engineers, eliminating even half of unnecessary context switches could be equivalent to adding two or three full-time developers in terms of actual output.
Cohen’s essay is short — characteristically so. He’s never been one for verbose argumentation. But the implications are broad. If taken seriously, the Mañana Principle challenges not just individual work habits but the entire communication infrastructure of modern engineering teams. It suggests that Slack’s always-on notification model is actively harmful. That the cultural expectation of immediate response times in workplace chat is a productivity tax. That the best thing a developer can do with a new request is acknowledge it and then ignore it until tomorrow.
This aligns with a growing counter-movement in the tech industry against what some have called “hyperresponsiveness culture.” Companies like Async, which builds tools for asynchronous communication, and Twist, Doist’s Slack alternative designed around threaded async conversations, are explicitly building products for teams that don’t want to be always-on. The Mañana Principle fits neatly into this trend, though Cohen frames it as an individual practice rather than an organizational one.
The timing of Cohen’s essay is interesting too. The tech industry is in a period of intense focus on developer productivity, driven partly by the proliferation of AI coding assistants like GitHub Copilot, Cursor, and Anthropic’s Claude. These tools promise to make individual developers faster at writing code. But writing code was never the real bottleneck for most engineering teams. The bottleneck is focus. It’s prioritization. It’s the ability to work on the right thing without being pulled in six directions. AI can write your code faster, but it can’t stop your product manager from pinging you mid-flow with a “quick question.”
Cohen’s principle addresses the actual constraint, not the imagined one.
There’s also a connection to the broader conversation about maker schedules versus manager schedules, a framework popularized by Y Combinator co-founder Paul Graham in his influential 2009 essay. Graham argued that makers — developers, writers, designers — need long uninterrupted blocks of time, while managers operate in one-hour increments. A single meeting in the middle of an afternoon can destroy a maker’s entire day. The Mañana Principle is essentially a mechanism for protecting the maker schedule from the manager schedule’s constant incursions.
Whether Cohen’s specific formulation catches on as a named methodology remains to be seen. Software development is littered with productivity frameworks that burned bright and faded — Getting Things Done, Pomodoro, various Agile derivatives. But the best ideas from those systems tend to persist even after the branded framework loses its novelty. The Mañana Principle’s core insight — that delaying response to incoming tasks by one day dramatically improves both focus and filtering — is the kind of idea that’s obvious in retrospect and hard to argue with on the merits.
The real question is whether teams and organizations have the discipline to implement it. Individual developers can adopt the practice tomorrow. Literally. But organizational adoption requires buy-in from product managers, engineering managers, and executives who are accustomed to getting immediate responses. It requires rewriting the social contract around response times. It requires accepting that “I’ll get to that tomorrow” is not a sign of laziness but a sign of intentional, focused work.
That’s a hard sell in most companies. But Cohen has never been particularly interested in easy sells. He built BitTorrent when the prevailing wisdom said peer-to-peer file sharing couldn’t scale. He built Chia when the prevailing wisdom said blockchain consensus had to be energy-intensive. The Mañana Principle is a smaller bet, but it carries the same contrarian signature: the thing everyone assumes is necessary — immediate responsiveness — might actually be the thing that’s killing your productivity.
Do it tomorrow. Today, finish what you started.