Managing ambiguity – an emergent skillset
Photos courtesy of Pexels.
For the past few weeks, I have been in conversations on critical emerging skill sets for different industries. The conversation has ranged from LinkedIn groups (especially Design Thinking), to long e-mail threads, to dips into Twitter and even Facebook. (I generally try to keep work out of my Facebook but sometimes things converge).
One fascinating conversation has been the role of ‘ambiguity’ in different professions. The comment that got us going was:
“Learning more about design for business analysts, engineers, and so on becomes very complicated and is sort of dangerous because of the comfort designers have with the concept of ambiguity, not knowing the answer at the inception of an inquiry. This is what made enemies, so to speak, of marketers, engineers, and other specialists with designers in the first place. Marketers, engineers, etc., look for answers in linear ways. They want solutions that are repeatable. Ambiguity and the ability to deal with it is an aspect of the education of a designer that has to be protected.”
This got me wondering if engineers would see things this way. I reached out to Dr. Philippe Kruchten, the mind behind the Rational Unified Process and a person who is thinking deeply about how to train the next generation of software engineers. He shared the following from a course he teaches of software architecture.
Skills of an architect
Architects must be capable of coping with ambiguities and contradictions
Most engineers are trained to eliminate ambiguities while an architect must move forward accepting ambiguities
Architects must be capable of managing multiple, concurrent issues
This skill is not part of standard engineering training
Architects must be able to rearrange priorities as situations change
So the design perspective and the software perspective are ‘kind of’ in agreement on ambiguity. Software architecture is as much a design discipline as an engineering discipline and in software architecture, as opposed to software engineering more broadly, the ability to manage ambiguity comes to the forefront.
I suspect this is true in all design roles, whether one is designing a building, a data collector for the Internet of Things, a subway system an on-line service, a pricing system or a revenue model. There will always be a level of ambiguity that needs to be preserved and managed.
Yes, you read that right, ‘the ambiguity needs to be preserved.’ That is my claim anyway. We need to design in ambiguity. We need to do this to give systems the latitude to change and evolve. The world is growing increasingly complex as we connect together more and more systems, suck in data, and use that data and analytics to reconfigure the systems in basic ways. We are getting a lot of emergent phenomena. We are getting used to being surprised. (Don’t believe me, look at the current US electoral cycle, where we have more data than ever before and have never had so many surprises.)
Volatility, Uncertainty, Complexity, Uncertainty. These four phenomena have become so common in business today that they even have their own acronym, VUCA. There is a good article on this by Nathan Bennett and G. James Lemoine in the January-February 2014 issue of Harvard Business Review, ‘What VUCA Means for You.’ They include a useful differentiation of these four terms, which are sometimes used interchangeably. Ambiguous situations are those about which we know relatively little and that are difficult to predict.
The great designers, product managers, systems engineers and business leaders of the future will excel at making decisions under uncertainty. All the data in the world will not remove that uncertainty; in many cases it will only increase it. So we also have to get better at designing solutions that embrace ambiguity rather than those optimized for some narrow set of assumptions about the future.
What skills are needed to manage ambiguity?
To answer this question I turned to the TeamFit skill graph. In this case though, I did not find any data. Most people do not think in terms of something as abstract as ‘managing ambiguity’ so I needed to go deeper. I did this by interviewing a few people in design, management on innovation and investment in innovation. Here are some of the themes I turned up.
Attitudes:
Humility (Open to being wrong)
Question Asking (To uncover the roots of the ambiguity)
Risk Taking (Willing to act despite the uncertainty)
Cognitive skills:
Root Cause Analysis
Probability
Weak Signal Detection
Frameworks:
Scenario Planning (Allows you to imagine and plan for more than one possible future)
Risk Management (Helps to plan for what might happen)
Design for Resilience
Once I had unpacked it to this level, I was able to find some of these skills in the TeamFit skill graph and to see the larger patterns of skills that they fit into. ‘Scenario Planning’ for example is associated with skills such as ‘Organizational Design,’ ‘Knowledge Management,’ ‘Story Telling’ and ‘Cajoling.’ Cajoling! I suppose a certain amount of cajoling is needed to successfully run a scenario-planning project. ‘Risk Management’ was most closely associated with ‘Project Management’ and ‘Budgeting’ but was also associated with ‘Knowledge Management.’
One of the places we are going with TeamFit is to be able to associate skills with roles. So if I am looking for a Project Manager who has to deal with a project where there is a lot of ambiguity I will know what skills and attitudes to look for. This is still a ways in the future, we need more data and our system needs to get smarter, but that is the direction we are going. Join us on this voyage of discovery!
The top image is from a wonderful article on grafting fruit trees on the Organic Gardening Resource Center.
Critical Skills
