The Setup
In 2012, Basecamp (then still called 37signals) had a problem that most growing companies quietly share. Their calendar had become a communal dumping ground. Meetings bred more meetings. Founders Jason Fried and David Heinemeier Hansson found themselves doing something that should have felt absurd: scheduling time to actually work.
They wrote about this period honestly in Rework and later in It Doesn’t Have to Be Crazy at Work. The core observation was simple but uncomfortable. A calendar full of meetings isn’t a sign of a productive team. It’s often a sign of a team that has confused activity with output. And the calendar itself was the evidence, sitting right there in everyone’s Google Calendar, radiating the problem in color-coded blocks.
What made Basecamp’s response worth studying isn’t that they invented some exotic system. It’s that they started treating their calendar the way their engineers treated their codebase: as something with real structure, real consequences for bad decisions, and something that deserved deliberate design rather than passive accumulation.
What Happened
Basecamp made several specific changes that held up over years, not just weeks.
First, they established that Mondays and Fridays were largely meeting-free. The logic was straightforward: Monday is for orienting yourself and getting into work, Friday is for wrapping up and reflecting. Dropping a two-hour sync into either of those days is like deploying to production right before the weekend. The timing is just wrong.
Second, they declared Thursdays their dedicated “big work” day, a protected block for deep, uninterrupted effort. Fried has been explicit in interviews that this wasn’t a suggestion. It was a structural commitment, the same way you might mark a function as private to protect it from outside interference.
Third, and most importantly, they pushed back hard against the assumption that availability equals responsiveness. They stopped treating an empty calendar slot as an invitation. If your afternoon is clear, that doesn’t mean it’s free. It means you’ve allocated it for something, even if that something is focused thinking. Software companies set invisible defaults that make millions of decisions before you do, and the default assumption that empty time is up for grabs is one of the most costly ones in any knowledge worker’s life.
Heinemeier Hansson wrote about the concept of “maker’s schedule versus manager’s schedule” building on Paul Graham’s 2009 essay on the same topic. A manager can absorb a thirty-minute meeting anywhere in the day with relatively low cost. A developer, designer, or writer working on something hard cannot. Interrupting a flow state isn’t like pausing a video. It’s more like restarting a build. You lose context, and rebuilding it takes time you can’t get back.
Basecamp’s specific fix was to encode these rules into their actual scheduling practices and internal culture rather than leaving them as aspirational guidelines. They documented what kinds of work deserved which kinds of time, and they gave people explicit permission to decline meetings that violated those rules. The calendar became an artifact of their values rather than a battlefield everyone was too polite to fight over.
Why It Matters
This is not a story about a company that got lucky with its culture. It’s a story about treating time allocation as a first-class engineering problem.
Think about how seriously most teams treat their code. You don’t let random people commit to main without review. You don’t mix infrastructure changes with feature work in the same deploy. You separate concerns. You protect critical paths. You document why things are the way they are so future you doesn’t undo the decision without realizing it.
Now look at how most teams treat their calendars. Anyone with scheduling access can add a meeting. There’s no review process. There’s no separation between deep work and coordination work. There’s no documentation of why certain blocks exist. And every few months, the whole thing gets silently corrupted until someone finally complains.
The asymmetry is striking. Teams that would never tolerate sloppy version control practices will tolerate a calendar that looks like a merge conflict nobody resolved.
The attention residue research from Gloria Mark at UC Irvine reinforces why this matters at a neurological level. Switching between tasks doesn’t just cost you the transition time. It leaves cognitive residue that degrades your performance on the next task, sometimes for twenty-plus minutes. A calendar that scatters meetings throughout the day isn’t just inconvenient. It’s actively making your thinking worse.
What You Can Learn
You don’t need to run a company like Basecamp to apply this. But you do need to get concrete, because vague intentions about “protecting your time” decay immediately under social pressure.
Audit your calendar like you’d audit a codebase. Look at the last two weeks. For every recurring meeting, ask: what would actually break if this didn’t exist? You’ll find some meetings are load-bearing. Many aren’t. The ones that aren’t are technical debt. Remove them or refactor them into async updates.
Define your protected blocks explicitly. Not “I’d like to have more focus time” but “Tuesday and Wednesday mornings, 9am to 12pm, are not available for meetings.” Put it in your calendar as a recurring block with a title that makes the intent clear. Treat it as a first-class commitment, not a placeholder you’ll move the second someone asks.
Separate coordination time from creation time. Cluster your meetings. If you’re going to have them, put them in the afternoon or on specific days. The goal isn’t to eliminate coordination. It’s to stop letting it leak into every corner of your week. Meeting-free blocks are not a perk. They are how serious teams actually ship.
Document your calendar decisions. This sounds unusual, but it works. If you set a rule about your time, write down why. When someone asks you to break it, you’re not defending a preference. You’re explaining a deliberate design decision. That framing changes the conversation.
Review and refactor regularly. Basecamp didn’t set their schedule rules once and walk away. They revisited them as the company grew. Your calendar should get the same treatment. What worked at twenty people won’t work at two hundred. What works for an individual contributor won’t work for a team lead. Treat drift as a bug worth fixing.
The Basecamp story matters not because their specific rules are universal. They’re not. It matters because the underlying discipline is. When you treat your calendar as something carefully designed rather than passively accumulated, you start making different decisions. You push back on bad requests more confidently. You protect the conditions that make your best work possible. And you stop mistaking a full calendar for a productive one.
Your calendar is already a system. The only question is whether you designed it or whether it designed itself.
