The wise Nigel Thurlow posted the following on LinkedIn –

A consultant should never implement solutions or attempt to fix anything. In most cases they’ll simply create thrash and often make things worse.
They should instead light the way and teach others to “learn to see”. Once others are able to see the consultant can guide them on contextually relevant tools, techniques, methods, and approaches.
Hint: you should be an expert generalist and possess deep knowledge beyond frameworks. People solve problems, not frameworks.
Teach others how to fish. Help them see and solve their own challenges. Trying to fix companies will only result in frustration for both sides.
Caveat: leaders (the ones with big job titles) must be engaged and participatory otherwise the best that can be hoped for is a short-term placebo effect.

When I last checked, it generated 67 comments. Instead of commenting on LinkedIn, I thought I’d briefly respond on the blog…

I found it quite interesting to go through the comments and look at the different views on the role of a consultant. There is rich discussion and varied perspectives that I think are valuable.

Why does it matter?

Glad you asked.

I think the discussion is valuable from an Agile Coaching perspective.

First, if I view agile coaching with the Agile Coaching Growth Wheel framework in mind, consulting and advising is a vital part of our coaching competencies. Having guidance around the stance can be valuable.

Second, the statement - A consultant should never implement solutions or attempt to fix anything.

Aligns incredibly nicely with your coaching mindset and ICF principles and ethics. Coaches often feel that “consulting” is the opposite of the coaching stance. But I think of them as blended and complimentary.

Wrapping Up

The more nuance we bring to the stances of agile coaching, the better. At least from my perspective.

One thing that Nigel didn’t explore in his brief post was the difference it makes to be an internal (employee) versus external (consultant, contractor) coaches. I explored this in in a prior article that you might want to read, along with an additional take by Joel Bancroft-Connors.

Stay agile my friends,

Bob.