Leadership is like ‘steering a ship’ (or so they say). While startups do float in an ocean of venture capital, I don't believe startups are boats full of whisky and lots of sailors.

A company starts to feel 'chaotic' when there are multiple overlapping changes that affect 'you'. It is impossible to know which changes require your full attention and which ones can be ignored. Corporate chaos is a failure of coordination. People, sometimes depending on seniority and sometimes tenure, learn about things at different times and may be reacting while others people are learning about a change for the first time. This lack of coordination makes people feel unstable and people start saying:

1. Why wasn't I involved in that decision?

1. I want to be in the leadership meeting so I can give my input earlier next time.

1. This change was poorly communicated, I'm not bought in.

In any organization, things that work at small scale, where individual competence is the limiting factor, slow down and stall as you scale the activity and the systems/organization become the limiting factor.

In a small organization, communication can happen synchronusly. A common failure mode is when companies transition into either async engagement or 'listen only' meetings to address scale. On a macro level, the company transitions from one room to many rooms and on a smaller level, individuals transition from individual contributors to leaders of a function (or leaders of leaders).

Changes 'reverberate' through companies as people process individually, discuss with peers and then react. The people are tied together, like knots on a string by a shared interest in the success of the company.

If you try to make too large of a change or make too many changes in rapid succession, the string's movement is no longer smooth but chaotic and unpredictable.

The problem occurs in two flavors — the slime mold flavor and the military hierarchy flavor. The latter is worse, so you should try to be like slime mold.

Theory of change

In the string metaphor, a change has two properties - its size (amplitude) and its speed (frequency).

In this metaphor, a large change at low speed will take along time to move the entire organization string to a new direction. A small change a high speed propagates almost instantly.

In a real company, hierarchy slows down information sharing by just adding lots of hops for any message. It takes time to meet with each group to distribute information. During the distribution, the message may distort or new information may get added. The 'startup chaos' emerges as information is slowly propogated through a hierarchy that then overlaps with smaller high speed changes.

So, lets think about how we can get information sharing under control. Can we can affect information size and information speed?

Waterfalls

A simplistic communication path might be a linear path from C Suite → Senior leaders → Managers → Team members. This ‘alignment structure’ follows a 'waterfall pattern'.

An 'alignment structure' trades speed for stability. All communications are delayed to a regular cadence and then cascaded through the org.

In waterfall software development, you end up with a firehouse of feedback late in the implementation phase. Late alterations mean communication moves 'up the waterfall' (ie from ICs to managers) and then back down again.

This waterfall communication strategy, can create 'bureaucratic' companies that fear change. A fear of change is a rational response to an environment where change is more difficult than dealing with the incrmental uncomfort of the current reality.

What is another structure that could reduce the decay of information and perhaps be better for a 'high change' company?

From alignment to involvement

Instead of an 'alignment' structure that slowly cascades, what if we just…worked together. Lets call this an ‘involvement’ structure.

In this scenario, an 'involvement structure' might look like a cross-functional team that includes few people people who identified the business opportunity and a few people who are trying to build the solution. By working together, information can be distributed from its original source, interrogated, acted upon and then the implementation reviewed all within a cohesive group.

The challenge with the ‘involvement’ structure is that it asks some busy people to block time at the same time. Involvement processes also necessitate small teams which requires aligning on trusted deputies from each function. Many organizations are not good at either of these things.

As for how specifically to implement an alignment structure, there are many approaches from co-reading before meetings, to off-sites and hackathons. Alignment structures are ways to distribute information where, for a moment, the organization is flat and all people working on a problem have the same knowledge at the same time and the cross-function group co-creates a higher resolution output like a prototype or a detailed spec.

Alignment is easy now, harder later. Involvement is harder now but easier later.

The agile organization

This is a proposal for small, short lived silos. I believe that an organization with many small 'involved' groups that, periodically 'align' via the waterfall approach can be extremely effective. But, how is that actually different from standard organization practice?

In short, a kickoff meeting is merely sharing information from a higher group in the hierarchy to a lower group - it is not 'involvement'. The difference is that 'involvement' processes encourage people to collaboratively solve problems instead of merely passing information.

People are highly adaptable. People can form different structures that suit the needs at the time. In these smaller silos, larger changes can propagate immediately and solutions beyond local maxima can be reached. Involvement structures are different for each project and build a competency of organizational adaptability, empathy and trust for people on other teams.

How has this manifested for me?

In short, I've mistaken structural problems for people problems. I might take people aside or do an offsite to ‘right the ship’. But, my interventions had nothing to do with solving the stressors affecting the team. The people were great, they were just consuming a diet of poor information.

Like the Mentats in Dune, teams need a diet of high quality information to function. Teams can be short circuited by giving them partial information or too many metrics. My teams with good, clear information tend to be much happier than teams with sporadic bits of information and unclear measures of success. Like software decay (ie: ‘bit rot’), information exists in a dynamic environment and becomes less valuable as time passes and the surrounding context changes.

Communicating information is also very hard. Once when adjusting my team, I got buy in from each team member but I put little effort into bringing along the People function. Instead of meeting with them, I shared them on various emails and slack messages, with the bits all out of order, passed in some perverse game of telephone. Their part of the string was not happy to get pulled along by me. While I could have shared information with them more effectively, what they wanted was to co-create the solution.

Slime molds and military hierarchy

Takeaways

A company is not a ship to be steered, but many loosely organized groups of people.

I believe successfully communications is more about managing how information reverberates and less about crafting the perfect message. If the communications reverberate and then change as they are passed between many groups, a chaotic team culture can emerge. If communications are too slow, backchannels will emerge that break the intended cascade and feedback lool, again contributing to the feeling of chaos in the org.

As a solution, I want to ask, if information cascade is needed, can the communication be done extremely swiftly? If not, is there a way to foster deep involvement and co-creation rather than message passing? I believe those are a couple ways we can change our structure to better manage those 'information reverberations' and make a company feel less hectic.

I believe we can change how people are organized to make sharing easier. While I don't have a perfect general answer to apply to all companies, I suggest trying to think about information cascades more like trying to change the direction of a string than steering a ship. I believe this will help identify the right structure for your organization.

References

• There is no villain responsible for this. Coordination simply becomes vastly more difficult far earlier along scaling trajectories than people realize. Things get worse than you expect, sooner than you expect. This is coordination headwind. It’s an exponential snowballing phenomenon.

• There are many sources of coordination headwind — execution uncertainty, ambiguity of goals, effort fragmentation, cost of deconfliction through escalation, sensitivity to small misunderstandings, attribution errors, obstacles obscuring goals and timelines, negative network effects, and so on.

• All contribute to create a superlinear relationship between scale and coordination headwind intensity. This happens with mathematical inevitability via multiplication of long chains of numbers that are individually high (like say 0.95) but net out to a rapidly falling probability of accomplishing anything.

• People routinely and radically underestimate the massive size of this effect, and misattribute it to bad management, individual incompetence, or malice, and systematically under-react to it, doing too little, too late, and letting the problem grow to crippling, existentially threatening levels before even recognizing it.

• When things stall due to coordination headwinds, people predictably pull out a variety of responses that at best don’t work, and at worst, make things work. These responses include: excruciating process discipline (spreadsheets!) to control uncertainty, heroic dragon-slaying efforts, simply ignoring it, leaders “diving in” to “help out,” and of course, throwing more people at the problem.

• There are no easy answers, but one general approach is to replace big, brittle long-term goals that are fragile to coordination headwinds with a process of iterative retargeting (Komoroske uses the metaphor of “roof sighting”).

None of the individual ideas is particularly new, and many specific bits have been better articulated elsewhere. But what is impressive about this deck is that it integrates all these well known bits and pieces into a coherent and digestible overall ELI5 picture with the right proportions and pattern of emphasis.

I want to quickly point out a few connections to other ideas that get at the same phenomenology but in a more piecemeal way.

• Komoroske’s analysis is a generalization of Brook’s Law (adding people to a delayed software project delays it further) that accounts for many more sources of increased coordination load besides adding people.

• The idea of “iterative roof-sighting” is very closely related to the one articulated in a famous paper by Charles E. Lindblom, The Science of Muddling Through, where he calls it the method of successive limited comparisons.

• Not explored in the deck, but the popular heuristic that important problems have to be solved anew at every scale is basically an acknowledgment of coordination headwind effects. Each new scale boundary is marked by the collapse of the coordination approach used at the lower level.