Part III — Cultivating Organizational Flow · Chapter 48 · 4 min read · First Public Draft

Technology

Multiplying What's There

Technology is a poor first move and an excellent second one, which makes almost all of this about sequence.

Christoffer Råsten

Reduces frictionCreates valueOwnership clarityHandoff lossDecision latencyLearning cycle time

Faster, and Still Wrong made the observation: technology multiplies a capability and has no opinion about whether the capability was any good. This is the chapter about using that on purpose.

Which is mostly a question of sequence, and sequence is a much better piece of news than it sounds. Nobody has to give up on the platform. The argument is only about what happens in the eight weeks before it arrives.

What changes

Technology stops being the thing you buy to fix an organizational problem, and becomes the thing that multiplies whatever the organization already is. The buying decision gets easier once that is settled, because you are no longer asking the tool to do something tools cannot do.

Ask what it assumes before asking what it does

Every platform encodes a way of working. Who approves. What constitutes a team. Where a decision sits, and how many people have to touch a thing before it counts as done. Those assumptions were reasonable in the organization the product was designed for, and they arrive in the box whether or not they match yours.

This is worth doing as an actual exercise rather than as a caution. Take the shortlist and, for each one, write down what it believes about how work gets approved. It takes an hour, it is more interesting than the feature comparison, and it occasionally eliminates a front-runner outright — usually the one that assumes a central function you spent three years dismantling.

The assumption also outlasts the contract. Long after anyone remembers choosing the tool, the organization will still be shaped a little like it.

Fix the ownership first, because the multiplication is honest

Scaling a capability nobody owns produces more of a thing nobody owns. This is the most reliable way I know to spend a large budget and change nothing, and it is very difficult to see from inside because every individual step is competent.

The good version of this is quick. Before scaling something, establish who would be able to say the output was wrong, and how long that answer takes to arrive. A name that answers in a day scales well. A committee that meets monthly is still an owner, but scaling the work without scaling the answering makes the forum the constraint on everything downstream of it. And a shrug scales into a much larger shrug.

Keep the map alive

Naming capabilities once, in a workshop, with cards, is the enjoyable part. The map is only worth something if somebody keeps it current as the organization changes shape underneath it — and it will, roughly every eighteen months, whether or not anyone updates the diagram.

A map nobody has touched in two years is a historical document. It is still interesting; it is no longer something to decide from.

Measure the path, and then the other end of it

Lead time for changes and deployment frequency are friction measures wearing engineering clothes. They are well defined, already collectable in most places, and the research linking them to commercial performance is stronger than anything else in this paper. If delivery is slow and ownership is already clear, Accelerate has far more to offer than I do.

But they only measure the pipe. An organization can get both numbers into the top decile and still ship, weekly and reliably, things nobody asked for. So the pairing worth building is one movement measure and one outcome measure, side by side on the same page: how quickly change reaches production, and whether anything changed for anyone once it got there.

The second number will be worse, later, and softer than the first. Keep them adjacent anyway. Two numbers of unequal quality, looked at together, produce better conversations than one excellent number looked at alone.

When it isn’t the pipeline

If delivery is technically excellent and things still take nine months, the pipeline was never the constraint. Look at what had to be decided, by whom, and how far it travelled — and expect to find the answer somewhere in the first half of this paper rather than in any tool.

That is not a disappointing result. It is a considerably cheaper one than the platform would have been.

This cultivates: Faster, and Still Wrong, in Part II.