Thinking horizontally in a vertically-oriented world

Jim Womack’s keynote at the LPPDE14 conference in Durham nicely captures one of the key problems faced in Product Development:

Most organizations are organized vertically […] but the product needs to flow horizontally across the organization in order to be made right/well and solve a real problem for the customer. Every time the vertical and horizontal structures intersect, as an engineer or developer, you’ve got two bosses. The challenge is how to think horizontally in a vertical world.

Sadly, I see little evidence of this horizontal thinking taking root yet. People inside the system find it very difficult to break out of the vertically aligned organisation to really see how the work flows. Even those that do, rarely see it from end-to-end – they still tend to see product development as serving internal stakeholders and don’t look far enough upstream to where ideas come from – and that demand and supply will never be in balance.

It’s also far more likely that information flows are vertically aligned as well. We even use the metaphor “cascade” to describe the top-to-bottom method of spreading information and creating “alignment”. (As an aside: perhaps this is also where Product Development is different to even the most agile military approaches. How much information transfer is required between adjacent cells and from one point in time to another seems different to me).

Womack goes on to explain how Toyota solved it:

The way Toyota did this, he says – not that we can all be Toyota, nor should be – is to have a chief engineer. The chief engineer is the person responsible for “surfacing contradictions within the organization” and “getting a conversation going about what the right thing to do is for the customer and the company.”


The idea at Toyota was/is this: your chief engineer helps different parts of the organization work together, makes things “whole”. The question for developers at organizations without this role – how can you be more effective in creating some sort of chief engineer function?

So if the point of Toyota’s chief engineer is to “surface contradictions”, maybe there’s another way to do this? What form do these contradictions take? Trade-offs seem an obvious candidate. Trade-offs between time, cost, value (and the optionality within the latter two). Maybe we need an economic framework to help deal with these contradictions and make better trade-off decisions??

And perhaps we can go beyond Toyota (surely it’s time?). Maybe we could do this without the chief engineer through which Toyota orchestrated all these decisions? Replacing many vertical orientations with a single vertical authority doesn’t sound like a solution to the need for horizontal orientation. Perhaps we can instead quickly disseminate the information all of the various horizontal actors in the system need to be both better aligned and less likely to contradict?

In the software world, we’ve used “Product Owners” where Toyota used a Chief Engineer. But how is that working out for us? It may have massively simplified the interface to the development team, but I’ve seen far too many Product Owners who are left to struggle with a set of stakeholders who want it all, want it yesterday and have conflicting priorities and desires. Many of the conflict and contradictions arise because we’re making different assumptions about where the value lies and the urgency – with the thousands of trade-offs between different aspects of value and time.

Perhaps one way of quickly disseminating the necessary information required to make good trade-off decisions and avoiding contradictions is to gain a shared understanding of the Cost of Delay. Perhaps doing so would change the role of the Chief Engineer and Product Owner from one that makes decisions, to one that facilitates the ability for everyone to make better decisions faster. Doing so also helps to decouple the parts and allows many more paths to be quickly explored by the people who best understand those trade-offs. Deferring this to an omniscient “chief” who looks after the horizontal despite all of the vertical organisation has become more difficult in our increasingly complex and fast moving world.

Now wouldn’t that be cool?

Comments 2

  1. Strange that your site should have parts of the Amazon shareholder letter about innovation, and this article. It’s almost like there are writers with horizontal and vertical views and they’re not seeing the big picture.

    Disruption in IT, at the moment, appears to be about providing simpler and more efficient vertical solutions. So collaboration tools, like Slack, are disrupting horizontal tools like Skype, Dropbox etc. I suspect this article is more from the point of view of user organisations. Isn’t every company going to become an IT company though? Won’t car companies become verticals like Tesla, instead of horizontals like GM?

    All in all, a good set of articles and a good site. Portent of the future direction of agile business development. Stick to your guns though, incremental is not innovation.

    1. Post

      Hi Mel, thanks for reading and taking the time to comment.

      Perhaps you may be thinking about a different definition of “horizontal” to the one I am talking about. The horizontal that this article discusses is about the value stream: how work and information flows within an organisation. This has nothing to do with whether a company is “vertically integrated” or not. The verticals I am talking about are the departments or divisions of a company, which often become silos of information and queues form between parts of the system as they tend to optimise for local needs rather than what makes sense from a global, end-to-end perspective.

      Also not sure what you mean by “incremental is not innovation”?

Leave a Reply

Your email address will not be published. Required fields are marked *