Determining Sources of Complexity
In management it is important to distinguish among sources of complexity to determine what is possible and desirable to simplify.
Julian Birkinshaw and Suzanne Haywood (reference below) argue that not all complexity is bad, but managers don’t always know what kind their organization has. They start with the distinction between:
- Institutional complexity – such as the number of organizational units or lines of business
- Individual complexity – the complexities faced by individuals in the organization, such as poor processes, confusing role definitions, or unclear accountabilities.
They found through survey research that most people in the organization do not care about institutional complexity but they struggled with forms of individual complexity such as processes that had initially been effective but over time become increasingly bureaucratic.
Birkinshaw and Haywood suggest that it is important to distinguish between:
- Imposed complexity – laws, industry regulations, and interventions by nongovernmental organizations. It is not typically manageable by companies.
- Inherent complexity – intrinsic to the business, and can only be jettisoned by exiting a portion of the business.
- Designed complexity – results from choices about where the business operates, what it sells, to whom, and how. Companies can remove it, but this could mean simplifying valuable wrinkles in their business model.
- Unnecessary complexity – arises from growing misalignment between the needs of the organization and the processes supporting it. It is easily managed once identified.
Roger Martin, in two HBR posts on Self-Inflicted Complexity (references below), uses Peter Senge’s distinction between:
- Detail complexity – driven by the number of variables
- Dynamic complexity – situations where cause and effect are subtle and where the effects over time of interventions are not obvious
and introduces the problem of:
- Inter-domain complexity – resulting from attacking dynamic complexity by minimizing detail complexity, and thus dividing the world into numerous deep knowledge domains.
According to Martin:
“Inter-domain complexity challenges us whenever a hospital patient has co-morbidities (heart and liver problems for example), or a business problem spans marketing and finance, or a political problem bridges foreign relations and domestic economics. The specialists who focus on heart, liver, marketing, finance, foreign relations, and domestic economy frame the problems using their tools, models, and language systems because that is what they know and that is where their confidence lies. It is hard for them to un-frame what they have framed or un-see what they see.
“It is not impossible. It is just hard. Typically, every bit of their formal and informal education has taught them to sacrifice detail complexity – to narrow problems to facilitate analyzing them. They don’t actually know how to take two opposing frames, models, and diagnoses, and do something useful with them. In fact, the more expert they are, the less likely they are to ever have done so – even once in their life. So they stick assiduously to something at which they are terrifically good: being narrow, and confidently so.”
Julian Birkinshaw and Suzanne Heywood (2010), Putting organizational complexity in its place, McKinsey & Company, May 2010, at http://www.mckinsey.com/business-functions/organization/our-insights/putting-organizational-complexity-in-its-place, accessed 27 February 2016.
Roger Martin (2013), Our Self-Inflicted Complexity, Harvard Business Review, 6 September 2013, at https://hbr.org/2013/09/our-self-inflicted-complexity, accessed 27 February 2016.
Roger Martin (2013), The Cure for Self-Inflicted Complexity, Harvard Business Review, 4 October 2013, at https://hbr.org/2013/10/the-cure-for-self-inflicted-complexity, accessed 27 February 2016.
Atlas topic and subject
Page created by: Ian Clark, last modified on 29 February 2016.
Image: Brian Castellani, Complexity Art, at http://sacswebsite.blogspot.ca/2012/10/complexity-art-latour-global.html, accessed 29 February 2016.