Influencing

A key skill when working with others is being able to influence positively.

Some of the most difficult challenges many of us face involve the need to influence others we have no direct control over. These may be colleagues from your own organisation, customers or external stakeholders, or those from other organisations. They may have more positional authority than us and may not immediately understand the reasoning behind our thinking.

Here are some tips for dealing with these situations:

1. Focus on the right people. It is important to earn trust and support from direct colleagues, but it is equally important to recognise when this is not enough. Sometimes you need to also win the support of leaders and influencers in the organisation — the people others look to for backing or permission.
2. Use the GROW model to clarify your thinking about what you want to achieve.
3. Understand what motivates those you need to influence.
   • They may be interested in things like wanting to reduce costs, deliver faster or reduce perceived risks.
   • They may have a very different perspective to you and it's important not to dismiss their thinking because it seems unfamiliar or at odds with your understanding. Actively listen to what they say and empathise with their point of view.
   • A technique which can help with this is to try to judge the person's DiSC profile — see DiSC Personality Types and DiSC styles.
4. Understand their situation.
   • Sometimes it can be hard to understand the logic behind people's objectives or decisions, and they can hold beliefs which, on the face of it, don't appear to add up to common sense. Always be aware that people have to operate in complex, sometimes hidden environments with their own players, driving forces, and obscure objectives.
   • People often have to implement things that they don't 100% believe or back for a myriad of tricky political reasons. Don't judge them; instead, advise them and try to understand the world in which they operate. Always try to provide solutions that are sensitive to their constraints. Sometimes stakeholders can't do the 'right' thing, they have to do the best they can — so you telling them that they are doing it wrong isn't helpful.
5. Explain the problem you observe in terms which will resonate with others. For example, "Our mounting technical debt is meaning that features are taking longer to develop, work is harder to estimate, we have an increased risk of bugs which would cause incidents, and incident resolution is slower"
   • Try to be objective. This will strengthen your case, and is a good way to validate your thinking. Sometimes when cast in these terms you realise that things aren't as much of a priority as you thought.
   • Use facts and metrics to evidence your claims, even if these facts and figures are basic, and of low accuracy.
   • Consider using examples as well as facts and metrics, as they make things more tangible. For example, "Have you considered doing X? I've seen something similar before and by doing X we were able to unlock Y and Z. I wonder if that type of approach might help in this scenario."
   • Talk about what is good as well as problems. This helps reinforce positive behaviours and avoids appearing overly negative.
   • Attribute successes to individuals, but when talking about problems do not mention individuals to avoid appearing to be apportioning blame. Talk in terms of the shared perception of the problem. For example, "We are seeing that it is hard to make changes safely due to accidental complexity in the code" rather than "the old team left us with a lot of poor quality code."
6. Explain your options and the degree to which they will address the problems. Focus on the benefits which will be gained. Be forward-looking rather than dwelling on issues from the past, and concentrate on the ways in which things will be better. For example, "By spending a little time now to make the code more consistent and easier to test we will be able to deliver faster in the mid and long term."
   • Think about how to break changes down so that they can be made incrementally, reducing risk and fear of change.
7. Make a clear proposal. Find ways to explain changes which do not criticise the current situation or decisions made in the past. Use "we" to avoid suggestion of blame. For example, "what we were doing made sense at the time, but we can see it is no longer working." Lead others to conclusions using coaching and insightful questioning rather than just presenting them with answers; let them feel they are part of the thought process. Aim to get people's buy-in and for them to identify with the proposal. It's great if they are happy to champion an idea we helped develop. We do not seek credit or recognition — we are focused on outcomes, not how we get there.
8. Consider what format to use, including whether to interact individually or in group settings.
   • If arranging group sessions, seed ideas individually with key people beforehand so that they are mentally prepared before the session starts and know what to expect.
   • With those who are neutral or positive, you are seeking to build support so that they will be allies in the group session.
   • With possible detractors, it is best if they can have their say before the group session so you can either modify the proposal or explain the thinking and build mutual understanding.
   • You may also consider sharing a written proposal ahead of individual or group sessions to give individuals time to digest and consider the proposals.
9. Make the change feel safe. Suggest the change as an experiment to reduce its perceived magnitude. Where possible, describe it as building on something which is already in place.
10. Avoid triggers. If certain words or phrases have taken on negative connotations or confused meanings for others, use different words. For example, it is more productive to suggest specific ways to enhance collaboration than to tell people to adopt DevOps if they don't like that word for some reason — or to tell them they are not doing DevOps right if they feel they have already fully adopted DevOps.
11. Put your money where your mouth is. Part of proposing solutions is being willing to get stuck in and help implement those solutions. Always be ready to offer that help, not being pushy, but being ready to roll up your sleeves and demonstrate what you mean practically if asked to do so.