Few topics are as hotly debated in companies as the question of how to organize people into teams and departments. All kinds of arguments are thrown around, ranging from span of control for managers to optimal professional and personal development for frontline people. Of course, not all of these discussions are genuine and only focused on the best outcome for the company. Quite a few are driven by the personal ambitions of the individuals and the perceived implications that a particular choice of organizational structure will have for them.
The second challenge I experience in many companies is that everyone jumps on organizational design questions without a clear understanding of what that organization is supposed to accomplish and how it’s supposed to interface with other parts of the company or the business ecosystem. In this context, many years ago, together with colleagues, we defined and published the [BAPO model](https://janbosch.com/blog/index.php/2017/11/25/structure-eats-strategy/), which seeks to address this challenge. In this model, we claim that the business and the business strategy should be defined first. These should be used to define the architecture and technology choices. These, in turn, should be used to develop the processes, ways of working and tooling. Only after these three elements are in place should we focus on the organization.
In practice, most organizations are OPAB. The existing organization causes a set of processes and ways of working to appear as some people and teams are close and some are far away. These processes then result in an accidental architecture that’s, Conway’s Law style, a reflection of the organization that built it. As it was never designed intentionally, this accidental architecture then results in a highly limited set of business strategy options.
That said, we can use organizational changes as a mechanism to drive changes in processes, ways of working and architecture. However, we should have a very clear picture of the intended implications of the new organizational structure. In practice, the road to reorganizations is paved with good intentions but typically ends up in a worse place or doesn’t have any real impact on the company at all.
Assuming we have the B, A and P figured out, we can start to reason about organization. Rather than beginning at the top, we approach it from the bottom here: teams. The key factor to consider is coordination cost. One of the patterns I’ve noticed is that the larger the company, the more time people spend in meetings. In my experience, nobody likes meetings particularly much, but we all agree to join them and participate because we understand that we need to align our efforts to ensure that we’re all contributing to the common goal of the company or, at least, the business unit that we’re part of. The larger and the more complex the business unit, the more meetings are required to ensure alignment.
At the same time, we’re acutely aware of the fact that being in meetings is more of a necessary evil and less of actual work. Especially mid-level managers as well as quite a few architects and senior technical staff tend to only sit in meetings and are, de facto, information conduits between different parts of the organization and no longer do actual work. All sacrificed on the altar of bureaucracy!
The need for alignment won’t disappear, but there are ways to significantly reduce it. The two mechanisms I’ve found the most helpful are aligning through architecture instead of through process and converting inter-team coordination into intra-team coordination.
Although many people find this a confusing concept, the fact is that we virtually always have a choice when thinking about aligning teams between process and architecture. Aligning through process typically means meetings where different teams come together to talk about the touchpoints between their work activities and how to ensure that problems are avoided.
Interestingly, we can do the same through architecture without having to have meetings. Simply by having one team work on one side of an architectural interface and the other team on the other side, there’s no need for process or meetings as long as both teams respect the interface.
In practice, this is how business ecosystems are organized: the ecosystem defines interfaces between the various participants and as long as everyone abides by them, things are fine and dandy. Of course, these interfaces aren’t simply APIs but include expectations, business models, assignment of responsibilities, competition between different parties vying for the same role at the same interface and so on, but the principle holds. The reason that business ecosystems provide a competitive advantage over other forms of organizing is the reduced synchronization cost. This is achieved through agreed-upon interfaces.
Changing the architecture is very difficult in business ecosystems, although it can and is done continuously. Within organizations, it’s easier, though not trivial, and this is where architects play a central role. Here, we’re back to process, though, and architecture refactoring, which we discussed earlier.
The second mechanism is to convert inter-team coordination into intra-team coordination, which is at least one and often two orders of magnitude more efficient. This means that when we organize work, we should seek to structure teams so that coordination inside teams is maximized and between teams minimized. The consequence tends to be a cross-functional team that can take a requirement or hypothesis all the way from the initial idea to deployment without needing to interact with other teams.
For this to work, the team has to include all functions and capabilities required to execute the entire process, including product management, user experience, architecture, development, testing, deployment and customer support. Consequently, it’s highly cross-functional. This way of organizing is very different from classical organizations where people tend to be organized based on their discipline and function.
There are many arguments why people stay away from cross-functional teams, including concerns about competence development, not all roles being required equally, performance assessment and so on. In my view, however, we should prioritize reduction of coordination cost over everything else, hence cross-functional teams, and develop mechanisms to compensate for the challenges of this way of organization.
Few topics lead to as much excitement and energy as discussions around how to organize people and teams. Many begin with the organizational structure where I argue to start from business strategy, architecture and ways of working and select the organizational structure to optimally support these. In general, the focus should be on minimizing coordination cost. The two most effective mechanisms are architecture-driven alignment and highly autonomous cross-functional teams. To end with a tongue-in-cheek quote by Cassandra Clare: “Don’t sulk. For someone with the grace and coordination of a pregnant wildebeest, you did great!”
Want to read more like this? Sign up for my newsletter at jan@janbosch.com or follow me on janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch) or Twitter (@JanBosch).
