Maker schedule

A marketing team with content creators and campaign managers struggled with inconsistent output. Content writers had difficulty finding time to write amid meetings and Slack interruptions. They implemented "content creation days" where writers worked from 9-12 with no meetings, no Slack, no interruptions. Campaign managers handled ad hoc questions and coordination. Writer output increased from 3 articles weekly to 5, with noticeably higher quality. The calendar change cost nothing but enabled substantially better performance.

Maker schedule recognition directly impacts productivity and quality of work. A writer or designer trying to work on a maker schedule in a meeting-heavy environment will produce less because they're constantly context-switching. A coder interrupted for meetings every two hours will make mistakes because they never fully enter flow state. Organizations that don't respect maker schedule needs get lower quality work and slower delivery despite everyone working hard.

This distinction also explains cross-functional friction. When engineering and product managers have different default schedules, frustration emerges. Managers see makers as unresponsive because they're in deep work. Makers see managers as inefficient because they're in meetings. Both can be true simultaneously if the schedule mismatch isn't recognised and addressed.

For B2B companies where product quality matters, respecting maker schedule isn't a perk, it's a competitive advantage. Companies that enable their makers to work in deep blocks ship better products faster. This translates directly to customer satisfaction, feature velocity, and ability to outcompete.

Identify roles in your organisation that require maker schedule (engineers, designers, product strategists, content creators). Don't assume all knowledge workers can work equally well on fragmented schedules. Some roles genuinely need long blocks.

Create protected time blocks for makers. This might mean no meetings before noon, or designating specific days as meeting-free. Communicate these boundaries clearly to the organisation. When everyone understands that certain people have protected time for deep work, they'll respect it better than if it seems arbitrary.

For managers working with makers, batch your interactions. Rather than interrupting throughout the day, gather your questions and requests for a specific time. A 15-minute sync where you cover 10 things is far less disruptive than 10 separate interruptions. This respects maker schedule while still getting your manager needs met.

Protect long, uninterrupted blocks for deep work, and cluster meetings so they don't shatter the day.

The maker schedule is a simple idea with a big payoff: some work needs hours, not minutes. Paul Graham split knowledge workers into two camps. Managers run on a calendar carved into one-hour slots, hopping between short tasks and meetings all day. Makers (engineers, designers, writers, product people) need long, uninterrupted stretches to get into deep focus and actually build something.

The key insight is the cost of an interruption. When a manager gets pulled into a meeting, they lose the meeting time, nothing more. When a maker gets pulled in, they lose the meeting plus the 15-30 minutes either side spent climbing back into flow. One badly placed meeting can write off a whole afternoon. So a calendar that suits a manager actively sabotages a maker, and most companies are built around the manager's day by default.

This also explains a lot of cross-team friction. Managers think makers are unresponsive; makers think managers do nothing but sit in meetings. Both can be true at once. The fix isn't working harder, it's recognising the mismatch and structuring around it: protected deep-work blocks for makers, batched questions instead of constant taps on the shoulder.

How to apply it

Work out which roles genuinely need maker time (engineers, designers, writers, product strategists) and give them protected blocks, then guard those blocks like real appointments.

• Say you're running engineering in Linear. Instead of a stand-up that fragments everyone's morning, you batch updates into the issue threads and reserve mornings as a no-meeting zone. The team reads status async when they surface for coffee, not when someone pings them mid-flow.
• Say your makers drown in interruptions on Slack. Turn on Do Not Disturb for the deep-work block and agree that anything non-urgent waits for an afternoon thread. A 15-minute sync covering ten questions beats ten separate taps that each cost half an hour to recover from.
• Say your inbox is the leak. A tool like SaneBox filters the noise out of sight during your morning block, so the only things that reach you are the few that genuinely can't wait, and the rest get dealt with in one batch later.

For companies where product quality is the edge, respecting the maker schedule isn't a perk. The same people, the same hours, arranged differently, ship better work faster.

A SaaS company's engineering team was constantly interrupted by product, design, and operations questions. Delivery was slower than expected and bugs were increasing. Leadership implemented no-meeting mornings and designated afternoons as flexible meeting time. Engineers used mornings for deep coding work, afternoons for collaboration and interruptions. Feature velocity increased 35% and bug rates declined 20% in the first quarter. The same people worked the same hours but respecting maker schedule made their work dramatically more productive.

A product team included both engineering (makers) and product management (managers). Constant friction existed because engineers seemed unresponsive and product managers seemed to do nothing but meetings. Once the team recognised the schedule difference, they implemented a solution: makers had meeting-free mornings, managers worked meeting-heavy mornings then deep work afternoons. A daily 30-minute all-hands standup batched most questions. This simple structure eliminated the perception of unresponsiveness without changing anyone's hours.