In this issue: Food safety, Hollnagel’s ETTO principle (revisited), tension theory, manufacturing serendipity, the four horsemen of tensegral failure.
Patience Zero
One of the most interesting concepts to emerge from our work from the Summer of Protocols is that of a tension. It’s a subtle, but important level-up from the more popular concept of a trade-off. We’ll explore this concept, its definition, and potential applications in this essay.
A couple hundred entrepreneurs, engineers, and protocol designers now use tensions as a key component of their mental models. Since last spring, I’ve hosted over twenty iterations of this workshop, called the Tensions Game, in partnership with Edge City and 0xPARC, to develop the concept of tensions with professionals from all sorts of backgrounds.
These workshops simulate the use of tensions in live-fire, infinite-game scenarios where problem management is superior to problem solving – a budding principle of protocol science – and challenge players to imagine futures, full of competing visions and governed by strange new rules.
We think a powerful sensemaking approach to complex systems could emerge from these modest beginnings, and that everyone involved in protocol design or managed evolution should master thinking in tensions﹣which can be counterintuitive.
“Balance is not about eliminating tensions; it’s about making use of them.”
- Karl Weick, Sensemaking in Organizations
By nature we’re inclined to eliminate tensions, usually through violence, rather than make use of them. History books are full of bitter lessons proving that. So, what are tensions, how are they different from simple trade-offs, and why should you care?
Camp Clean
Let’s start with a basic case: there are times to be efficient and there are times to be thorough. When you’re in the woods, the standard for dishwashing is camp clean. A bit of leftover oatmeal or coffee grit is ok. Not so much in an industrial food plant. Frito-Lay could singlehandedly launch an epidemic by adapting its protocols to a new policy of camp clean. Also, if your hiking buddy acted like a foodsafe inspector, you’d probably stop inviting them out.
We can scale the gravity of this problem all the way from a weekend camping trip to the behavior of governments – institutions whose inefficiency we often rely on for purposes of long-term strategic coherence or on account of principles of human decency.
Efficiency and thoroughness are both valuable characteristics, but are fundamentally opposed. Erik Hollnagel, a prolific safety researcher, dubbed this the ETTO Principle, short for Efficiency Thoroughness Trade-Off.1 It’s impossible for an individual to be maximally efficient and thorough at the same time. To attempt to do so is to fail with certainty. If a hiker tried to set a record pace and thorough dishwasher on the same trip, they would fail – by slowing down, compromising on coffee grits, or starving to death because, well, the surest way to keep your dishes spotless is to not eat.
“ETTOing well is the pathway to glory; ETTOing badly will make you feel sorry!”
- Erik Hollnagel, The ETTO Principle
Protocols can modulate the ETTO of a process. In safety-critical operations, like the deployment of AI in healthcare settings, thoroughness is preferred. A recent extension to SPIRIT (“Standard Protocol Items: Recommendations for Interventional Trials”) includes steps to document AI usage.2 Watchdogs can spot potential issues faster and improved traceability can aid accident forensics. In the case of pandemic response, often decision speed (a form of efficiency) is more important than precision (a form of thoroughness).
Another example: Coordinate leadership is a lightweight emergency protocol that comprises two steps: get frontline staff with knowledge of the situation into a decision-making position and provide them with unlimited access to senior leadership, who offer authority and oversight. Emergency protocols, like coordinate leadership and those that compose the Incident Command System3 are unreasonably sufficient at improving safety, given their simplicity.
The question of whether to be efficient or thorough can be relatively straightforward in one time scenarios like emergencies. The issue is that we carry over the logic of trade-offs to more complex, ongoing situations where a good solution might be a bigger problem in disguise.
From Trade-Off to Tension
The TO of ETTO stands for Trade Off, but that starts us off on the wrong foot. The best way to understand the relationship between efficiency and thoroughness is not as a trade-off, but as a tension. Even Hollnagel, who coined the term, knew this well. Trade-offs are an aspect of one-time decisions, or finite games. When players know a game’s endpoint in advance, ends can justify the means of sacrificing dynamic range (See Fig. 2). In the short run, the costs of hyperefficiency and hyperthoroughness can be delayed long enough to win. However, in scenarios with an unknown number of repeat decisions, or infinite games, players benefit when they respect the preferences of all others. You win the most points by keeping the game alive. In infinite games, there are no trade-offs – only tensions.
coined our working definition: “A tension is a trade-off plus a conflict.” Actors have different preferences with regards to how they make trade-offs. These differences spark conflict. To think in tensions, rather than trade-offs, is to avoid unnecessarily reducing the complexity of a situation.Resilient people and organizations share a common quality. They use protocols to get to and shift along the ETTO frontier. When first formed, processes are rarely efficient or thorough. Same with new technologies, which have unresolved bottlenecks, vulnerabilities, pinch points and externalities. A good operator can protocolize a process to improve both efficiency and thoroughness as much as possible, then reprotocolize to a different point along the ETTO frontier. Protocolization first corrects weaknesses, then exercises dynamic range.
It’s not enough to achieve a stable pareto-optimal ETTO distribution. You have to shift your management style once in a while to avoid stagnating – but not too much. All tensions have at least four obvious failure modes: maximization (one in each direction), context traps, and spin cycles. Let’s take a look at a famous case study through this new lens.
Amazon’s Serendipity Manufacturing Plant
Jeff Bezos’ fabled API Mandate illustrates how managing the efficiency-thoroughness tension required Amazon to exercise its dynamic range as an organization.4 Temporary focus on thoroughness enabled winning efficiency in the future, thanks to long-term expansion of the ETTO frontier. Thoroughness creates conditions for compounding returns from efficient processes and, importantly, luck.5
In 2002, Bezos issued a directive – the API Mandate – all teams at Amazon now had to communicate through standardized APIs. While this introduced significant challenges, including the need to overhaul existing systems and processes, it forced the organization to adopt a more modular and interoperable structure. This approach prioritized long-term scalability over immediate productivity, setting the stage for greater independence among teams and creating the groundwork for future developments like AWS.
The cost of tension is conflict. In an organization, some units are geared towards efficiency (like sales, finance, and operations) and some are oriented towards thoroughness (e.g. legal, HR, marketing). They will get into arguments. This is good. The benefit of maintaining the tension in an organization is the progressive expansion of the ETTO frontier, through the exercise of dynamic range.
The API Mandate enabled future efficiency, allowing Amazon to meet a fortunate influx of consumer demand. Their hard-earned modular computational and operational structures earned dividends. It was time to rotate back into thoroughness. Amazon’s next step was to protocolize internal infrastructure into external-facing services – now known as Amazon Web Services (AWS). This was an expensive investment; AWS required reliable, scalable, user-friendly services. Customers demand a level of usability far beyond that of internal engineers.
Armed with a kit-like service offering, and having found themselves smack dab in the middle of a huge demand for compute power, Amazon then shifted to another phase of efficiency. More hardware meant economies of scale. With a thoroughly designed off-the-shelf product, the company could focus on rapid growth. Margins would grow naturally. No need to think through everything. It was a time for checklists and routine. The flywheel was firmly anchored by prior thoroughness.
This path was not at all obvious and required the company to check itself with regards to some regular blunders that are common across all tensions. We can illustrate how Amazon’s engineers avoided maximization, context traps, and spin cycles, using the efficiency-thoroughness tension as an example.
Four Horsemen of Tension Failure
Amazon maintained tensional integrity.6 They avoided all four modes of efficiency-thoroughness failure.
Hyperefficiency is common in financialized industries, where balance sheets and dashboards become the main viewport of an organization. Cost-cutting initiatives make progress, but ultimately run the risk of killing the golden goose, screwing up strategic coherence, or decreasing resilience. Amazon avoided hyperefficiency by issuing the API Mandate and then by establishing a new business line in AWS. These thoroughness cycles were profoundly unattractive when Bezos first pitched them, but ended up being foundational.
Hyperthoroughness is the Achilles Heel of what I call artistic enterprises, like creative agencies, craft goods, and videogame studios. These org cultures have completionist and perfectionist streaks which can overpower efficiency functions like project management and go-to-market teams. Amazon avoided organization-scale perfectionism by copy-pasting its organizational structure and then focusing on economies of scale when growing AWS.
Context traps are a mismatch between an actor and its environment. It’s why you don’t invite restaurant inspectors on backcountry skiing trips. For an organization like Amazon, context fit is achieved by providing value to customers. A sudden switch in market conditions (or any sort of major environmental factor relevant to a particular actor) can drop a business into territory where its internal model no longer corresponds to the outside world. Competition can also drive context failure. Differences in efficiency or thoroughness between two firms can deeply impact odds of success, and do matter, but the trick is to avoid getting caught up in unnecessary “arms races” towards efficiency or thoroughness, and to focus on maintaining sufficient adaptability.
Spin cycles are the fourth killer of tensegrity, rooted in a lack of discipline or commitment. The reasons for Amazon’s success in avoiding indecisiveness are twofold. First, the widespread commitment of Amazonians to follow key protocols like the API mandate, whether in the direction of efficiency or thoroughness. Second, but later, compartmentalization allowed Amazon to make even better use of tensions. Entire departments could be oriented towards being efficient or thorough, balancing each other out. Keeping this tension provides Amazon with dynamic range.
ETTOing for Protocolists
Hollnagel’s ETTO Principle is a useful mental model for protocol designers, especially when cast as a tension. I chose it for its versatility — you can easily increase the domain specificity by modifying it (e.g. Ease of Use vs. Security, Productivity vs. Safety, Exploit vs. Explore, etc.) to a specific problem.
Here is a starter checklist of questions that you can ask to force consideration of the efficiency-thoroughness tension into your protocol design process:
Are we in a position where both efficiency and thoroughness can be increased?
For decisions: How quickly do the costs of inaction grow? How expensive is a wrong choice?
How can our organization leverage the tension between units with different ETTO preferences?
Should we lower performance targets to invest in thoroughness?
Can we replicate or scale what we have, instead of creating new versions?
I challenge you to start looking at your surroundings in search of protocols and the tensions they manage. I put together this field guide for myself last year – you might find it useful as well.
A few notes to remember along the way – tensions incur ongoing costs of conflict, but unlock future optionality by manufacturing conditions for luck and efficiency. Trade-offs belong in finite games, which are rare (and therefore dangerous to use in your mental models) in the tangled, technological bank that is the real world.7 If members of your organization are not having disagreements about the ETTO principle, you have a problem. Beware both religions of efficiency and cults of thoroughness.
Happy protocol watching! Share your finds in #protocol-watch or #candidate-tensions on our Discord server.
https://erikhollnagel.com/ideas/etto-principle/
https://www.thelancet.com/journals/landig/article/PIIS2589-7500(20)30219-3/fulltext
The Incident Command System (ICS) is commonly triggered in the wake of disasters like wildfires and and floods. https://en.wikipedia.org/wiki/Incident_Command_System#History
https://chrislaing.net/blog/the-memo/
Honorable mention to Buckminster Fuller’s concept of tensegrity﹣ a “structural principle based on a system of isolated components under compression inside a network of continuous tension”﹣a portmanteau of tension and integrity.
The term technological tangled bank is inspired by Darwin’s portrayal of flora and fauna as neighbors in a tangled bank of vegetation, but with modern technologies spliced into the already complex, living system. See more in this presentation: Plenary Talk - 2024 Protocol Symposium
I like the idea of tension. Tension does not need to be binary though. For example in the case of efficiency vs. thoroughness I'd add a third obvious option: innovativeness. Innovations are neither efficient nor thorough. They may be promising but at the start they are poorly formed. So they can't be very good at what they are supposed to do, perhaps only a prototype. And because of lack of scale, they can't be efficient either.