In the light of delivering outcomes, we should consider the respective merits of horizontal and vertical approaches. The more common (and not necessarily incorrect) approach is to slice a problem horizontally and build layers to a stack based on objectives with clear left and right parameters. This not meant to imply that there is a direct correlation between inefficient, services-based businesses and horizontal integration – indeed, many companies could (and do) achieve considerable efficiency through sophisticated slicing of problems and applying focus and discipline to a specific layer.
However, this scenario presupposes that horizontal slicing actually makes sense for the problem at hand. More often than not, this won’t work for truly world-changing problems – thorny, costly messes that have always defied incremental or partial solutions. For these kinds of problems, you generally need a vertical slicing methodology, wherein the problem writ large is solved end to end.
Complex problems are a lot like the classic peg-and-hammer game: knock one peg down and another one almost instantly pops up. Focusing on one problem may cause another one to become more pronounced, or it may result in an entirely new problem emerging (the law of unintended consequences). Once you begin to recognize that the underlying structure defies incremental approaches, the revolutionary no longer seems implausible – in fact, it often proves to be essential.
One aspect that makes vertical approaches so hard is the amount of abstraction required. Many business leaders pride themselves on seeing the bigger picture, but paradoxically, successful abstraction requires a concurrent grasp of concrete problems throughout the stack. You can code in Java or C, but if you want to truly push the boundaries of performance, you need to understand what the computer is doing at the CPU level. Conversely, nuts-and-bolts problem solving does not amount to a transformative business without some broader vision, and this requires abstraction. In the vertical methodology, there are two main tiers of abstraction: that required to solve a specific problem end to end, and that required to generalize this solution to whole classes of problems. Finally, it is worth noting that the abstraction challenge is equally crucial to management as well as technology, and morale tends to be worst when people can’t make meaningful abstractions – or feel they can’t.
Apple is a great example of the success of the vertical approach, not only for its mastery of end to end considerations, but for rethinking the whole model of personal computing – a deft blend of granular and abstract problem solving. In contrast to the Microsoft approach of focusing on operating systems and desktop software and letting hardware manufacturers fight it out, Apple chose to take responsibility for the entire experience, from the hardware to the user. This required not only solving all the normal granular problems associated with each layer of the hardware, OS, and software stacks, but actually creating a continuous whole. It’s about more than just a pleasing design – the idea that the user interface encompasses the device itself is central to Apple’s identity. For Apple, the medium is the message, in three dimensions. By slicing multiple user needs vertically, Apple ended up creating a whole new vertical, one it continues to dominate.
Where most companies saw problems they’d rather not touch, Apple saw opportunities – in device design, in platforms, and in challenging a monolithic company that conventional wisdom would suggest was unbeatable. For years, Microsoft succeeded because they had created the most effective walled garden. Although Apple’s OS had always had loyal adherents, Microsoft’s wall arguably started to erode with the introduction of the iMac and Macbook, which caused consumers to reconsider the fundamental relationship between form and function. With the creation of the iOS developer platform and app store, the walled garden concept was turned inside out. Yet I would argue that the platform, for all its merits, would have been exponentially less attractive if people were not already loyal to the device and the entire experience it represents – a shining validation of the power of vertical problem solving.
There is one quite interesting twist to all of the above: in the course of developing a vertical solution so you will actually develop strong intuition about how the problem can be sliced horizontally. This is the entropy of the human approach and the way we naturally organize to solve problems in teams – i.e. frontend and backend, to use a very broad example. Within each category, you can further refine the dynamics of the cross-functional teams that enable each horizontal slice.
As a final note, it’s worth mentioning that while the vertical approach at its most successful may create the impression of an all-encompassing technology, an end-to-end solution almost is achieved through scrupulous attention to each layer of the stack. However unified the whole may appear, the parts each play a discrete and necessary, not sufficient, role. Developing vertical solutions is not a matter of finding a silver bullet, but rather the most effective combinations and permutations of thousands of lead ones.
Craftsmanship 
One thought on “Vertical vs Horizontal Approaches”