Maker's Schedule, Manager's Schedule (2009)

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 [2]: https://en.wikipedia.org/wiki/Fragmentation_(computing)#Exte... [3]: http://gameprogrammingpatterns.com/object-pool.html

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.

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.

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.

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.

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.

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.

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

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.

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

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.

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):

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...) 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.

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.