
Maker's Schedule, Manager's Schedule (2009) - MarlonPro
http://www.paulgraham.com/makersschedule.html
======
munificent
This is directly analogous to memory allocation[1].

Your day is the heap of all available memory.

"Manager time" is a small allocation. Since the manager's heap only uses
blocks this size, she can do this all day without any problems or
fragmentation.

"Maker time" is a large contiguous block. If the heap is empty, you can
allocate them without any problem. But stick one manager-sized block in the
middle and now you've split your heap such that the total time available is
large enough, but it's not contiguous. Classic heap fragmentation[2].

pg's solution is the classic one in memory management: memory pools[3].
Partition your heap into regions for different-sized allocations. Small
allocations always go in one region, large ones in another. "Office hours" is
your small block allocator.

I often hear people say, "Look, I program in <high level language> with <giant
standard library> all day. Why should I care about this old low level CS
stuff? It's already been done for me!"

This is a great example to me of how those old concepts are still useful once
you realize they are only a single analogy away from being about your new high
level problem.

[1]:
[https://en.wikipedia.org/wiki/Memory_management](https://en.wikipedia.org/wiki/Memory_management)
[2]:
[https://en.wikipedia.org/wiki/Fragmentation_(computing)#Exte...](https://en.wikipedia.org/wiki/Fragmentation_\(computing\)#External_fragmentation)
[3]: [http://gameprogrammingpatterns.com/object-
pool.html](http://gameprogrammingpatterns.com/object-pool.html)

~~~
ryangittins
Hah, wow. What a great reply. Props to you, man. That's just a terrific
analogy.

------
mwsherman
As a relatively recent manager (former dev), I’ve embraced the idea that it’s
my job to be interrupted. It’s not a bug, it’s a feature. It signals that the
interrupter’s time is more important than mine, which is what I want for
people on my team.

Any new manager should embrace this, and moreso, develop the skill to be
interrupted gracefully.

~~~
chipz
I think that is certainly the way, any manager or lead developer should always
open to interruption, that way we can manage our team.

Being a lead dev or manager, i think we should always expect less coding.

------
beat
I've been sharing this article around for years, especially in the enterprise
gigs that I dayjob at. It really clarifies a lot for people, even people with
zero interest in startups.

If they're really interested, I usually advise them to take a few hours some
afternoon and read through all of pg's essays.

~~~
cpach
Cool! Did you get positive feedback from the people who read them? I mean, PG
is quite critical regarding large enterprises, which might cause some people
to discard him.

~~~
beat
Oh, sure. Everyone gets it, managers included (and sometimes, it helps them be
a bit more sensitive). And anyone who works in the bowels of Big Enterprise is
more critical than pg on the subject. We have the scars.

That said, I think the Silicon Valley startup community is profoundly ignorant
about the enterprise, and its strengths as well as its weaknesses. There's
this perception that the enterprise sucks because people there are lazy and
stupid. Not true! Much of the problem is just because the enterprise will
tackle problems so large and overwhelming that they're just really, really
hard to win, hard to make sense. The problem with enterprise projects isn't
the result of laziness or stupidity. The problem is that this is the best that
really smart, hardworking people can do at that scale.

~~~
famousactress
I agree with a handful of your points, but I think the biggest thing broken
with enterprises is that accountability is hyper-distributed, both internally
(through massive org/bureaucracy) and externally (by selling things to your
users', bosses', bosses) and not having a clean enough feedback loop.

It makes them effectively irrational machines, who can survive (or die) fairly
independently of their ability to create value.

I think these misaligned incentives are the reason Enterprise projects suck,
not because people are lazy and stupid (is anyone really honestly arguing
that?), but also not because we've literally reached some hard-limit on the
theoretical ability for 6,000 people to do great work.

I also disagree that the problems enterprises purport to be tackling are all
that large or overwhelming... not that they're not large or even overwhelming,
but the idea that some group working on Oracle's Business Intelligence
Solutions is saddled with a much harder problem than I dunno... Google, or
Oculus, or NewRelic is _super_ hard for me to swallow.

~~~
beat
Good points. I've worked a lot in banking and healthcare, so where I see
complexity isn't the software so much as the regulatory environment. This
leads to a much more process-intensive way to work.

I was in a brief conversation this morning about Conway's Law in the
enterprise, and something I realized (I'm surprised I'd never realized it
before) is that that ever-changing fault lines of corporate org structures
break existing, successful software projects. Conway's Law says you create
software that is a reflection of your organizational structure. What if the
org structure changes, but you have a valuable legacy software product to
support? Now the software and the organization are at odds with one another.
That feels like a Big Truth to me, one of the key reasons things get screwed
up in the enterprise.

~~~
Terr_
Another factor is that sometimes the software becomes the "battleground"
between different facets of the company, especially when there's some
social/organizational problem nobody is capable or willing to deal with. By
spending money (dev effort) and eroding the software, the company gets
palliative care.

Hypothetical example... suppose Sales makes little white lies when quotas are
looming or commissions are at risk. This causes problems for Finance when they
have to reconcile some things down the line. Rather than fixing incentives, a
feature-request comes in for a meaningless "I Pinky-Swear I'm Telling The
Truth" checkbox that all sales-people must tick in the workflow.

Next release, the sales-people complain about the unnecessary extra time it
takes, and there's a counter-effort to make it ticked by default for users in
certain "trusted" roles.

Either way, it hasn't helped much, because the sales-supervisors have no
incentive or willpower to chasten the salesfolk for broken pinky-swears. So a
new feature-request comes in, for "Sale Validation Logic" or "Sale Approval
System"...

------
JoshTriplett
I'm in a position where I spend half my time working on "manager's schedule".
After a relatively short time of doing so, I adopted the trick of scheduling
an all-day meeting for Wednesday, Thursday, and Friday. Then, when people want
to schedule a meeting (regular or recurring), and it isn't incredibly urgent,
they'll generally default to Monday or Tuesday, days where I primarily handle
meetings, email, and short activities. This works well with automated tools
that find the next available timeslot that everyone has marked as "free".
Occasionally, someone will ask if I can accommodate something urgent on Wed-
Fri, to which the answer is usually "yes", but despite that, I tend to have
7-8 hours of uninterrupted time on those days.

~~~
gklitt
I use the same trick by blocking out my whole afternoon every day, and find
that it works really well. It turns out that most meetings have no particular
time that they need to be scheduled for, so this gives me maker schedule time
and makes me far more productive.

One caveat is that if many people in an org start doing this it might become
difficult to schedule things, in which case it might be useful for the whole
company to coordinate (eg "no meeting Mondays").

~~~
dmichulke
I do the same but the other way round (maker = morning, manager = afternoon).

I find that sometimes at night I wake up and think about problems and it's
best to put them into practice in the morning, before absorbing all the noise
during the day.

When I'm really lucky, I just schedule 2h manager time after lunch (because
there my stomach is full and my productivity low) and then return to maker
schedule.

------
daniel_iversen
A hot tip that may help others, here at Dropbox a lot of the engineers (and
other folks) schedule "maker time" in their calendar and when people see that
they respect those times as sacred and won't bother the person.

~~~
chipz
Do they each really keep a calendar filled with schedule in their desk? :)

------
engi_nerd
I sent this post to my boss at a previous job. Why? Because I became tired of
his constant interruptions. One week I decided to keep track of his
interruptions. The average number of interruptions -- just from him -- was 10,
with a maximum of 17. His response was "You need to learn to get more work
done between my interruptions, so I won't need to interrupt you so much to
check on you."

Just one of many reasons why I don't work there anymore.

------
mark_eijsermans
We've been blocking off Wed/Thurs as no meetings day for engineers largely
inspired by this article. It's amazing how much you'll get done with 2 days a
week uninterrupted. Down side is that it's tough to schedule a meeting (and
room), so some meetings get pushed back by days or weeks.

~~~
carlivar
That's not a bad thing. It means meeting time is precious and valuable, so the
bar for meetings is higher. People are also less likely to put up with non-
productive meetings.

------
JacobAldridge
Definitely one of pg's simplest and most enduring essays - it resonated with
me in 2009, and I continue to reference it (most recently while delivering a
presentation to business owners yesterday morning).

There's a direct analogy (I believe) with the concept of Fast paced / Slow
paced behavioural preference some of my business and health colleagues have
developed [1]. I find that process (and there's an online indicator that can
score you) fascinating because it looks at Maker/Manager (Slow/Fast) time for
Leisure, Nutrition, and Exercise as well as Business. I'm quite consistently
the Slow/ Maker's Schedule in all areas of my life, but work with some people
who are opposite between Work and Home as a form of life balance.

[1]
[http://www.shirlawscompass.com/pacefaq](http://www.shirlawscompass.com/pacefaq)

------
jttam
The day unit is not the only unit in play. I split my week up this way, where
I try to keep one day in the business schedule and four days in the maker's
schedule. Unfortunately, as my career has progressed I've started putting two
days into the manager's schedule and three days into the maker's schedule, but
I find this a highly effective partitioning scheme. You have all your coffee
meetings and whatnot on a day of the week of your own designation.

------
Avshalom
Sidenote: Customer's Schedule both trumps and ruins both.

~~~
hwstar
Sidenote to sidenote: If the customer is too unreasonable, then the developer
finds a new job elsewhere. A manager's job is to balance these polar opposites
in a way which makes the company prosper.

------
sharemywin
Never thought of it that way, but your right on. And even small things can
turn into an afternoon chasing something down or rewriting things. I always
wondered about "programmers block" similar to "writers block", too. The
article reminded me of it because it groups writes and such into a group
makers.

------
ianbicking
As a maker-turn-manager I've become skeptical of this perspective. I think
it's indulgent and misdirected. Yes, if _I_ as a manager schedule _your_ time,
I'm probably not going to schedule it for your best performance. But I don't
think the problem that as a manager I don't leave you giant blocks of
uninterrupted time. It's that as a manager I tend to interrupt your time with
meetings that serve _my_ role, and a manager's role tends to be focused on
prediction, expectations, upward-directed planning, balancing work, status,
risk... all things that aren't even intended to improve actual execution. In
theory of course a manager is supposed to be focused on team performance and
execution, but the heaviest pressure on a manager is about how the team fits
into the larger organization, not how the team works.

If a maker's days are interrupted by meetings that are genuinely structured to
improve their execution, I don't think the interruption is very concerning,
and may be beneficial. This theory about a Maker's Schedule, and these
theories around attention, make these positive interruptions less likely to
happen – the maker's become skittish about all meetings, become reclusive,
sometimes causing a downward spiral because the maker _actually needs_ those
meetings and becomes more reclusive out of shame because the maker is confused
and performing poorly. Defensively the maker reacts against the structure that
remains – the structure of meetings created by the manager, meetings which
aren't supportive, where the maker is not sufficiently engaged to feel
confident in repurposing the meeting... but the dysfunction is that in the
face of these meetings a better response would be more meetings, better
meetings, meetings where the makers leave the meeting ahead of where they
started instead of behind. But don't expect the managers to call those
meetings – frankly as a manager I often can't make those meetings happen even
when I want to.

I'll also copy a post I wrote on the topic
([https://plus.google.com/u/0/+IanBicking/posts/jgJCdMkzyBE](https://plus.google.com/u/0/+IanBicking/posts/jgJCdMkzyBE)):

I'm somewhat pro-meeting, which maybe puts me at odds with the cultural norms
of developers.

I think I realize some of the problem. Meetings tend to be called by managers.
Managers have management goals. Process, deadlines, coordination, etc. The
developer sits around in case they provide some important input on one of
those topics, or to give status, or to commit to a deadline. Nothing in that
kind of meeting helps the developer's work. And the developer tries their best
to withhold, to protect their own work, but also to protect the project which
actually needs that output.

In a developer-oriented meeting the topics would be decisions to make,
architectural choices to consider, noting places of tension where a creative
solution could be helpful. In a developer meeting it is reasonable to take
some time to look at code. To do a bit of research – right in the meeting – to
answer a question. To brainstorm ideas. If a problem is hard, it is reasonable
that everyone go silent for a minute and ponder the problem.

In The New Science of Building Great Teams ([https://hbr.org/2012/04/the-new-
science-of-building-great-te...](https://hbr.org/2012/04/the-new-science-of-
building-great-teams)) they discuss some evidence-based observations about
communication patterns. In it they suggest that high levels of communication
lead to more productivity. By developer sensibilities, _very_ high levels. But
mostly peer interactions – developers interacting with developers.

I'd really extend this to all the people engaged in making the product,
design, user experience, user research, development, probably support and
other roles. In an ideal model there would be dozens of meetings, as different
sets of these people came together to talk about what is relevant to those
groups of people. These meetings would not have clear and firm agendas, the
product is the agenda, finding the agenda is some of the work of the meeting.

It's easy to blame management for the unproductive meetings. We're calling
these snooze-fest status meetings. But I'd turn it around: professionals
shouldn't depend on management to initiate meetings. Sure management can try;
I try to setup meetings I think will be productive for other people. The
Standup is the quintessential example. But we know where those so often end
up: as yet another management-led status meeting. And it's a form without a
clear purpose. Who should be in the standup? What should we talk about? When
those things are defined by management we get management-style answers. Even
better than trying to fix the standup, keep it from being necessary: make the
meetings that help everyone do their work, where the topic is always execution
and not prediction or planning or status.

With Project Managers and other professions focused on planning there is a
danger that we defer to the specialists. But everything needs to be planned.
The next line of code I write has to be planned. Developers have to be
planners, every one of them.﻿

------
mpdehaan2
Another factor here is lots of pointless meetings, especially ones that rehash
status or repeat status when there are no updates, are especially
demotivating.

Design meetings, one can live for, if one is interested in how to solve a
problem. Killing the design meetings is probably something to be avoided.

The zone exists, to an extent. I sometimes think there are parallels to
something like videogame-esque canon that takes a long time to charge up. The
best work I'm going to do is going to come at some random hour during the day,
and if I'm interrupted, the charge counter is likely to reset. But maybe not.

I'm sort of interrupt driven at times, and I think our culture being very
triggered by email, phones, other things, can cause people to wait for
interruptions to do things too.

So there's a balance. But yes, pointless meetings are bad things. But it's
ugly when there are meetings you have to have, and there's a backlash against
the manager calling the meeting, because then "the manager is something
different", and I think there's a bit of negative legacy to this article in
that vein.

Really, I think the question is to ask, at the end of whatever meetings, how
much value did you get out of it, and what actionable conclusions came out of
that meeting. If the meeting doesn't produce action items (that hopefully get
done before the next meeting of the same kind), it's not a good meeting.

And meetings are really about getting people together that need to talk about
something. If it's not that, then don't do it :)

Make sure everybody's time in there is valuable. If you have a meeting where
somebody only talks for thirty seconds out of an hour, it's probably not worth
that person's time. However, it's also destructive to think a meeting isn't
worth someone's time, and use that to "protect" their time.

Everybody should get to be involved in some decision making that wants to be.

Do I find that in technical-manager-mode I can't code very well because I'm
too distracted by 1000 different things? Yes, pretty much. And one of the
first things I do is try to cut the B.S. management meetings and make sure the
ones I'm involved in is important. If you can't cut that, it's frustrating.

But the complexity of having more people means conversations to organize
things do have to happen, and to crush them in the spirit of "meetings are
bad" can be dangerous too.

I think that's wrong. Again, the important part is to have the right meetings.
If you can block them out to happen during major blocks of time just a few
days a week - most of the time - I think that's great.

