Skip to content

Scale your processes with organizational size

Short thought for today, but, I think, an important one.

You know what’s guaranteed to piss people off? Filling out TPS reports when you’re a 5-person startup. Conversely, if you’re trying to figure out how things are going with a project involving hundreds of people, you will need a little more process and status reporting.

The key is figuring out the right transition points, and ensuring you make those transitions before you get lost in the mess that ensues from attempting to scale an unscalable process.

Don’t get hit in the face by the equivalent of Dunbar’s number in process failure, where you hit it and everything starts to fall apart in a rapid downward spiral. This applies to every organization, whether it’s a corporate entity or an open-source project.

One way people get around Dunbar’s number is to break up groups of all-to-all links in communities into bundles of loosely coupled, separate communities with a small number of bridges between them. How can you apply that to process? Make sure it’s only applied where necessary and no further; sequester process to the greatest extent possible, and minimize the leakage of process to other groups/divisions/etc.


Categories: community, distributed-development.

Comment Feed

2 Responses

  1. examples? Gore. Any others? who does this well?

  2. I’ve lived this story over and over.  Living it again right now.  The interesting piece of making this change is the organizational sociology associated with making the changes.  Typically there are a few areas that I run into.

    Individual and organizational agreement that is directly coupled with individual and organizational change resistance.

    People hold on to the old way of doing things longer than they should. 

Some HTML is OK

or, reply to this post via trackback.