Organizing for "Efficiency"

 

I gave a talk at the local PDMA group called “Setting Expectations Between Engineering and the Three PMs”, attempting to clarify how the roles of product management, program management, and project management are sometimes confused, and to suggest practices that help people unconfuse them. I set up teams of people to create a little project (making greeting cards), having people take on roles as one of the PMs or as an engineer. During the debrief, one of the participants said something like this (I’m paraphrasing because I don’t remember the precise words): “We spent a bunch of time trying to organize around the most efficient way to do things — in an assembly line way — and we were dead last. In fact, we didn’t finish the task. We were the least efficient.”

That team had attempted to plan and implement via the architecture. One person would do all the fronts, one person would do the insides, and one person would do the backs. (In the talk, I’d recommended they implement by slice, doing one feature all the way through the architecture, but that was foreign to this group, so they tried the normal-for-them-approach.)

I’ve run this simulation many times, and this was the most obvious example of how assembly line organization isn’t the most efficient for brand new or not-repeatable-work work. In software, every project is unique. By definition, it’s unique, because if you already have software to do it, you don’t have to write more. If I’d had the teams generate 6 or 7 greeting cards, then assembly line organization might be effective, because the work is repeatable (in the boring sense of the word). But for one card, taking the time to organize in an assembly line wasn’t worth it.

The lesson here is not to prevent people from organizing themselves. We rarely perform 5-10 minute projects. Even if we do, it’s probably worth taking the time to make people comfortable in their organization. But the lesson is this: If you’re developing a unique product, don’t bother trying to optimize around when you do which piece. (Don’t bother organizing all the GUI work together as an example.) The lesson is that implementing by slice, implementing one complete feature at a time is more efficient than grouping all like work together.

One Reply to “Organizing for "Efficiency"”

  1. Hey JR.
    I wonder. Perhaps talk of “efficiency” in this sense – when it doesn’t work – ought to be called “theoretical efficiency”, or perhaps “apparent efficiency” or even “ill-concieved efficiency.”
    Designing a process for “efficiency” in terms of a situation you don’t have isn’t efficiency at all. I wonder whether in addition to the guidance on what to do, a note about abuse of language might also help. “Efficiency” is the bang / buck you get, not the bang / buck you think you ought to get in some world that isn’t the case.

Leave a Reply