The responsibility for client change

I came across this interesting comment the other day on LinkedIn and have been thinking about it long and hard.

ScrumMasters & Agile Coaches need this skill to have ANY chance of succeeding :
*To be able to INFLUENCE*

Jem D’jelal

Personally, I don’t agree with this comment – although I respect Jem and all credit to his post in getting me thinking about this topic.

I mean, and I’m only positing here, but I’m assuming the statement “ANY chance of succeeding” probably means delivering change for the client in a resistant environment, or perhaps not being personally held to account when the client’s wishes for change do not eventuate.

Written from the point of view of being a contractor in the above roles (which I have many years of experience with now), I actually feel there is something a little *perverse* about being brought in as an external Developer/Business Analyst/Project Manager/Scrum Master/Agile Coach etc – but then being asked or expected to influence the organisation to change or act and do things in a certain “new way”.

Isn’t it actually the client’s responsibility to take ownership and “influence themselves” into improving? 

I’ve experienced this a lot in my public sector roles and I am coming around to the idea that what’s usually going on is something more like organisational scapegoating or abdication of responsibility by management (although to be fair, it’s perhaps due to lack of organisation maturity regarding change which is causing these surface factors).

As an external, I arrive with a toolbox that has a lot of things in it to offer the client in satisfying their own needs, but my real deployment of influence is reserved for everything related to my own Ltd company, my own personal sphere of influence and personal well-being, and of course the shareholders of my company.

I do acknowledge a link between client “success” and revenue for my limited company however, but sometimes that is truly tenuous at best.

The Blinkered Engineer

Perhaps however, the kind of responsibility for change Jem is positing is at odds with how Engineers see and act in the world, and for other ‘kinds of people’, it is perfectly appropriate and reasonable to personally undertake influencing the client for their own good.

Have you heard about the 5 Colors of Change by Léon de Caluwé and Hans Vermaak? (source) It’s a framework that illustrates the different approaches to change that individuals take.

Colors of Change is also a way of understanding an individual’s style towards negotiation and change. Blueprint Thinking is typical for analysts, strategists, Engineers and project managers; they think first and then act according to a plan ie. following a rational process.

It’s fascinating seeing a change framework that explicitly outlines the strengths of a Blueprint Thinker, and reflecting on how these strengths can also become personal weaknesses if not recognised. They can also lead to misunderstandings with other team members who may not appreciate how Engineers see and approach change.

I believe the typical civil service way of influence and change is Yellowprint Thinking (bringing common interests together, participating in power game behaviour) which is most visible in public sector decision making from what I’ve seen. Compare that to the typical Business Analyst which follows something more like a Blueprint approach, which if true, automatically pits one against the other in natural style.

I recommend watching the other video clips in this series too, found here all Colors of Change YouTube clips.

Postscript

The Colors of Change rang a personal bell for me, having been brought into transformation programmes at an early stage and then finding myself needing to ‘convince’ other senior members of staff in the same organisation that the change was warranted and was what another part of the organisation was asking for.

As a Business Analyst, making that case through analysis alone was very hard and often not productive……. leaving me wondering what I was “doing wrong” and questioning my value.  All this was in a government setting before I knew much about the idea of Yellowprint Thinking – I’d be better equipped to handle this situation next time it comes along.

If you are unhappy with your development team, they may need more detailed guidance.

Better software requirements can help with this.