How to win support and influence stakeholders

Getting support for new ideas can seem like an impossible task at times. It shouldn’t be like that though. In this post, I share the four questions I ask myself when I need to win support and influence stakeholders. The four questions I ask myself are:

• Am I solving a real problem?
• Have I done enough to truly believe in my idea?
• Do I have the evidence others need to support my idea?
• Have I proven it?

Am I solving a real problem?

First and foremost, your idea needs to solve a real problem. The bigger the problem is compared to the effort required to execute your idea, the more likely you are to get the buy in.

Don’t exaggerate the seriousness of the problem though. Exaggerating the scale of the issue to get support only ends one way, and that’s you looking bad. Instead, help your stakeholders understand the issue. Put into terms they can comprehend. Give them metrics. The better someone understands the problem you are trying to solve and why it needs solving, the more likely they will support your idea.

Have I done enough to truly believe in my idea?

This may seem obvious, but so often not truly believing in the idea is what causes it to be rejected. For me, there are two main parts to truly believing in the idea.

1. Being able to present it with genuine passion and excitement.
2. Having done enough investigation, research, or experimentation to have a solid case to be able to have faith in the viability of the idea.

Part 1 is really dependent on having done Part 2. If you have done the work to really prove to yourself that your idea is the solution to the problem you are describing, you should be excited to share that with others. You will also be well positioned to defend it when questioned.

Do I have the evidence others need to support my idea?

This should link the last two sections together. When proposing your idea you need to

• Sell the value of the idea – Is it going to save time? money? Both? Whatever your proposal is, it has some kind of value to someone. Share what that value is, and how it benefits the broader organisation.
• Acknowledge the risks and share how you will reduce them – Almost every piece of work carries some risk. Acknowledging them demonstrates how well thought out the proposal is, and having a plan in place to reduce the risk encourages confidence.
• Do the benefits outweigh the risk? – Something to consider from the point of view of others. Does the improvement offer more value than the potential risks detract? Can you reduce the risk further to improve the value to risk ratio?

Have I proven it?

Sometimes a high-level idea isn’t enough, no matter how detailed the plan. In these cases you need to prove it will work in order to get the support.

How you prove it will vary depending on the problem you are solving and the idea you have. However the most common ways of proving an idea are:

• Building a Proof Of Concept – Ideal when you are proposing a complex technical task, or one that will take a long time to implement. Building out a working example of your idea can help prove some of the value and increase support.
• Create a detailed experiment plan – Maybe there is no other way to prove it then trying it? For these cases, putting together a detailed experiment plan which focusses on minimising risk and measuring results is what is needed.
• Gather the data that backs it up – The data may already exist, in which case gathering it into a digestible format for the people need convincing is what is needed. If it doesn’t, then you may need to compose an experiment so that you can compare the before and after data.

Example

Lets say you are seeking support to create automated checks. You hope to ultimately replace the manual effort taken to conduct regression checks.

In this scenario lets say the manual regression checks take 2 people 2-3days to complete. You are also expected to conduct some checks in production following the deployment to ensure everything is working as expected. You believe that you can build out automated checks that will cover the key regressions checks in a fraction of the time taken to complete manual checks. Unfortunately the decision maker doesn’t believe they will be reliable enough or save as much time as you expect.

Getting support for a smaller project is the way to go here. Instead of trying to get support to build out automated checks that cover the full regression checks straight away, we should build a proof of concept. Focus on building out a small subset of automated checks. Maybe those that are done as part of confirming a production deployment succeeded, or the more time consuming manual checks. In taking this approach you can

• Demonstrate the reliability of the automated checks over a period of time.
• Prove that they catch any issues that are caught by manual checks.
• Show how much faster the automated checks are than manual checking.

Eventually you should have enough evidence to overcome the stakeholders previous objections, and in turn gain their support.

Summary

Hopefully this has helped you. For future just remember the 4 key questions:

• Are you solving a real problem?
• Have you done enough to truly believe in your solution to the problem?
• Do you have the evidence needed for others to support your idea?
• Have you proven it?

Further reading

If you enjoyed this post then you may also enjoy more of my Engineering Leadership posts.

If you haven’t already then I would also highly recommend having a read of How to win friends and influence people by Dale Carnegie. Or if audio books are more your thing, then its free on audible.

Subscribe to The Quality Duck

Did you know you can now subscribe to The Quality Duck? Never miss a post but getting them delivered direct to your mailbox whenever I create a new post. Don’t worry, you won’t get flooded with emails, I post at most once a week.