Case study: How this expert managed a dominant non-technical stakeholder.

I recently worked with a software engineer, let’s call her Rachel, who worked for a large financial institution in the United Kingdom.

In our early conversations Rachel identified a key challenge she faced in executing her role effectively – getting a deep understanding of what key stakeholders were requiring her to build.

Rachel told me that stakeholders would routinely provide a brief that told her what they wanted and how she should design it, but very often, when she followed this brief to the letter, the business stakeholder came back with many revisions, and sometimes direct feedback that what Rachel had delivered “didn’t meet the brief.”

This often led to rework for Rachel, delayed other important project work, and created tension in the relationship. It also negatively affected the organisation, as no enterprise wants productivity delays or frustrated key employees.

In my experience, Rachel’s situation is quite typical. Many experts find it hard to persuade key stakeholders that investing time to fully understand their needs ultimately saves time and leads to better outcomes for the business.

Rachel’s stakeholder was a senior executive who was time poor, thought they knew best, and that Rachel was just there to serve, rather than partner. Rachel wasn’t even sure that the stakeholder, let’s call them Adam, was aware of her capabilities or indeed her impressive professional track record.

In our discussions:

• we helped Rachel put herself into her stakeholders’ shoes, exploring what might be driving the behaviors that Rachel was finding so difficult to deal with.

• We also discussed some key content from the Mastering Expertship program.

• We talked about Rachel deploying the consulting model and associated gain/pain questions more effectively (we call this capability “Solutioning”).

• We also explored whether having a reset meeting with the stakeholder, deploying the Stakeholder Health Check, might be valuable (this tool is part of the capability we call Stakeholder Engagement).

• Finally, we discussed how Rachel might “sell” a meeting to the stakeholder, deploying advanced influence techniques and great storytelling (this capability we call Personal Impact).

In subsequent coaching sessions, Rachel reported that the reset discussion with the stakeholder had gone well. Rachel had piloted a new process where she asked lots of discovery questions which elevated her design, streamlined the development process, and ended up saving both Rachel and Adam time and effort.

Rachel is now exploring similar conversations with other key stakeholders. And she reported these conversations were easier, because she had the example of her work with Adam to draw upon. Both Rachel and her organisation is benefiting from the higher value work Rachel is able to deliver, faster.

As with many of our coaching conversations with technical experts, it wasn’t their technical prowess that was causing the problem, but their non-application of advanced enterprise skills. This is what the exploration of Expertship is all about.

Read more about our programs and publications at www.expertship.com.