A couple of weeks ago I attended the European Organisation Design Forum (EODF) in Vienna. The conference is attended by many of the global thought leaders, in what is a small but passionate field.
Although the community is focused on Organisation Design, my feeling is that a good 50% of what was presented and talked about was in fact Organisation Development. Many people believe Design falls within Development while others see them as fields that belong in fundamentally different parts of the organisation, i.e. Design should sit with the strategy function/COO while Development belongs with HR.
In discussing this topic with Mark LaScola (Mark, an American, runs one of the leading niche but very much global Organisation Design firms and has been an Organisation Design practitioner for 30+ years), his view is that Europeans are confused about the difference between the two ODs while Americans have a very clear sense of their separation. In Europe they are seen as similar fields, with Design being a subset of Development. The below Venn Diagrams depict these two world views:
So what is the difference? Does the difference matter and if it does matter, in what way?
I really like Naomi Stanford’s analogy:
“Organization design is deciding first what is the purpose of the car that you are about to design e.g. is it to cross the desert? Is it to win a Formula 1 race? Is it to transport two adults and three children to a party? Then designing and delivering a car that is fit for that purpose.
Organization development is about keeping that vehicle in the condition necessary to achieve the purpose e.g. using the right fuel, having it serviced regularly, teaching the driver how to drive it to maximize its performance, and so on.“
The organisation design definition does not mention people or behaviours, while the organisation development definitions are all about these. In that sense, Design comes first.
All too frequently the Design is done around the people, not around the strategic requirements. This leads to bad design, because in practice it is hard to differentiate the role from the person, as we are not just our perfect job specs. Having a purely engineering, mathematical perspective can lead to some pretty stupid people-related decisions. In so many ways structure, governance rules and interfaces have a dramatic impact on behaviour; defining who decides what has a pretty significant impact on how people act, who they need to influence and who needs to interact with whom.
So in my view, the two ODs can never be truly separated. Equally, I believe you have to start somewhere. So, start with what needs to happen – the ideal design for a given set of criteria – and then think through the impact. Think through whether too many trade-offs are being made and if the desired behavioural outcomes are going to be met. Think through ‘How Will it Work in Practice’ or the ‘HOWWIP’. Think through the risks and people trade-offs, iterate the design if needs be (and iteration will almost certainly be needed) until the optimal design is established.
The way of thinking through a design process is quite different to that of a development process. It is more physical. It is more concrete. It is more left brain. But, ignore development and almost certainly the whole design will come to catastrophic implosion under the weight of real politics with a small ‘p’. That means that those analytically driven souls like myself have to get to grips with a field that doesn’t come naturally. By the same token, however, those who come from the development side of the equation have to equally get to grips with the design field, and not just use the good old development tools & techniques as a way to fumble through.
Human skills, coaching skills, consulting skills can achieve amazing results, but there are some fundamental design techniques that need to be applied too. Design and development should team together, and to do so we still need a good appreciation of each other’s worlds.