A further note on organisation design & feedback loops

An organisation is primarily made up of feedback loops. A feedback loop improves itself, and any part of an organisation without a feedback loop stagnates. The design of an organisation is then primarily a game of building self-reinforcing feedback loops.

The quality of the people in the loop is not even as important as the pain that the feedback loop causes in the people when it is negative. People will naturally seek every method to resolve the pain.

The natural thing they will always want to do is to remove the feedback loop. It is uncomfortable to grow, because growth stretches people. It makes them think. Removing the feedback loop solves this for the individuals, but kills the company.

As a company grows, the loops it needs changes. A very early stage marketing department may optimise for signups on the waiting list, and this loop is out of date in a few weeks. But someone needs to change it, and the department itself is incentivized to remove it, but not to replace it with anything else.

Luckily, a company does not need a great number of loops, so they do not need to be adjusted often. However, they do need to be adjusted by people who are NOT affected by the impact of the loop (the new work it creates),but only by the positive outcome of the loop.

The design of such loops, however, is not only difficult, but it also requires domain expertise at both the departmental level, and the organisational level. As companies grow, there are often gaps where that individual simply does not exist.

A feedback loop does not have to offer positive incentives, I would even argue that positive incentives are a sign of a poorly designed feedback loop. I rather think that the feedback has to rather introduce pain for a non-working loop. Like an engine gear that grinds because it is poorly aligned, the loud crunch immediately makes the operators correct the operation of the machine. Contrast that with offering the operators a bonus the longer they keep the machine running - will they stop operation for proper servicing, when needed?

The ideal loop is that the creators of the machine use the machine to make the machine. For example, a programming language that is written in itself.

A second, also good loop is that the creators of the machine use the machine to sell the machine. For example, a sales tool. There is internal feedback about how well it is working.

Less ideal, but also fine is where there is reasonable usage of the machine by the people who make the machine - for example, an e-commerce site.

Another ideal case is where the customer need is to precise that the usage of the machine needs to be simulated internally before it can go to the customer, and the customer will instantly complain if it differs - for example precision tools.

Bad loops are where the machine is simply created, and the team that creates it never uses it. There is no loop here. Feedback is not precisely implemented. The machine drifts from the need.

Unfortunately, the last case is very common, particular when we drop out of the organisational level and look at the matter from the team level. A small team that is working on something in particular, for example, a check-out page, may not use this check-out page very often. They just simply build abstractly, but do not really understand what the user experiences and how it fits into the overall picture of the site.

The solution here is a bit complex, but in many cases, this complexity is required. The reason there is no simple solution is three-fold a) you cannot expect team members to constantly be paying for things and b) even if they were, most team members do not have the taste required to provide feedback c) like I mentioned earlier, the team has an incentive not to add work to themselves.

The complex solution involves introducing a “taste tester” from outside the team. This person is an artist, someone who cares deeply about how things feel. This person comes in at a regularly interval to fully test this product without caring about the internals. They just get the feel of it.

Out of their test, the second “precision tool” method is developed - the parameters of how it should be are developed and described. These parameters include the entire subjective experience of the tester.

Once this is documented, then this doc acts as the baseline against which the team develops, and a lower level tester enforces this standard. This creates a feedback loop that is very flexible and can adapt.

We elevate the feedback loop design out of the team level into a simpler level above, make it flexible and adjustable, without putting a lot of mental burden on the team members.