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.
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.
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.
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.
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.
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.
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"...
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.
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").
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.
> 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
That doesn't work as well if you need to meet with people in other time zones.
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.
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.
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.
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 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.
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'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.
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