Human Networks: Coupling, Cohesion & Encapsulation
If we want to build responsive organizational systems, then we should be serving resilient, fault-tolerant networks.
It has become fairly common among organizational designers to use evolution and ecology as metaphors for adaptive systems design. While I agree that living systems are structurally what we’d like to achieve with movements like Responsive, I think that there is enough intent in our work to make this metaphor limited, especially in inspiring how we go about creating/facilitating the systems. In other words, when we work with real clients on actual projects, we have to design the systems and walk with people through the changes to achieve emergence, where in evolution change and novelty are naturally emergent.
So when I think of adaptive/emergent systems that have some level of human intent behind them, I immediately go to networked computing.
In certain types of networked systems design there is a set of concepts known as coupling, cohesion, and encapsulation. Getting those concepts well organized in the system’s architecture can lead to stability, but not at the expense of adaptability. Specifically, well-executed systems are conceptually easy to modify, extend, and delete (if necessary). Really resilient versions are also highly fault-tolerant, meaning they can deal with problems without whole system crashing. I think those are good characteristics we try to achieve for our clients in our org design work at The Ready, so to Aaron’s point above, I’m going to try to offer non-software (but still somewhat specialist, sorry!) definitions for each of the terms. Further, I’ll try to explain why I think most well-designed organizations have limited coupling, high cohesion, and disciplined encapsulation.
Limiting Role Dependencies: Coupling In Human Systems
My proposed definition for coupling in organizational design is the degree to which a role, team, policy, or process (we’ll call these “nodes”) is directly connected to others. By connection I mean that it is either dependent upon, or depended upon directly. If a node is tightly coupled, then that means that a large number of other nodes share dependencies with it. Therefore, making a change to that node is difficult since we likely need to make changes to all the other nodes to which it has dependencies. Tightly coupled nodes are difficult to modify, extend, or delete, so they are a barrier to responsiveness.
My proposed definition for coupling in organizational design is the degree to which a node is directly connected to others.
We can control coupling by thinking about interoperable interfaces. More simply, these would be standard ways that what a node does interacts with other nodes. Think about two teams that work on different projects within an organization, one in finance, and one in manufacturing. Early on, they don’t imagine that there will be crossover between their work, but increasingly meeting “next steps” are “call so-and-so in Finance and get their perspective on this” or “email she-and-she on the Manufacturing Team because this will change their forecasting.” Suddenly the group manager or the team leads add a process where meeting minutes have to be sent between the two teams, and financial models have to be approved by both team leads, and a bunch of other connection points. It’s arduous, but makes both teams effective. Then the manufacturing team is told by the CEO that the FY2018 strategy has changed, and now they’ll be making a whole new type of widget. Their outputs totally change, as has the need to be connected to the Finance Team, but they have a bunch of governance that requires approvals between the two. It all gets very messy, a phenomenon known as organizational debt.
Now imagine the same two teams operating independently, but their data, meeting, and weekly outputs are stored in a standard format on an accessible, searchable drive, accompanied by good instructions and contextualizing information about how to use them. All someone has to do to access them is tap into that interface with the proper permissions and credentials, and they have access to it. They might occasionally still need to ask the Finance or Manufacturing leads for advice or context, but these conversations can be focused and efficient and ideally, infrequent. The well-designed interface, which in this case is a standard means of sharing, accessing, and interpreting information (part policy, part technology) has cut down dependencies. The best part is that the standard interface is super scalable, because any other properly credentialed team has access to the same information without us having to predict in advance that they’ll need it.
To be clear, we don’t want to eliminate coupling. Coupling is what makes the system networked and useful. We just want to 1) limit it as much as possible for a given node and 2) control/standardize it as much as possible to keep it easy to modify, extend, or delete.
High Level Concerns, Low-Level Implementation: Cohesion In Human Systems
I define cohesion for organizational design as the extent to which given nodes work together in service of a greater value than can be achieved from the node alone. To make this definition measurable means we have to understand both extent, and the higher purpose to which nodes are aligned.
We need to understand the high level concerns of our group as well as low-level implementation details.
To achieve cohesiveness, a given team or group or company must hold in its hands two concepts: 1) the purpose that brings them together and 2) how that impacts their daily work and responsibilities. Side Note: Since at The Ready our goal is always cohesiveness in service of adaptability, I’d add 2a) the recognition that #2 can always change in order to better serve #1. In other words, we need to understand the high level concerns of our group as well as low-level implementation details.
When we’re designing adaptive organizations, it’s important that we make sure all the nodes be defined as simply as possible for their given level. In other words, we want roles to perform (ideally) one function, and teams to perform one mission, and business units to take advantage of one revenue domain (I know, I know, but I said ideally!). This allows us to achieve low coupling, and high cohesiveness between levels. The opposite is when we create roles that do everything. In software, these are called “God Objects” because they “know too much.”
Keeping in mind that roles are different from people, imagine if you had one role in your organization whose responsibilities were:
Mining consumer insights
Developing new product ideas
Paper prototyping new product ideas
Conducting user and business research to determine idea priority
Conducting engineering analysis to determine idea possibility
Hard prototyping new product ideas
User testing prototypes
Designing & purchasing tooling for scaled product rollout
Writing marketing plans for new products
All of these are reasonable functions in a common workflow. However, not only would this be a colossal lift, if we assume that a given organization has multiples of these roles, we would get very little cohesion between their low level implementation (such as how they choose to build, store, and research prototypes). That causes a massive coupling issue, breaking our adaptability.
Reasonably, we can break each one of the listed functions into (at least) its own role, which allows us to limit the responsibility of each node, making direct coupling straightforward and modular.
Teams Choose their Own Ways of Working: Encapsulation in Human Systems
Encapsulation in organizational design is the idea that, with effective interfacing, teams can work whatever way they choose. In other words, as long as I provide quality standard outputs, and people know of a quality standard way of working with me, how I choose to get my work done shouldn’t really matter.
Encapsulation in organizational design is the idea that, with effective interfacing, teams can work whatever way they choose.
This is the toughest part to explain, I think, so bear with me. Basically, if a team understands how to work with other teams at the company and can share what it creates in a way that respects the norms or governance of the rest of the organizational system, then it doesn’t ultimately matter much how the team gets things done (from a technical standpoint, not an ethical one). Again, interoperability is the key here, and determining and standardizing the interfaces between nodes of the organization is the make-or-break when it comes to encapsulation.
This piece is simply intended as a light primer to begin talking about some really important (I think) features of systems design. I’m going to continue building on this, so feel free to challenge my thinking, add clarifying questions, or just respond below. I think if we can start to deepen our consideration of human systems and mire ourselves in the details a bit, we’ll be equipped to run up against real world scenarios with a high degree of preparedness.
My name is spencer pitman. I consult with The Ready on organizational design, and I advise some companies on product development, mostly in the distributed systems and commercial aerospace industries. These days I spend my free time riding my bike around New York City, so if you’re in town, let’s get some miles in.
