Team organisation: horizontal vs vertical. Or is it?
How is your team organised ?
In my travels through IT-land I’ve seen basically two ways of people cooperating in a team or teams cooperating: the vertical and the horizontal organisation. In the vertical organisation, one person (or team) is responsible for one functionality, from start to finish. In the horizontal organisation, one person (or team) is responsible for a common layer of several functionalities and you need each one of them to complete a functionality. As a result of Conway’s Law, this organisation is reflected in the architecture of the systems.
Each of these ways of organizing has distinct advantages and drawbacks. Many organisations go through regular flip-flops, switching from vertical to horizontal and back, only to trade one set of drawbacks for another.
Flip: vertical
The advantage of the vertical model (the integrated team) is that they have their eye firmly on the goal: delivering a useful system for the customer.
We have all seen the disadvantages: silo systems. Systems that are not integrated, have trouble exchanging information, have nothing in common, no reuse, enormous amounts of duplication. A too narrow focus on the local goal (the current system), without looking at the global goal (all systems that support the business).
All good news voor EAI consultants and vendors…
Flop: horizontal
The advantage of the horizontal model is that the people in each layer are very knowledgeable in their area and can focus on one specific area. There’s natural reuse as all applications use common layers.
The big disadvantage is that it’s hard to see the goal of the whole system. Each layer starts to define their own local goal. The local goal can be misaligned with the global goal, or even go against the global goal. Sometimes, the means and the goal get confused: framework authors try to increase the amount of framework code that is used in applications, whether the framework helps the application writers or not; methodologists start to measure conformance to process or documents instead of results; DBAs try to increase database stability by denying all change, at the expense of the applications using the database…
Beyond the flipflop
Of course, most (larger) organisations are not organized along such clear lines: there’s a mixture of horizontal and vertical teams. In these cases there’s often a tension between the two types of groups.
Thinking Beyond Lean by Michael Cusumano and Kentaro Nobeoka describes a refined and pragmatic organisation with a combination of specialists vs generalists, reuse vs uniqueness, integrated vs separated in use at Toyota since a few years. See the previous entry for a more extensive description.
If I can choose, I prefer to start with a vertical organisation, because they have a clear idea of the goal. Then factor out commonalities. Get the different teams, one by one, to communicate with each other, to find commonalities and ways to share useful resources.
With a horizontal organisation, it’s important to make the global goal clear again for everybody involved. One effective way to do this is to create a “virtual crossfunctional team” for the duration of the project. Get the layers to communicate with each other, preferably using a “pull” model, where the layers closest to the customer request services from the layers further away.
Been there, done that!
With the exception of one case, I’ve always worked in “vertically” oriented, customer and delivery focused groups. In the one horizontal case, the goals of the group actually ended up working against the global goal.
Tomorrow, I start to work for a “horizontal” team. More stories will surely follow.
Note to self: keep your eye on the goal!
