Maker's Schedule, Manager's Schedule

[jducoeur]

Thanks to my co-worker Tonytip for the pointer to this fine article about the two types of work schedules.

The high concept -- not astonishing, but well summarized here -- is that managers and programmers simply work on different sorts of clocks (different granularities, more than different hours), and there's a great deal of friction when those clocks need to overlap. Traditionally, programmers are forced to run on the manager's granularity, but smart companies are starting to take this problem seriously, to find ways to let programmers work in their natural mode more often...

Comments

[goldsquare.livejournal.com]

Pshaw. :-)

It's an OS scheduling problem, where one process has lots of little tasks (managers) and one process has one big one (programmers).

Managers just context switch more often. And better.

[be-well-lowell.livejournal.com]

Managers can context switch better because the context is usually smaller. Or so my manager tells me.

[metahacker.livejournal.com]

+100.

So, having been a coder, then a manager, then a coder again...(and now creeping up on management again...)coding takes up a HUGE amount of mental context. Like a lot. I'm always surprised when I jump back into coding how _hard_ it is and how many loose ends there are to remember.

Managing takes up a lot of context, too -- but that context is all active during a meeting -- meetings are when you *use* that context. Unless it's a highly technical meeting, the context of the engineer is not engaged, except during those crucial 20 seconds when the manager asks "So, Pat, can we wibble the frotz?" And human-context carries over from one meeting to the next. Except when you go to external meetings outside your report chain; those really do require a context shift, though generally from 'detailed' to 'abstract'.

[goldsquare.livejournal.com]

Hmmm.

Maybe I'm not very good at "management things". In my current position I occupy a rather odd middle ground - I do supervise staff, I also do hands-on technical work.

I find that in either case, I'm often solving problems of an equivalent magnitude. When I spend a day or so working on management sorts of things, I find that I KNOW I'll have to do a lot of context switching, but the context seems, to me, to be just as weighty. Knowing in advance that I will have to, I do it anyway.

[jducoeur]

It's an interesting point. I'm in a similar position, and I agree that the management context doesn't exactly seem smaller. But there *is* a very strong qualitative difference, that I'm having trouble putting my finger on. The management-brain is -- I dunno, a bit squishier and less focused, more holistic. It generally lacks the precision and depth, the *specificity*, that I require when I'm programming. Even when I'm coding something large, I am far more detail-focused than I am in most management tasks, because the details usually loom larger in the result.

That switch back and forth, from the holistic big-picture view to the precise programming one, may be part of why I find the context shift especially time-consuming. There's often a lot of grinding in the mental clutch...

[yakshaver.livejournal.com]

I was thinking as I read the title, "Bet my rss reader has a new Paul Graham essay...."

[learnedax.livejournal.com]

Hmm, yes, this is particularly familiar for me right now, as our early-stage Scrum transition has meant about 30% of work time is in meetings sprinkled awkwardly throughout our schedule.

[umbran.livejournal.com]

...but smart companies are starting to take this problem seriously, to find ways to let programmers work in their natural mode more often...

And really smart companies work both ends, rather than just one.

You see, allowing the programmers (and sysadmin types) to work on the Maker's schedule is only one technique. The other is a coding discipline - break up your tasks into smaller chunks.

One of the big notes for scrum masters is that user stories should be broken down so that each story represents no more than a week of work (what that means in story points depends on your team). Some practitioners work straight from user stories, but that doesn't help you here. The full procedure then has you breaking user stories down into development tasks required to make the story go.

At a maximum, those tasks should take no more than a day. If you are doing them right, they are each notably less than a day. You lose far less production to interrupts if your atoms of work are less-than-half-day tasks than if they are all half-day and full-day tasks.

If you have found yourself in a place where you can't generally break work out into more, smaller tasks, that's a sign of code-cruft, previously undisciplined coding practice, or simple brain lock - failing to notice that if you need to do X, Y, and Z to accomplish the task, then X, Y, and Z can be atomic tasks themselves. And maybe you can't do all three before the meeting, but you can get X and Z done, and Y can wait until later.

[jducoeur]

While partly true, I think this oversimplifies a bit. I've worked in that mode -- hell, in the last days of Convoq I was running it -- but I still find there to be a significant overhead involved in mental context shifts, and there's some extra overhead involved in managing the discipline you describe. This is especially true because meetings happen on fixed schedules, and fitting one's tasks around those is generally imprecise.

So while you're right that a user-story-and-task-focused development discipline helps (and I'm quite looking forward to our project getting to the point where I can be mostly working in that mode), it doesn't entirely solve the problem...

[umbran.livejournal.com]

And if I said it entirely solved the problem, then you'd have a point.

I said that really smart companies use both techniques.

[evil-macaroni.livejournal.com]

Interesting article! I noticed a similar work mode in the hands-on engineering world. When I had tool access, it wasn't worth my time to just spend an hour in the cleanroom - I worked far more effectively if I had a nice 3-4 hour chunk of time. With only 1-2 hours I'd just be getting set up and in the rhythm when I'd have to stop what I was doing. There were a lot of engineering tasks where if I had a midday meeting I knew that I should just forget about getting them done on that day and focus on the smaller stuff (if possible).

[leanne-opaskar.livejournal.com]

My artist's schedule is much like a programmer's schedule. I can't do *anything* in an hour ... well, maybe ink or sketch one page, that's it. Forget coloring or trying to do anything else more complicated. I get pretty frustrated when I have lots of errands and things to do ... it makes it so hard to get down to work!