Baby Steps Toward Accepting the Maker’s Schedule

The engineer sat down at her desk, excited at the prospect of making headway on her project. She was on track to deliver an API that the UI team downstream would soon need.

The engineer sat down at her desk, excited at the prospect of making headway on her project. She was on track to deliver an API that the UI team downstream would soon need. She glanced at her calendar, and her mood sank. A one-to-one meeting with her manager, another meeting to update the team on project status, an onsite interview, and a phone screen sliced her day apart, ensuring that there was no continuous block of more than an hour open aside from lunch. She sighed; given the complexity of the code she had to implement, her code wouldn’t be completed today. This phenomenon, aptly summarized in Paul Graham’s Maker's Schedule, Manager's Schedule post, came up at a discussion during an event for all engineers and managers at Delphix. The notion is that people who are making things want to be able to use their time in larger blocks, in order to maximize progress toward a goal. By contrast, managers are accustomed to changing tasks more frequently. After all, a manager’s job isn’t to build a thing, it’s to ensure that the team building the thing has what it needs.

engineer in a meeting

I know what you’re thinking. Oh, boo hoo, if you have too many meetings, just start offering new schedules and/or refusing some of them. That works when the meetings have few attendees or are engineering-only, but it isn’t always that easy.

  • Meetings with folks in other disciplines, particularly ones that are under pressure, such as sales, are more difficult to turn down. Sales, in particular, either wants information that will help make money, or should get information that will keep them from promising something that will cost the company money. These meetings are often important, and will just happen anyway.

  • Interviews are also difficult for engineers to control, since they have to account for the schedule of an interview candidate as well as the interviewer, and typically several engineers are scheduled to interview the candidate on the same day. While it might be possible to swap a slot with someone, there’s no easy cure to the problem there, since no one is immune to the effect.

  • In addition, engineers who have built up ownership of areas of the code base are commonly sought out by others to consult on issues that relate to the areas they own. Sometimes these are scheduled meetings, and other times they occur ad-hoc.

Any of these types of interactions in isolation won’t cause much trouble -- each represents only a short interruption. Taken together, the effect is devastating to a maker’s productivity. A number of us at Delphix really wanted to solve this problem. The makers, after all, want to make stuff. The managers want the help solve the problem as well; we didn’t get into management to damage the productivity of our colleagues! It is clear to us that if there are multiple causes to the problem, there probably isn’t just one solution. As stated earlier, the solution for less critical meetings is to just not have them. Engineers with more ownership may opt to condense demands for their time by holding “office hours.” These only go so far. To help with the scheduling of interviews, we are experimenting with software to cap the number of interviews sent to any developer, and working with the recruiting to ensure that an engineer’s interviews are scheduled close together instead of scattered across the calendar. It might mean that we’ll all need to have more discipline about respecting interview start and end times, but asking for discipline from highly educated professionals isn’t a stretch. Perhaps the biggest step we’ve taken so far is setting aside an entire day as a “Maker’s Day,” where meetings and interviews are discouraged. They’re not prohibited; the idea is to give makers a tool by which to control their own lives, not to control it for them. It exists now as a calendar invite for everyone in engineering that blocks off the entire day.

interrupted engineer

If the first step toward solving a problem is admitting the problem is there in the first place, then I’d like to think we’ve now taken two steps forward. The feedback from members of the team so far is very positive; it seems the “Maker’s Day” and changes to the way we schedule interviews especially have helped to build awareness of this issue throughout the organization. They’re small steps, to be sure, but the hope is that in the future we will be able to do more to conform to Makers’ needs.