5 min read

How-to convince colleagues to accept new processes

How-to convince colleagues to accept new processes

Let me share with you a technique taught to me that I've used and refined, it's always had an impact that can help convince even the most remiss, ignorant, or doubtful opposition to a well argued and rationalised new process.

More than 10yrs ago when I was in my 20s I already had several years experience and was being groomed to be a leader. At 23 I was supervising teams on the floor of exhibitions and events, organising hundreds of exhibitors, freight transports, all the logistics of a show the size of Australia's Avalon Air Show (yes the one with tanks, and crazy red bull plane demonstrations). Most of the time I'd be working on at least 5 (and up to 20) events simultaneously.
Obviously that sounds incredibly difficult, but that was the job and there isn't much more than the organisation and interpersonal skills needed. So my mentors helped me through this teaching me the skills they've used for decades, one particular lesson was where my technique came from, and it was simple;

  1. Give the subject some seemingly arbitrary information upfront
  2. Discuss some merits
  3. Ask questions you asked during your own journey to learn your conclusion (yet to be delivered)
  4. Deliver your ultimate message

Now let's dig deeper into this;

  1. Give the subject some seemingly arbitrary information upfront but do not dwell on it. It is key to delivering your desired message and you want it in their subconscious early but not be over bearing.
  2. Discuss some merits and try be extremely open to all arguments they present but be cautious to avoid any deep discussion on them. You've spent more time on this then most and have done you're own assessments on all these arguments. So although you have justified responses now do not indulge these arguments yet.
  3. Your desired message is likely to be one that anybody can conclude given they had asked the same questions and followed similar investigations to your own, so be sure to lead your audience along your journey by presenting them simple questions in a well thought out order.
  4. The delivery of your ultimate message, the one you desire your reluctant audience to accept, should feel as though it was their idea and the most natural conclusion. In reality they simply took a condensed version of the same path you took to get to your conclusion.

Today however, I do not follow this strategy. Though mostly effective it is actually very hard to go against my nature until the end. I intrinsically aim to share my knowledge which makes me susceptible to debate or give in to argument before realising my audience/adversary is not yet open or ready to accept the information being delivered.

Also I find the above technique to be border-line manipulative and that doesn't sit right with me.

The lessons in that method are people need to not just be told answers they need a realisation moment. My mentor always suggested the answers should come to them as though they had though of it, but i disagree. People are more mature I find, and you can still deliver the idea to them so long as you ensure you've delivered that moment of realisation prior. This is very important.

So here is an example of how I deliver realisation.

Hypothetically you are a new coder in a large organisation where there are a lot of more senior coders, architects, managers, and all the diverse rolls of a software development focused organisation. You learn that all code is stored in shared networked file server (ahem Dropbox) and you are horrified.
Instead of running screaming like a sane person, you were looking forward to working with these great people on a bleeding edge code base so you stay.

Your first attempts to propose source control (git to the rescue, yes this is only in last decade) was met with sarcasm and dismissive jest, how could you possibly know how to manage such a large foreign code base as a young newcomer?
One day you intend to be a consultant that works on new and exciting technologies with many companies so if you can't convince this one team to adopt a superior technology that will save them time, effort, and money - then how will you ever reach your goals?

This scenario is to establish a once common situation which we now deem a novel decision on any new project.

Taking for granted today's development environment, source control enables you to do a lot of other related things that were impossible or very hard to do prior. Consider;

  • New starters setting up a development environment
  • Switching between multiple development environments
  • Software configuration
  • Concurrent incompatible development
  • Having the same state of code everywhere
  • Being able to view past states of code

Lets just focus on the key topics you need to communicate;

  • What problem does this solve
  • Time and cost, both savings and loss when switching

It's not always clear but you should always cover all pro's as a single idea, it is the desired message you'll want to deliver. This case it is Change and release management that is the problem you are solving and it so happens to sum up all the pro's above as well. Be sure to prepare appropriate time and cost analysis associated but hold it back until after you've delivered the main message.

Let's focus on the realisation moment now.

Assuming you secured a short time-slot to deliver your proposal, everyone is in the room and before you start you instruct everyone to;

  1. Write on the paper you provided 6 four digit number and their own name below the numbers
  2. Ensure that they have personal meaning to you, because you should memorise them all.
  3. Swap paper with someone so that everyone has someone else's 6 numbers
  4. Read all 6 numbers, strike out 2 of the 6 numbers, and write your name on the back, and hand in to you (the presenter)

You go on to present the proposal and make no mention of the exercise.

At the end you randomly choose a paper, ask the named person from the back of the paper to recall the 4 numbers they did not strike out. It is most likely they remember only the ones they had striked-out, and if they can recall all you'll have to start again with someone new because you likely chose someone who has a photographic memory!
Now ask the person who decided the numbers to recall them all, they likely recall each one perfectly because they have special meaning.

This exercise is designed to demonstrate;

  • A six step simple release plan
  • The person who decided the numbers know the plan well, they designed it!
  • When someone gets new information it is extremely hard to instantly relate to all of it at once so you focus on certain details that allow you to relate this new information to your current knowledge. Striking out 2 numbers demonstrates this
  • The time period between the exercise and the test is filled with new information (your presentation) which demonstrates BAU in a workplace

All 6 steps are crucial, and without proper change and release management things break down fast.

No one has perfect memory recall for long periods of time not spent recalling the information, so for accuracy and consistency sake we should have systems and process in place to do the accurate memory recall for us.

You've demonstrated a simple analogy that everyone can relate to with your exercise which engaged and hopefully impacts the audience in preparation for you to deliver the desired message.

How could they now deny the benefits!?