TL;DR: The old-style, bureaucratic org chart has a bunch of levels; information flows up the levels, decisions flow down. A resilient, generative org chart is nested; information flows up and down; decisions flow sideways.
A high-resilience organization solves novel problems, such as building software. It is generative, always creating the next version of itself to solve the problems that will appear tomorrow. A resilient org creates positive outcomes, even when something is going wrong somewhere all the time. Just like resilient software.
Software is all novel problems: everything we do is design; everything is new, because if it had been solved already we’d call that code and be done. (Sometimes the novel problem is connecting our system to the service that does what we need.) The work of development is making decisions: what questions to ask, what to implement, how to know it works, all the way down to what character to type next.
Information flows down
These decisions take information. We need all the details of the particular code we’re working with, the service we’re trying to call, and the production constraints. We also need the broader purpose of what we’re doing, so we know how to handle errors, how much work to put into speeding it up, and how to “compromise without derailing.” (Evans)
The best (and quickest) decisions are made steeped in the context of what is present, while understanding the broader perspective of what is needed.
David Silverman in Team of Teams sees parallels with modern military operation. In Vietnam, the military used new communication technology to do ever more old-style coordination. People pushed information up through several levels to an admiral in a helicopter, and waited for decisions to come back down. That admiral never had enough information, or timely-enough information, or even the brainpower to absorb it all if he had. This was the bureaucratic organization at its peak, showing its weakness.
More recently in Iraq, they found success when units made decisions on the ground, after sharing information in a giant daily meeting and then coordinating resources with nearby units. This was a resilient configuration, with information flowing outward to teams, and details negotiated between them.
The job of managers is not to make decisions. The leader’s job is to push information down to the teams, so the teams can make decisions in the midst of their deep context.
A manager makes decisions about the organization they lead, but not about the work. A leader grows the organization that can make decisions about the work.
Some information flows up the org chart, some comes from outside, and more flows down.
Decisions go sideways
Decisions are made in a distributed fashion, not at the top of a hierarchy.
Heinz von Foerster suggests “heterarchy” instead: “Each employee in a company is a manager in his or her own area of expertise.” Decisions are made by teams, in consultation with adjacent teams that are affected.
This is more than a good idea in software. It’s unavoidable. Development teams tell the software what to do. The software’s behavior impacts interfacing software.
Like it or not, software developers are making the decisions that determine how the business runs. Make them informed decisions.
And listen to what the development team experiences. Don’t just look at metrics! Ask for surprises, struggles, news that can affect a wider scope. “What did you learn this week?”
The heterarchy of decisions functions within a hierarchy of support.
Nests instead of levels
This hierarchy is not expressed in levels.
Our tendency to organize the world, and our companies, into uniform levels is unnatural and un-resilient. Levels of organization are “structure we’re imposing on the world, [not] structure we’re reading off the world.” (Potochnik)
What does a “Senior Engineer II” in the front-end of an retail site have to do with a “Senior Engineer II” in data processing for recommendations? Nothing. Nor in any other department. Stop categorizing for status. Uniformity is not resilient.
Delineating levels across specializations is an imposed structure that distorts our organization.
In nature, the world doesn’t divide neatly into levels. It does nest, subsystems within subsystems.
As in software, encapsulation helps. The resilient org chart leaves internal details of teams and divisions to those teams and divisions. Without this, there is no self-organization.
So draw an org chart with some leaders, and then some organizations one level down. Smaller organizations or teams are nested within, rather than arrayed below.
Like in software: I want that module to work, and to work with the other modules. I don’t want to think about transitive dependencies if I can help it.
A high-resilience organization keeps decisions down where the details are. It does this by pushing information and strategic direction outward to the teams. It lets the subsystems and teams grow themselves, with encapsulation of structure. Leadership doesn’t control the work; it guides and supports the growth of the systems that can change the work.
If you know what problem you’re solving and you know how to solve it, a bureaucratic organization will do. Stick with what you know.
If you’re writing software, that’s a generative activity. You need a high-resilience org chart. Fewer boxes, more flexibility.
References
Understanding Systems, by Heinz von Foerster and Bernard Poerksen
“Our World Isn’t Organized into Levels,” by Angela Potochnik (pdf)
“Patterns of Generative Cultures: How They Can Be Destroyed and the Importance of Trust with Dr. Ron Westrum,” an episode of The Idealcast by Gene Kim
“The Principles and Practices behind Team of Teams,” a series of episodes of The Idealcast (starting here)
Domain Driven Design, by Eric Evans.