For many years, I’ve referenced a simple continuum that helps to describe the types of consulting that might be provided to a client, from Process consulting to Expert consulting.
At the Expert end, the consultant takes ownership of the problem and exerts their expertise; at the process end, the consultants’ expertise is helping the client help themselves. Somewhere in the middle is often called the Doctor/Patient model.
If we take healthcare as an example, we can see why. At the Process end is something like a Jungian therapist, who asks many open questions. At the Expert end is a surgeon who specialises in a particular part of the body and often has very little interaction with the patient other than in a very mechanical way. And in the middle is a GP.
I’ve recently been talking with colleagues about the extent to which dealing with ambiguity is part of the consulting skillset, and that got me wondering about the Expert/Process continuum. It feels to me like the closer your consulting needs are to the Expert end, the less ambiguous your situation:
You don’t get in front of a surgeon without your diagnosis being entirely well-defined. Your therapist never really comes to a diagnosis – it’s primarily up to you, and their model thrives in perpetual ambiguity.
What if we were to apply this approach to the world of software development?
There’s a similar focus on roles as one gets closer to expert consulting. If we take just three roles to illustrate, User Research is about exploring ambiguity. Product Management is perhaps the bridge between the ambiguous (what are the most critical needs, and translating those into things to be built) and Developers push us further towards certainty by translating those things into code.
Why is this important? Part of my recent conversation was about how there tends to be more ambiguity earlier in the engagement lifecycle, and we need consultants who are better motivated in those circumstances. This diagram makes me wonder if there is a naturally smaller proportion of people in certain roles who can thrive in ambiguous (or certain) scenarios because, for example, if you are a developer, that simply might not be something that you find intrinsically rewarding.
mmitII 