Maker vs manager schedules
Every now and then the topic of schedules comes up, what sorts of schedules are best for being "productive"? This is a question that people ask from time to time, but the willingness to actually try something different comes up far more infrequently. Schedule inertia is a strong factor and not just because of habit. When you book in calendar events some time out you introduce constraints to your future calendar choices if you wish to meet those existing calendar obligations. Recent world events have led to many people revisit their schedule choices and how they are working.
Is the discussion really about schedules or is it about trust?
Many people talk about the idea of which schedules are "best", but what they mean by "best" can vary substantially. Before any good discussion about scheduling choices can be made you first want to be clear about what the schedules are actually trying to achieve or optimize for.
One example I've seen with this recently is a strong inflexibility and rigid adherence to the 9-5 rules in many organizations that have been ostensibly talking about flexible work schedules. The weird thing has been seeing just how much irrational adherence to this 9-5 synchronous working schedule has persisted in a world impacted by COVID-19 considering all the changes and uncertainty this has introduced. Despite the forced changes like closures of physical offices some organizations are still fighting hard to work in the same synchronous ways as they did before 1. The first thing to determine with any discussion about schedules is the intent behind the discussion, is the mental framing centered around mistrust and associated surveillance or productivity and success?
I think part of the difficulty in discussing alternative approaches to scheduling and productivity stems from many organizations fundamentally mistrusting that their employees will actually get work done on a different sort of schedule. This manifests as "concerns" being expressed about the schedule that really are actually just trust issues about their employees doing their job, you'll notice that the concerns tend to linger with any schedule as these discussions were never really about the schedule in the first place beyond it's ability to help surveil the presumably goldbricking employees.
It's important to first determine if any discussions about the productivity of schedules is in good faith as disturbingly often they are not. If the real issues are trust based then de-prioritize discussions about schedules, since discussions about schedules are mostly a waste of time if there's no trust.
Maker vs manager schedules
Say however that you do trust that people can actually do their work, since you hired competent professionals who you trust and respect, then what's the best schedule for people to actually use? I suspect the best schedule directly depends on the type of work being done, some deep work requires uninterrupted concentration and time, whereas other tasks do not. One of the biggest scheduling concepts that matters in any area dependent on deep work (like the software world) is the maker vs manager schedule distinction.
One of the interesting things about the manager schedule is that most of the tasks do not have this ramp-up time. Getting on a call with people may only take a few minutes to get up and running, you might spend a few minutes reviewing your notes in a CRM system or your notebook and then you are ready to get on that conference call. The "manager" schedule doesn't even have to be able management, any job where the majority of tasks can be timeboxed interchangeably into 1 hour chunks works well on this schedule.
Jobs where the tasks cannot be interchangeably timeboxed find the manager schedule to be a poor fit. Many tasks require a lot of ramp-up time to get to the "high productivity zone", take for example writing a book or creating software, there's a large amount of context that you have to get in your mind first before you can be productive. This isn't just about thought work, some tasks have set up time that doesn't contribute to productivity but nonetheless has to be done before you can start generating something of values, thought work is just an instance where this applies. The reason software is so notable is that the lower productivity ramp up time is often on the order of hours. It will take over an hour to get up to maximum productivity contributing to a software project, in messy or complex systems it can be even longer. What is unique thought work tasks like software development is the ease at which non-practitioners can be ignorant of the start up times, or more cynically feign ignorance. Say you are working in a shop that does machining, many jobs have a set up time needed to complete tasks, and because this is tangible people will tend to respect the fact that there's a lead time on being able to generate things of value. With software however it's super easy to be willfully ignorant of this start up time due to it being far less visible, and this reduced visibility makes it politically harder for people to fight back against when their productivity is transgressed on. In the machine shop example if someone keeps interrupting the setup then its very easy for the people that have had their output interfered with to point at the reason for their lack of productivity. In software however it's much harder for the target of interruptions to fight back since the evidence of how the interference impacts productivity is harder for outsiders to see and understand. Often this is just a lack of shared understanding of what needs to be done, if you don't engage in tasks that have a setup time it's easy to interrupt those that do due to a lack of understanding. However sometimes people use this dynamic as a political weapon. If anyone pulled this as a political game in my company I'd do everything I could to fire them since this type of behavior will completely kill off first the ability to do deep work and will do irreparable damage to the culture of deep work in an organization. Any software company needs to protect its culture of deep work if it wishes to thrive. People need to know their schedules, of all types, will be protected from interruptions to feel comfortable.
Reasons like this are just a small part of why software is an extremely political activity.
Coordination across schedules
I don't especially like the mental framing of the terms used to describe these schedules because they prime people to think more about job roles than the actual tasks being done. If you are a "maker" sometimes you may want to spend a day a week on the manager schedule and vice versa. What you really want is to get a good match between the tasks people are doing and the schedules they are using. From an organizational point of view coordination is difficult in organizations that have people working on fundamentally different schedules. A software developer needs to be on the maker schedule, a salesperson probably has to be on the manager schedule, ironically a manager can be on either the "maker" or "manager" schedule depending on some other factors.
There are multiple imbalances that you have to contend with in coordinating schedules. It starts with understanding of schedules, the manager schedule is much easier to understand than the maker schedule. Specifically people who are on the "manager" schedule need to understand the realities of those on the "maker" schedule, while the manager schedule is already easier for everyone to understand. The manager schedule is far simpler to conceptualize because the connection between the generation of value and this schedule are far simpler than that of the maker schedule. On the manager schedule each hour worked has a fairly linear association with value produced. This is not so for the maker schedule and misunderstanding this is the root cause of many organizational problems.
One of the biggest issues with schedule coordination is that there's a large number of ways in which people can asymmetrically destroy the productivity of other people and thus the entire organization via interruptions. People tend to know that interruptions are bad but I think the first article I remember that explicitly talked about the asymmetrical wastage of time due to interruptions was this article by Joel Spolsky. Specifically the thing that stuck with me after reading that article was that he mentions "Here’s the simple algebra. Let’s say (as the evidence seems to suggest) that if we interrupt a programmer, even for a minute, we’re really blowing away 15 minutes of productivity". Experience shows me that this isn't exaggerated at all, any interruption you make of someone who's engaging in deep work comes with a cost of at least 15 minutes. 2
Giving everyone the mental tools to judge if and when interrupting someone else makes sense is imperative.
In order to judge if an interruption makes sense you need to do a cost vs benefits analysis.
If you for some reason have inflexibility about schedules and you want to frame everything in one hour blocks 3 the best way to deal with this in a way that works with tasks with ramp up time is to have task dependencies, for any task that needs some deep work you have to allocate large blocks of time. Now the important part of this is to generate back pressure for interruptions. The tendency is to chunk off large blocks of time on the calendar, but this doesn't properly highlight the cost of interruptions. If you want to schedule deep work in a system that artificially uses hourly blocks you have to schedule the deep work time in such a way that accounts directly for the ramp up time and the differential in value of the ramp up time vs the time in full productivity. This means that deep work time can only be placed in the calendar if the associated ramp up time is scheduled directly before it.
One difficulty often stems from the fact that in many organizations there is a power imbalance between those on the maker schedule and those on the manager schedule. Politically in many organizations it is often easy for people on the manager schedule to interrupt those on the maker schedule. If your organizations output is dependent on deep work you need to make it a priority to deal with the politics of interruptions. If your organization feasibility is based on the quality of its thought work output you must fight hard against cultural aspects that enable casual or thoughtless interruptions. One important way to do this is to have a good mental accounting of the cost of interruptions since there will inevitably be times where people face a decision about whether or not they should interrupt people. It is imperative that you give people the mental tools required to make the decisions about both if and when to interrupt in a sane and accurate way. One place I worked at got this comically wrong and had a policy that if you were stuck you should always reach out and do so immediately, effectively encouraging everyone to interrupt everyone else frequently4. Being so rigidly black and white about this was a terrible decision but had roots in not trusting the judgment of their employees, partly because they had a knack of hiring every single graduate they could without hiring anyone more experienced to give oversight so they didn't trust their employees to be able to make a good decision about when to interrupt. It should come as no surprise that this was a toxic environment for deep work, and bad cultural things like this tend to cluster. The issue was simply that there was no sense of cost of interruption. The other peculiarity about that organization was the obsession they had with keeping track of hours spent on projects, I think this was an overly naive metric for software projects that was far more concerned with the billable property of the hours than the productivity of those hours.
If you do want to account for hours on the maker schedule or deep work schedule you have to have a significantly different weighting for the ramp up time vs the non ramp up time. A common mistake I see is assigning an equal weighting for the value each minute or hour worked, for some tasks this is accurate but on others, like most deep work tasks, it is wildly misleading.
For example if someone has 1 hour of ramp up time you will perhaps do well to account for this as zero productivity time, then the second hour with a multiple of 1 and the next 2-6 hours as a multiple of 2. Beyond 6-8 hours most people start to get exhausted so you'll want to discount heavily beyond 8 hours worked and record negative value after whatever hours would start inducing exhaustion and longer term burnout issues. Overwork becomes a net negative over the longer term and must be accounted for as such.
The other thing that could potentially make a lot of sense is to keep track of both sides of interruptions. Knowing who got interrupted is important as it will reset the clock on their productivity but keeping track of who did the interrupting is important too. You'll want people to be accountable for interrupting the deep-work cycle as such interruptions carry a real cost. This is a bit like shutting down a production line at a factory, this is an expensive thing to do, but nonetheless you will need to do it sometimes. If people are not accountable for interrupting work then it starts to reduce the costs of interruptions which has a strong tendency to increasing the frequency of interruptions. If you rely on deep work you want the cost of interruptions to be felt by the person doing the interrupting as well.
Trying to have a remote working experience where you are trying to directly replicate office work via 8 hour long video conferences with everyone at home is a terrible approach to remote work (and yes some places are literally doing this). I think anyone subjected to this will want to avoid this in the future since this doesn't really get the good parts of working at the office or remote and manages to get most of the bad parts of both. ↩
This is why I find the notion of noisy open plan offices with very little quite space to be such insanity, no wonder places like this have poor output from their deep-work staff. While the cost of cheaper real estate is extremely tangible the loss of productivity is far harder to quantify. If your main organizational output is in the form of deep work then the costs of poorly designed offices are very high, often far higher than the "savings" from the cheaper real estate. ↩
For example some places do stupid things like build software on fixed billable hours. Deep work that is done on billable hours is something that probably should only be done as a contractual last resort when other approaches to enabling collaboration have failed. ↩