Feedback is more powerful than your own intelligence

Don't ever make the mistake of thinking that you can design something better than what you get from ruthless massively parallel trial-and-error with a feedback cycle. That's giving your intelligence much too much credit.

— Linus Torvalds

Torvalds wrote this while arguing on the Linux kernel mailing list, and the line carries the bluntness usually forgiven in someone who has sustained one of the most complex artefacts ever built for several decades. But it is not a provocation. It is a fairly exact description of how the material we work with behaves, and the part that usually goes unnoticed is worth pausing on: he does not say design is useless. He says that believing your design can outperform a massively parallel loop of trial and error is a miscalculation about yourself.

What a design can know

An upfront design can only contain what you knew before you started. That is its limitation, and it is not correctable with more talent or more planning time. When you project a digital product solution, you are working with information that mostly does not exist yet: you do not know how the system you are building on will behave, you do not know what people will do with what you hand them, and you do not know what other uses — often the ones that end up mattering — will appear at the margins.

The temptation is to treat that ignorance as a temporary deficit: if we research a bit more, document better, produce a more detailed design, we will clear it before spending money on building. There is some truth there, because some ignorance really does dissolve through reading. But most of what you need to know in digital product belongs to another category: it is only revealed once something is put in play. It is not information waiting to be found. It is information that gets produced.

This explains an experience anyone who has directed product recognises: the moment a team starts building is also the moment the questions that should have been asked earlier appear. They did not appear earlier because they could not.

The loop as an organ of intelligence

Torvalds's line puts intelligence in an uncomfortable place. Not in the person deciding, nor in the document, nor in the quality of the reasoning. It sits in the circuit: in how fast a consequence returns to whoever caused it, and in how many attempts that circuit can process.

The idea is old and well established outside our craft. Cybernetics formulated it as the minimum condition of any system capable of governing itself: without feedback there is no correction, and without correction there is no direction, only trajectory. Deming carried it into the factory by insisting that quality is not inspected at the end but built inside the process, and that a process without internal measurement is blind by design. Evolutionary biology describes it as an algorithm that produces extraordinarily good designs without any designer, purely through variation, selection, and repetition over a long time.

What the software industry added to that tradition was a practical fact: the cost of an attempt can be driven close to zero. That is the structural condition that makes Torvalds's claim especially true here and not in bridge-building. If trying is expensive, you have to think hard before trying. If trying is cheap, thinking hard before trying is a sophisticated form of waste.

Why organisations lengthen their loops

If this is so obvious, the interesting question is not how to shorten the feedback loop but why organisations systematically lengthen it. And lengthen it they do, with great effort and good intentions.

They lengthen it every time they introduce a step where information is aggregated before travelling. A weekly report is longer than a data point; a committee is slower than a conversation; an executive summary is cleaner and less useful than the original complaint. Each layer of aggregation improves readability and degrades signal, because the first thing summarising removes is precisely the anomalous, and the anomalous is where new information lives.

They lengthen it too every time they separate the person deciding from the person receiving the result. A product manager who never sees the support ticket, a designer who never watches a usage session, an executive who only sees the aggregated quarterly chart: in all those cases the loop still exists, but it has grown so long that the consequence arrives after the decision has already been replaced by three others.

And above all they lengthen it for a reason nobody says out loud: a short feedback loop exposes mistakes fast. It is a machine for producing evidence that someone was wrong, and in many management cultures that gets administered as reputational risk rather than as an asset. An organisation that punishes error cannot have a short loop, however many tools it buys. It will always choose, with reasonable-sounding arguments, the path where being wrong takes longer to become visible.

What this asks of whoever directs product

The operational consequence is less glamorous than the quotation. It consists of treating loop length as a variable of organisational design, as important as the product architecture. How long a consequence takes to come back. How many attempts fit in a month. How many hands a piece of data passes through before reaching someone who can act on it. How much it costs, in time and in reputation, to say out loud that something did not work.

And it consists, too, of accepting a certain modesty about your own judgement. Not the rhetorical modesty of saying we do not know everything, but the operational kind: building your processes as though your best conjecture were going to be refuted, because statistically it will be. Torvalds is not asking you to stop thinking. He is asking you to stop betting your project on having thought enough.

How long does it take, in your organisation, for a bad idea to stop looking like a good one?