Maker’s Schedule, Manager’s Schedule, User’s Schedule

During the recent SQLSaturday #25 in Gainesville GA, we had an open session at the end of the day which we treated like a “Meet the Experts”.  During the discussion, Cliff Jacobson referred to an article detailing the difference between the Maker’s Schedule and the Manager’s Schedule. 

Here’s the link for your reference: http://www.paulgraham.com/makersschedule.html

It’s a quick read, but I’ll sum it up for you

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… 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…

I would argue that (at least in our shop) there’s a third schedule: the User’s Schedule.  Some managers ARE users, so their time alternates between the Manager’s Schedule and the User’s Schedule, but for the sake of this discussion, we’ll keep this separate.

What is the User’s Schedule?  Basically, users only know of one time: Now().  Now is when they have to get their work done, and Now() is when the software breaks.  When their work gets interrupted, they have to resolve the problem before they can move on.

Why is this important?  Because when Users need a resolution, they don’t want to hear it’ll take a week to implement; they want it fixed Now().  When they request a feature, they want to know it’s being worked on Now().   Obviously, this is unrealistic for Makers; good code takes time to write, time to test, and time to document.  When a Maker skips one of those steps, it’s usually because they’re attempting to work on the User’s Schedule.

Now() is not necessarily a bad time; Users are not attempting to screw the Maker out of task completion.  The User really believes that Now() is when the Maker wants to know about the issue, so that the Maker can fix the problem before it gets too severe.  Notifying the Maker about the issue as soon as it happens is the User’s method of helping.

So how do we reconcile these three schedules?  Programmers need to meet with managers (they determine priority) and users (they determine requirements); in fact, the Agile Manifesto states that

Business people and developers must work together daily throughout the project.

How do you keep the conversation focused on the scheduled deliverable and not the bug of the moment?  You have to keep moving forward, but you also have to be willing to acknowledge the Manager’s need for status reports and the User’s need to report issues and request features.  I am no expert in this, but these are the principles I am starting to implement in my own schedule.

1. I’m working with Management to find appropriate times to schedule status reports.  I’m trying to fit them in either right before lunch (either the meeting ends on time, or I may get a free meal out of it), or in the last hour before the end of the day (sometimes meetings go long, which is unfortunate).    This takes care of the Management/Maker disconnect.
2. To avoid addressing issues Now(), I have started closing my email, forwarding my phone, and setting my IM status to Do Not Disturb (note: for a feature in Office Communicator, I wish I had a way to set different statuses for different contacts; DND doesn’t raise an alert, but I wish I could let my boss through) for 45 minutes out of every hour.  The last 15 minutes, I stop coding, and check email, etc.  This keeps my finger on rising issues, but is less interruptive than  constant contact.  Of course, I work remotely most days, so I don’t have to deal with Spring-Loaded-Butt Syndrome (and I’m not talking about hinges).
3. When I do contact users to deal with the bug-of-the-moment, I try to reassure them that the a) bug is being recorded, and b) will be prioritized.  We use Team Foundation Server, which is OK for a bug tracking system.  The biggest problem that I see in my current environment is that Users don’t often follow up with Managers to make sure that the issues are prioritized.
4. When discussing features for rollout, and the User attempts to bring up the bug-of-the-moment, I ask them to hold off on that discussion until the end of our stated objectives, and I encourage them to write it out.  By writing out the issue, they begin specifying the core elements of a bug report/requirements document. 

Is this perfect? No, but it’s a start.  I’d be interested in hearing what your ideas are on the subject, and what steps you have taken to coordinate Maker’s time, Manager’s time, and User’s time.