I’ve been thinking about how to represent the important bits of the current state of an organization, and here are some preliminary musings.
My sense is that the artifact will be a map of sorts, designed to serve as a snapshot of the structural “what is” in the larger process of discernment of the organization’s sum vector of intention.
For the purpose of this story, by “organizational structure” I mean a detailed enough representation of the organization that allows an observer to understand how the organization sustains and grows itself. In other words, what comprises this organization’s motor?
Suppose there’s a thriving team that is riding a typical developer ecosystem compounding loop: attaining some critical mass of users, the ecosystem attracts developers who build products and services that in turn attract more users. If we study this team, we will probably find a part of it that cares about sustaining and growing the segments of that loop. There may be some folks whose responsibility it is to ensure that developers are excited to join in and stay. There may be some who work on maintaining a high quality bar of these products, so that they are attractive to the users. There likely will be those who are asked to help bring more users to enjoy these products – and so on.
Given that this team is thriving, the various units within it collaborate effectively, forming its structure. Using maps as an analogy, this structure is sort of like the terrain: the rivers, roads, and mountain ranges. They aren’t something that we imagine to exist, but rather have to exist, since we can clearly observe their effects.
At first, I thought finding these units would be just a matter of looking at an org chart, but it doesn’t seem to be the case. Several times now, I’ve recognized this pattern where the reporting charts reflect more of an emergent outcome of operational convenience, rather than represent its structural underpinnings. Org charts are akin to the administrative boundaries on maps: cities, counties, and districts.
In the example above, there may be the growth team, the product team and the infrastructure team in the org chart. These boundaries help immensely with managing resources and priorities. However, they say almost nothing about the nature of the compounding loop. There might be one group in the org chart that actually contains several structurally significant units, or conversely, multiple org chart groups that are actually one unit. Just like in topography, rivers can cross districts and a county may span multiple mountain ranges.
There tends to be a temptation to shoehorn structural units into administrative or vice versa. I’ve tilted at this windmill myself. If you worked on the Chrome Web Platform team in 2016-2017, recall the ill-fated “Programmification” project. I still cringe when I think of the matrixed-org diagrams I drew with that unhealthy high-modernist sheen in my eyes. Often, it is more productive to simply accept that structural units and org charts are two different things – and stay aware of the difference to not accidentally conflate them.
It also seems clear that the terrain and the administrative boundaries are not orthogonal to each other: they interplay. Watersheds often define county lines. Streets are organized into rectangular grids. Similarly, org charts both impact structure and attempt to reflect it. Conway’s law hints at how seeking operational efficiency may – often unintentionally – influence the overall intention of the organization.
When a leader is looking to get a big picture of the organization, what they are probably asking for is a map that shows both the terrain and the administrative boundaries, and highlights how they play off each other.
So the question I am facing is: how do I map the terrain within an organization? The org charts are accessible and convenient, yet the structural units are typically less so. I am still at the early stages, but my intuition is that this will be an iterative process. I am planning to arrange it as a dance between three parts: the org chart, the list of compounding loop hypotheses, and the list of structural units.
The org chart is basically an anchor among the three, with the other two developing through iterations. The dance goes like this: using the org chart as a guide, populate the compounding loop hypotheses list with some initial values. As best as we can discern, write down the hypotheses for organizations’ compounding loops. There may be more than one, some that are quite clear (for example, “this is where most of our revenue comes from”), and some so vague that all I can do is speculate that they are there.
In parallel, rely on the org chart to spot units. I am still working on a decent rubric here, but it feels like it will be something like this: look for groups that do something different from the rest of the team. In engineering teams, they might have different codebases or bug labels or components, different processes, release targets, and/or priorities. They would typically (but not always) come with a sense of identity among its members – a sense of togetherness that can survive the reorgs and changes in leadership.
A good marker that I am looking at a structural unit is that once it exists, any attempts to break it apart face strong headwinds. This is likely because it is a load-bearing part of the organization, and mucking with it tends to shift what organization does. Drawing an administrative boundary over the river does not stop the flow of water, unless we put a lot of effort into building a dam.
As another possible source of insight, talk to the team veterans. People within the organization tend to intuitively know this structure. They know where structural boundaries are drawn and don’t need the map to navigate them. This is tacit knowledge and something every new member has to learn.
Once the first pass for creating both lists is complete, the next step is to stare at both of them for a while and try to match the units to the compounding loops. Which unit seems like a segment of another? Which unit looks like a part of a compounding loop yet unlisted? What units should be there but aren’t on the list?
This process is likely to yield more questions — and optimistically, the questions that are more interesting — that I can use to spelunk the organization in another round of this dance. Fingers crossed, after a few iterations, the lists of hypotheses and units settle down, revealing the terrain. What do you think? Would this work? I’d love to hear your suggestions. And I keep you posted about this adventure of organizational cartography.