One of my favorite managerial tricks is to introduce the idea of ‘coordination cost,’ as in “How are we going to manage to coordination costs here?”  or “What would estimate the coordination cost on this is going to be?”  or “Looks like a coordination problem.”

I find this helps people step back from the problem at hand and reframe things, looking at it more as a dance.

When I’m feeling particularly silly I like to be sure everybody gets to listen to this amazing recording: Postal Workers Canceling Stamps at the University of Ghana Post Office.  And then we can talk about the possibility that we just might achieve that imaginary happy state.

There is a huge amount of friction in organizations around coordination costs.  And most schemes for organizing things are really, at their heart, just a bundle of choices about how to lower that friction.  In a sense that’s all that Paul Graham’s nice recent essay “maker’s schedule, manager’s schedule”  is about.  Though in this case he’s highlighting a sort of meta-friction that arises when the standard that achieves low friction for one group runs up against the standards that achieve low friction for another.  I was pleased that he is much less polarizing in this essay then he often is.

Reading his essay I was reminded by a posting I made a long time ago about what makes for a great environment to assure high programmer productivity.  The environment outlined there is much like the one Paul appears to be advocating.  But I have my doubts.  Bill Tozer’s comment raises some of those concerns.  He’s more confident of what’s right than I am.  I tend to think what works varies a lot.  Which if true only makes for more friction as what works for this part of the process or people rubs against what works for something else.

I recently had a friend recommend what I should read about Scrum, and he pointed me to an excellent long essay (pdf).  Given my allergies to singleminded frameworks for solving all the worlds problems I was emotionally prepared to dislike what I read.  But I loved it.  I mostly found myself recalling when in my life I puzzled out this or that rule of thumb that I seen these folks have adopted.  So instead me rolling my eyes and saying “Oh please?”  I found myself saying “Oh yeah! Ain’t that the truth.”

So for some large class of software development activities I think you could do much worse than to adopt those methods.  But, these methods are quite disconnected the list of what makes for a great environment for programming, and there is reason for that.

The Scrum methods reside in a middle ground between Graham’s manager and maker time.  In the middle between the social network managers live in and the work of individual craftsman – a place where focused teams reside.  So these rules are about managing the coordination costs that arise there.  Between team members, between product and program managers, between designers and engineers.  In that world you need to strike a balance between coordination costs – interupts, meetings, et. al.  and pure versions of maker or manager time.