Where You Want Variance

Setting an objective separates what must happen from how to make it happen: the that and the how.

The that is the outcome you specify. The how is the choice of method you leave to judgment. A manager says “get this report done by Friday” (that) but doesn’t specify whether you work from home, use a template, or start at midnight (how).

The same distinction appears within each task. Every how, once you look closer, contains its own thats and hows. “Use a template” (that) but choose which sections to emphasize (how). The decomposition can continue as deep as you want to go.

Building systems that try to capture how I work, I’ve noticed the boundary between that and how isn’t fixed. It moves.

When something is tacit—when I can’t articulate why I make a certain choice—it has to stay a how. I leave it to judgment because I can’t specify it. But as tacit knowledge becomes explicit, hows can be decomposed into thats. The thing I used to leave to discretion becomes something I can nail down.

Specifying a how reduces variance: outcomes have one less way to differ with the person doing the work or the mood they are in. The process becomes more predictable and easier to control.

For a long time, I thought variance reduction was straightforwardly good. The whole point of building systems is to make outcomes more reliable, right? Take what used to depend on individual judgment and make it dependable.

There are places where you don’t want variance reduced.

Aircraft engines: no variance wanted. Every bolt torqued to spec, every procedure followed identically, every deviation flagged. The whole point is that the engine behaves the same way every time. Variance here is failure risk.

Art: variance is the point. If every painting followed a procedure so tight that any trained person would produce the same result, we wouldn’t call it art. We’d call it manufacturing. The whole point is that the outcome depends on who’s making it and what they bring to it.

The question becomes: where should we reduce variance, and where should we preserve it?

The answer depends on the objective. If you want reliability, reduce variance. If you want creativity, preserve it. If you want both, you need to be very deliberate about which parts of the process get specified and which stay open.

This is what makes system design hard. The ability to specify something doesn’t mean you should. As our tools get better at capturing tacit knowledge—as AI helps us articulate things we couldn’t articulate before—the can question gets easier. More things can be specified.

As more things can be specified, deciding which ones should be specified matters more.

I’ve been building a system that helps me process information. Early on, I tried to specify everything. I wrote rules for classifications. Handlers for edge cases. The system became rigid in a way that defeated its purpose—it followed my specifications and missed what I actually wanted.

The fix was knowing where to stop specifying. Some things stay as principles rather than rules. Some hows stay as hows even when I could decompose them further, because doing so would work against the objective.

The variance I preserve is discretion I’m choosing to maintain. The system works because of the remaining hows. They’re the joints that let it flex instead of snap.