Paul Graham’s 2009 essay on maker and manager schedules remains one of the most useful frameworks for understanding why engineering teams and leadership teams so frequently frustrate each other. Managers operate in hourly blocks — a meeting at 10, a one-on-one at 11, a planning session at 2 — and their calendars are designed for this rhythm. Makers — engineers, designers, writers — operate on half-day units. A morning of deep work is a single indivisible block. A meeting dropped in the middle of it doesn’t consume an hour; it consumes the morning.
Most project planning tools and processes are designed by and for managers. The result is project plans full of meetings, check-ins, and touchpoints that make sense from a coordination standpoint but quietly destroy the focused time engineers need to actually do the work.
Why the Conflict Persists
The conflict between maker and manager schedules isn’t about bad intentions. Managers schedule check-ins because they’re responsible for coordination, risk management, and stakeholder communication. Engineers avoid those check-ins because they need sustained focus to produce quality work. Both are responding rationally to their roles.
The problem is that most project plans don’t explicitly account for either schedule type. They treat all time as interchangeable: a 30-minute block is a 30-minute block, whether it’s an engineer’s deep work window or a product manager’s transition between calls. This produces plans that look plausible on paper and fail in execution.
Building Hybrid-Aware Project Plans
The first step is making both schedule types explicit in your planning. When estimating a feature, distinguish between maker time (focused engineering hours) and manager time (coordination, review, communication). These aren’t interchangeable and shouldn’t be planned as if they are.
- Block maker time as sacred first: When planning a sprint, identify the deep-work blocks the engineers need and protect them before scheduling any synchronous coordination. Maker time is the constraining resource.
- Batch management tasks to the edges of the day: Standups, reviews, and planning sessions belong at the beginning or end of the workday — not in the middle of it. A 9 AM standup and a 5 PM review protect the core of the day for focused work.
- Use async for everything that doesn’t require real-time presence: Status updates, design feedback, question threads — these don’t require live meetings. Moving them to Pulse task comments frees up maker time without reducing coordination quality.
Project Estimation Through Both Lenses
When estimating project timelines, the maker/manager distinction has direct implications for accuracy. A feature that requires 40 hours of engineering time doesn’t take one week if those 40 hours are fragmented across two weeks of interruption-heavy calendar. It takes however long it takes to accumulate 40 hours of genuine focused work — which might be three weeks on a meeting-heavy team.
Build this into your estimates explicitly. Ask: given our current meeting load, how many maker hours per engineer per week are realistically available? If the answer is 20 hours out of 40, your 40-hour estimate becomes a two-week timeline, not one. Surfacing this math makes the tradeoff visible and creates a productive conversation about whether meeting overhead is worth the cost.
The Role of Pulse in Bridging Both Worlds
Project management tools that only serve the manager schedule often end up resented by makers because they consume time without providing value to the people doing the work. In Pulse, makers use task threads to capture decisions, blockers, and progress without switching contexts. Managers get the aggregated view they need without scheduling check-in meetings to extract the same information. When both schedule types are planned for explicitly, teams ship faster, engineers are less frustrated, and managers have better information — not despite the constraints, but because of the discipline the constraints create.