And now for something a little different…
I recently read a fantastic article by Paul Graham entitled , in which Graham outlines that people who “make” things run by a much different work schedule than those who “manage” things. A key excerpt:
There are two types of schedule, which I’ll call the manager’s schedule and the maker’s schedule. The manager’s schedule is for bosses. It’s embodied in the traditional appointment book, with each day cut into one hour intervals. You can block off several hours for a single task if you need to, but by default you change what you’re doing every hour.
When you use time that way, it’s merely a practical problem to meet with someone. Find an open slot in your schedule, book them, and you’re done.
Most powerful people are on the manager’s schedule. It’s the schedule of command. But there’s another way of using time that’s common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can’t write or program well in units of an hour. That’s barely enough time to get started.
When you’re operating on the maker’s schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in. Plus you have to remember to go to the meeting. That’s no problem for someone on the manager’s schedule. There’s always something coming on the next hour; the only question is what. But when someone on the maker’s schedule has a meeting, they have to think about it.
After reading this and reflecting at length on many of the twists and turns my professional life has seen, I came to realize that the schedule is just one of many professional differences between managers and makers – and the most successful places where I’ve worked have found ways to make these differences work.
First, an aside: the terms “manager” and “maker” themselves deserve some reflection. I think the best way to look at it is this: does the person in question create something wholly new during their time or are they moving resources around? For example, a system administrator fits better in the “manager” category most of the time, while a programmer fits better in the “maker” category. A janitor would actually be a “manager,” while a brochure designer would be a “maker.” Got it?
Let’s walk through some of these, starting with Graham’s point.
Schedules and Multitasking
As Graham observed, makers often must focus on a single task. The challenge of creating something new requires full attention, often for extended periods, and without that full attention, it is incredibly difficult for a maker to do their job.
Managers, on the other hand, are inherent multitaskers, suited to deal with things as they come along. They solve problems as they come and simply focus on the next task that has to get done.
Unsurprisingly, these two butt heads, as Graham notes.
What’s the solution? I like the solution that worked well at one of my previous workplaces. All meetings were to be scheduled on Wednesdays, preferably first thing in the morning. We might have three or four meetings in there, but they were all lined up together so that there would be as little interference as possible with uninterrupted blocks.
Wednesday mornings usually involved one central “all hands” meeting, then several smaller meetings, often pretty informal, with specific groups. We all knew that this is what Wednesday mornings meant, so we planned around it – no seven hour tasks for Wednesdays.
Beyond that, there was a second simple rule: don’t interrupt someone if their door is closed. An open door meant that the person wasn’t bearing down on a problem and you could chat with them freely. A closed door meant “send me an email and don’t expect an immediate response.” This was a useful cue for the manager types and the maker types.
Problems to Be Solved
Managers often focused on problems of people and resources. How do we keep this system running? How do we resolve this personal conflict? Who do we hire for this position?
Makers often focused on creative problems. How do we write this piece of code? How do we make this experiment work? How do we model this phenomenon?
What’s the solution? In effect, it became clear that in the optimal workplace, the managers served the makers. If the managers were doing their jobs well, the makers would be focused on their problems without hindrances.
Another important step in this area is that when great products came from the makers, everyone got credit for it. The system administrator might not have any idea what the solution – or even the problem – was about, but by bringing his skills to bear in solving computer resource issues, he made it possible for that solution to occur and thus deserved some of the credit.
There was a strong culture enforced that you were looked down upon if you didn’t give plenty of credit where it was due.
Managers were often focused on tangibles: people, equipment, and products. Their communication often demonstrated that, as they would describe things entirely in the real world.
Makers were often focused on intangibles: ideas, theories, and potential solutions. Their communication often revolved around these areas, things that might mean very little to the managers.
What’s the solution? Everyone – managers and makers – had very clear and specific concrete goals in mind – the end products. Then, everything was discussed in terms of those products. The managers would think about what resources needed to be applied to get that product. The makers would focus on solving the creative problems that would need to be solved in order to produce the product.
Who would represent the work when talking to others? It depended heavily on the audience. At conferences of peers, it was often the makers who took the stage, as they could talk about the concepts quite well. When pitching the results for more funding, the managers would take the stage, as they were focused on the concrete elements of the results.
Obviously, makers tended to build good connections with other makers and managers tended to build good connections with other managers. That’s not to say that relationships didn’t bridge that gap, but the strongest connections were between makers and between managers, not crossing that gap.
Obviously, both styles of connections are really useful. Makers and managers can bounce ideas off their peers, but crossing that gap can provide really useful insights as well.
What’s the solution? In terms of conferences, makers went to meetings where makers congregated and managers went to meetings where managers congregated. Connecting with peers was the key here.
However, inside the office, there was often a point of having that manager/maker gap crossed. Managers and makers would often have lunch together. The head of the office might be seen having a dinner with a newly hired programmer, and a researcher grinding through an intense project might be eating with a system administrator. Many special projects would involve a maker and a manager working together, too.
What Can You Do?
So, how can you put these ideas to work where you are? I suggest five tactics for making your workplace more useful for everyone (which will not only improve your own standing, but help everyone get more done).
First, make an effort to schedule some big blocks of undisturbed time and make the schedule clear to everyone, even outsiders. Suggest this to everyone in your office. In effect, create some periods where, no matter what, people won’t be disturbed from their work (without an utter emergency). This gives makers time to settle in and managers time to focus on more introverted tasks (and meetings with other managers).
Second, try to bundle meeting times. See if you can find a certain day of the week that’s mostly devoted to meetings and other such interactions. This makes the uninterrupted blocks much easier for everyone to implement.
Third, offer comments that focus primarily on the end product. Don’t worry about what printer goes where (unless you’re the system administrator, in which case you should deal with it on your own) or what algorithm to use (unless you’re a programmer, in which case you should talk about it directly, programmer to programmer). Instead, when you’re meeting together with both managers and makers present, focus on just the product. It’s what you all have in common and it’s what you’re all focused on in the big scheme of things, so focus on that. Take the implementation details elsewhere.
Fourth, keep the product in mind when you’re working, no matter what you’re doing. Almost everything you do has some connection to the end product. Keep that connection in mind – and make that connection clear to everyone. Even things like expense reports have a connection – they help compensation for trips or other activities go to the right place, and those trips and other activities helped the product. If there truly is no connection between your task and the end product, you should be asking why this is happening.
Finally, give lots of credit, always. The artist doesn’t accomplish much if the janitor doesn’t empty the trash. The janitor doesn’t have a job if the artist doesn’t produce. You need each other and you both deserve recognition for making the end product a reality. This doesn’t mean you thank every single person for every single thing, but you never lose by thanking contributors of all kinds whenever you’re talking about your work. The managers make life manageable for the makers and the makers make life for the managers.
Time and time again, I’ve seen that modern workplaces thrive when they do more of these things and waffle when they do less of these things, from my years working for a huge employer to my days working for myself at home. You win – and everyone wins – when everyone realizes they’re really working for the same things – a great product, recognition, and a fat paycheck.