b3126044e8
- Simplify flatten_vault API to return usize instead of MigrationResult struct - Add KEEP_FOLDERS: attachments/ and _themes/ alongside type/, config/, theme/ - Use HashSet for collision tracking in unique_filename - Update wikilinks from path-based [[folder/slug]] to title-based [[slug]] - Clean up empty directories after flattening - Flatten demo-vault-v2: move all notes from type-based subfolders to root - Update smoke tests for flat vault structure - Remove migrate_to_flat_vault from repair_vault (one-time migration only) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
44 lines
3.8 KiB
Markdown
44 lines
3.8 KiB
Markdown
---
|
|
aliases: ["Maker's Schedule Manager's Schedule"]
|
|
Is A: Note
|
|
Author: "Paul Graham"
|
|
Topics: ["[[topic-productivity-systems]]"]
|
|
URL: "https://example.com/makers-schedule"
|
|
---
|
|
# Maker's Schedule Manager's Schedule
|
|
*Paul Graham*
|
|
|
|
Graham's essay (it is more essay than book, but its influence warrants a full note) articulates a distinction that every founder-creator instinctively feels but struggles to name. Makers -- programmers, writers, designers -- need long, uninterrupted blocks of time to do their best work. A single meeting in the middle of an afternoon can destroy an entire half-day of productive output, because the maker's mind needs time to load context, reach flow state, and produce meaningful work. Managers, by contrast, operate on an hourly schedule where meetings are the work and switching between topics is normal and expected.
|
|
|
|
The conflict arises when you are both maker and manager, which is the default state for any indie founder. You need deep blocks for writing newsletter content and coding product features, but you also need to handle sponsor communications, answer reader emails, coordinate with freelancers, and make strategic decisions. Graham's insight is that the solution is not better time management -- it is schedule segregation. You need to designate certain days or blocks as maker time and others as manager time, and defend the boundary fiercely. A single "quick call" dropped into a maker block is not a 30-minute cost; it is a half-day cost.
|
|
|
|
What makes this essay particularly relevant for the solo operator is that no one else will protect your maker time. In a company, a good manager might shield their engineers from meeting creep. When you work alone, you must build that protection yourself through calendar discipline, communication norms (e.g., "I respond to email between 2pm and 3pm"), and the willingness to disappoint people who want your time on their schedule.
|
|
|
|
## Key takeaways
|
|
|
|
- Makers need long, uninterrupted blocks (4+ hours) to do their best work; managers operate effectively in 1-hour chunks
|
|
- A single meeting in the middle of a maker block destroys the entire block, not just the meeting duration
|
|
- The cost of context switching is highest for creative and technical work -- writing, coding, designing
|
|
- Schedule segregation (maker days vs. manager days, or maker mornings vs. manager afternoons) is the most effective solution
|
|
- As a solo founder, you are responsible for protecting your own maker time -- no one else will do it for you
|
|
- Communication norms (batch email, async-first, office hours) are the infrastructure that makes maker time possible
|
|
- The "speculative meeting" (meetings that might be useful but have no clear agenda) is the maker's worst enemy
|
|
|
|
## How I apply this
|
|
|
|
- My week is split: Monday through Wednesday mornings are maker time (writing, coding, deep thinking), and Wednesday afternoon through Friday is manager time (calls, emails, admin, planning). This structure has been in place for over a year and is the single most important scheduling decision I have made.
|
|
- I tell sponsors and collaborators that I am available for calls only on Wednesday afternoon, Thursday, or Friday. Initially this felt restrictive, but no one has ever pushed back meaningfully -- and it protects 60% of my week for deep work.
|
|
- I batch all email and Slack responses into two daily windows (noon and 4pm). This was uncomfortable at first because I worried about appearing unresponsive, but response time expectations are usually self-imposed rather than real.
|
|
|
|
## Related
|
|
|
|
- [[on-founder-energy-management]]
|
|
- [[on-consistency-in-creative-work]]
|
|
- [[small-teams-scale-through-systems]]
|
|
- [[the-compound-effect-in-knowledge-work]]
|
|
- [[note-deep-work]]
|
|
- [[note-essentialism]]
|
|
- [[note-the-effective-executive]]
|
|
- [[topic-productivity-systems]]
|
|
- [[person-luca-rossi]]
|