Let us talk about everyone’s favorite pastime: Reorgs! There are many reasons why they happen, some very valid (like economic necessity or making sure the right people end up in the right position) some a bit less (e.g. a new manager wanting to leave a scent mark or sidelining an underperformer without stepping on anyone’s feet).
In this article I would like to argue that one of the reasons for organizational changes is that there is a tension between two competing ways of mapping teams to the value stream of an organization: Vertical, meaning mostly orthogonal to the value stream or horizontal, meaning along the value stream. Furthermore, these two form opposing poles in a magnetic field that causes organizations to turn in circles, continuously chasing the benefits of the pole furthest away.
To be clear, I fully agree that sometimes it is necessary to shift things around inside an organization to reflect new or shifted priorities. Each time this is done, however, it comes with a hefty price tag: Many people find themselves with new responsibilities, leading to initial inefficiencies, double work, or unclear priorities.
Consequently, most people will probably agree that it should be preferred to limit the frequency of such changes. There is thus a class of reorganizations that I am skeptical about as they seem to simply follow an infinite cycle, driven by opposing attracting forces.
Think about your organization in terms of a two-dimensional picture. The dimension from left to right represents your value stream, the sequence of steps that need to happen before any value is delivered. Understanding customer requirements, engineering work, quality checking and potentially consulting activities could all exist somewhere on this axis. You may also want to add sales activities somewhere at the very left of the stream. Furthermore, importantly, if you have any in-house tools and components that go into the final output or if you use the output of any other team, these intermediate steps exist somewhere in the value stream.
The y-axis in this picture corresponds to the various distinguishable outputs that your organization has. If you produce multiple products, each line could correspond to one product. If you have a project business, each project or each customer might be a separate line.
If you wanted to start from scratch to place teams in this picture, any scheme you could come up with would fall somewhere between the following two extremes:
The Vertical Organization
In a vertical organization, teams correspond to vertical slices in this picture. You could see this as a form of specialization: One dedicated team is capturing customer requirements across multiple projects, a different team is building UI components for all products, there is a dedicated customer service team, a dedicated QA team, dedicated operations, etc.
One way of looking at this form of organization is that it is the principal way of enabling synergies. That’s the advantage that a large organization has over a small one: One dedicated legal team can take care of all contract negotiations for instance. Following the same reasoning, you could reason that it makes sense to centralize UI engineering competencies and operational work into specialized teams. This reduces waste as multiple customers could have the same requirements which will only get implemented once.
Of course, there are problems with this form of organization. For example, any book around the principles of DevOps will elaborate in great length why it is often a bad idea to separate engineering and operations into specialized teams: Engineers that are responsible for operating their applications are more likely to produce reliable code and are more motivated to find ways around annoying or repetitive operational tasks.
Generalizing this intuition, by selecting a vertical organization you broke down the walls between individuals with the same specialization but you created new walls in those places where a hand-off between teams is necessary. Any hand-off comes with a lossy communication channel. Having a dedicated product management team for instance means that PMs are less aware of current technical opportunities and low-hanging fruit as much as the engineering team will be less aware of the customer’s reality. Their communication is constrained by the interface between the teams.
The same is true for the hand-off between the team that wrote the UI components. The UI engineers will likely have less information about the way that their creations are being used than if they had directly contributed their code to the customer-facing application. This in turn leads to waste due to misaligned priorities or quite simply teams building the wrong thing, a result of a long game of telephone.
The Horizontal Organization
The horizontal organization forms the other extreme in this spectrum: Teams are aligned along the value stream. In the most extreme case, you could see this as several tiny companies existing next to each other, each doing their own thing. Selling the product? The product team does it. Operating the product? Their responsibility. Customer service? Ditto.
This leads to more people having to wear several hats depending on the current needs as is often the case in small businesses. This in turn leads to very short communication channels around a given output. In some cases, what would be a hand-off in a vertical organization could now take place in the head of a single person overseeing several steps of the process. This leads to reduced cycle times, faster feedback loops, and a consequently reduced likelihood that the wrong thing is being built.
Skelton and Pais use the term “stream aligned” in their book “Team Topologies” to talk about teams directly on the value stream. Using this terminology, in a fully horizontal organization every team is stream aligned.
The downsides of this structure are clear: It disregards all the achievements of the modern big organization, any synergies between product lines are lost and you have to wonder why all of these independent teams would be part of the same company in the first place.
Furthermore, projects beyond a certain scope are simply not feasible in this setup. I don’t see how one might go about building a nuclear power plant without many specialized teams playing their part.
The Pendulum
Certainly, real organizations usually contain both horizontal as well as vertical aspects. However, irrespective of how you slice and dice the cake, you will have to draw the lines somewhere.
I will try to avoid making a pseudoscientific reference to Dunbar’s number, but let us just agree that the number of people that each individual can keep close contact with has some upper limit. Therefore, it is a mathematical necessity that every organization larger than a certain size will have silos. The good news is that you get to pick where they are.
Any such choice will come with downsides. Veering towards the vertical structure will increase the amount of waste produced by building the wrong thing, veering towards the horizontal structure increases the waste resulting from doing the same thing twice.
The tension between these two poles creates the pendulum effect: At any given point in the organizational spectrum, it is tempting to see the benefits of the other philosophy and to move in that direction only to discover the downsides a couple of years down the road. The result is a constant back and forth between these extremes, causing friction every time the direction changes.
An Escape Plan?
Some people will object that even with the barriers of any given organizational structure in place, steps can be taken to tear down silos and to get people from different teams to work together. This is not wrong, however, it does not come for free: You will have to pay the price of additional communication overhead. This realization does give managers one more parameter to play with but it does not change the underlying problem.
Others might point to matrix structures like the now-famous Spotify model in which an individual is located both in a team corresponding to their horizontal location in the organization (what they call a “Chapter”) as well as another team corresponding to their horizontal location (called the “Squad”). I do think that this model is interesting as it connects more people through one hop of indirection: I know a front-end specialist from my team who in turn knows the front-end specialists from other teams. It still does not change the underlying fact that boundaries are being drawn somewhere. In practice, one of the two dimensions will likely turn out to dominate the other. In the case of Spotify, they make it clear that the horizontal axis is the dominant one. It is a great example of making the communication structures explicit but I would not expect a free lunch.
The real way out of the infinite loop as far as I am concerned is to do the hard work to determine, which of the models fits the profile and positioning of the organization and to commit. This is a strategic choice.
In an organization with a functioning command and control structure in a domain and market that is very well understood I can see how a mostly vertical structure might work. It can be a strategic fit if replicating the same pattern over and over again in the most efficient manner is what matters most to your bottom line.
However, the more common situation in the parts of the industry that I have seen is that market conditions are not clear and that constant product discovery work is required. The biggest risk in these markets is to build something that fails to deliver value. If this is your case, it might be better to start with a horizontal philosophy and to only opt for vertical integration in a few critical places where a communication bottleneck can be tolerated in exchange for greater cross–organization synergies.
Most importantly, however, I think that an organization needs to accept the fact that by getting the benefits of one of the strategies, it won’t be getting the benefits of the other approach. It becomes a conscious sacrifice that is part of a larger strategy. By creating an internal platform team, you consciously choose to be a bit less reactive to changed market conditions. Your strategy becomes to compete on the throughput of output but not on lead time to requirement changes. By embracing DevOps on the other hand you accept that different flavors of the same operational patterns will be implemented over and over again. Having the intellectual honesty to accept these trade-offs may keep the pendulum from swinging all the way back the next time around.
The Solution Space 