What scales, what doesn’t, what’s relevant, and what isn’t

Dear Bob …

Does it make sense to reject a process *just because* it doesn’t scale well?

As you know, this is a technical problem as well as a management/development process problem, and I’m thinking about the social engineering and management side right now.

In a technical problem, you wouldn’t just substitute an entirely different technology for one that didn’t scale. You’d buy a bigger server, distribute the load across multiple servers, or whatever, if the technology you have is the best way to do what you were trying to do.

Or at least you’d *try* this approach before discarding it and moving on to re-invent the whole thing. It’s a more complex architecture, and perhaps a bit harder to understand, but usually a substitute system doesn’t do exactly the same thing, or doesn’t do it as well.

So… why, when people start working out how they will accomplish something large, does the comment “yeah, but it doesn’t scale” stop exploration of an idea in its tracks so fast?

Let’s say you have a software development team or technique that’s working really well, but it would be hard to translate this process to work with a larger team or a longer development effort. IMHO when you hear “but it doesn’t scale” in a planning meeting, this might just be dismissive management speak for “that wouldn’t allow me to have a big enough power base.”

The technique that “doesn’t scale” might use multiple, small, focused teams. Yes, they have to be coordinated, but the power is really distributed, and if motivation is going to be high so is the credit. So… out it goes.

Anyway, I’d be interested in your thoughts.

– Scaly, but not big

Dear Scaly …

I think you’re dealing with several phenomena at once. Let’s try to untangle them. To do so we should probably define terms – what “scale well” means.

You can assess a process according to five major parameters: Cycle time, throughput, fixed cost, unit cost, and defect rate. To say a process scales well (at least, according to how I use the phrase) when you crank up throughput, the other parameters show a linear response.

To take an example: Imagine you manufacture perfume, and your factory currently ships 1,000 gallons a day. If business improves and you have to start pumping out 2,000 gallons a day, the process scales successfully if the cycle time doesn’t suffer, fixed costs remain fixed, unit costs remain unchanged or, even better, improve, and the product smells just as good.

Some processes really don’t scale very well. Some don’t scale up well, others don’t scale down, although the latter doesn’t get a lot of discussion in IT circles (other than from yours truly, for reasons I can’t explain). The IT help desk is a common example. In a small company it makes perfect sense for someone with a problem to call whoever they know in IT and ask for help. In a large corporation, this results in problems getting mishandled while developers are distracted from major projects. You can’t just tweak “call whoever you know in IT” to get it to handle the needs of a large company.

Other processes don’t scale as is but are salvageable. Elihu Goldratt developed a methodology called the Theory of Constraints to improve process throughput by identifying and eliminating bottlenecks (I’m oversimplifying just a wee bit) – it’s just the ticket for this kind of situation.

How can you tell the difference between when you need to start over and when you need to improve the one yu have? A good way to tell is to map the process (I like swim-lane diagrams for this purpose). If, as you’re doing so, you find a lot of situations are covered by “we figure it out and do what makes sense,” alarm bells should start to ring. Figuring it out and doing what makes sense is what companies do for infrequent situations. For production processes they should figure it out once … and then fine tune it.

You also mentioned a third situation – call it “rhetorical pre-emption.” It’s a particulary irritating, but highly effective way to shut down an opposing perspective. By asserting something before the opposing side has a chance to state its position, you can prevent them from ever having a chance to make the case because trying to do so sounds defensive. Playing it out, it sounds like this:

Rhetorical pre-emption: “This process doesn’t scale.”

Other side: “It does too!”

The way to beat rhetorical pre-emption is with a question, not a challenge. “Really? Show me – I’m not seeing that.”

Asking questions instead of arguing is a rhetorical technique that scales very well.

– Bob