How to sell Continuous Delivery to the more resistant people at your organization

by  on  in Tutorials

Well that was nerve-racking. I’m on the train home from the first ever Pipeline conference. It was great and everyone who works with code in London should join ‘London Continuous Delivery’ here.

During the day I lead an OpenSpace discussion on how continuous delivery principles can be applied to databases. At the end of the day I half volunteered and was half press-ganged into joining the ‘panel’ in a Q and A session with about 100 delegates. I was sat in a row with Tomas Riha (@TomasRihaSE), the tech lead for Volvo’s WirelessCar, Phil Wills (@philwills), senior software architect at the Guardian, Stephen Thair (@TheOpsMgr) of DevOps guys and crushed against me on my left shoulder (the chairs were far too close together) was Dave Farley himself (@davefarley77), the co-author of Continuous Delivery, the book which everyone at this conference calls ‘the bible’. It’s fair to say – I felt a little intimidated.

PipelinePanel

And then someone asked:

“I really want to adopt continuous delivery at my company but I am facing resistance. How do I sell CD to people at my org in other functional teams?”

This question I can answer. I’ve been doing this for three and a half years. Here is my ‘sales 101’ crash course.

Step 1 – rapport

Right, let’s start at the beginning. People don’t buy from people they don’t respect, like and trust. The first thing you need to do is get to know your colleagues. You also want to think about which colleagues are influential. (Note that is different from which colleagues are the most senior.) If you are working in separate teams, responsible for different bits of the pipeline it is your responsibility just as much as it is theirs to start working together. Also, the fact that you aren’t working together at the moment is just as much your fault as it is theirs. Remember, many DBAs and software developers didn’t get their jobs for their social skills but no-one is perfect and they almost certainly know something you don’t. Be humble. Be polite. Ask how their daughter’s nativity show went or if they enjoyed their live-action Dungeons and Dragons weekend. Remember their birthday (I’m serious – don’t underestimate how powerful this can be). The best teams I have worked with have enjoyed each other’s company.

For the purposes of this post our DBA is a lady called Susie because there aren’t anywhere near enough female DBAs. (Is it bad that I jumped to the natural assumption that the person blocking CD might be the DBA?) You need to tell Susie that you want to reduce the amount of time she has to spend reviewing your changes. You are going to give her access to your source code (you might need to teach her what source control is) and you are going to pair with her. (Be humble – she knows more about T-SQL than you. You will probably learn something). You will show an eagerness to learn from her.

Step 2 – objections and drivers

As you get to know your colleagues you will get to understand them better. You will understand their reasoning better and see why they may object to your proposals. It is amazing what a difference it makes to see something with your own eyes. Get them to show you their database monitoring tool so you can see the red flags when you make a mistake. You might begin to see where they are coming from and why they feel the way they do – and they might have a point in some cases. You will also be better placed to explain to them your way of thinking and you know what… you might find a good compromise.

Also learn what motivates your DBA or business manager (is it bad that the next assumption I jumped to is that if it isn’t the DBA, it is the non-technical business manager?) and this might not be what you expect. I can guarantee that releasing every day is not their driver. Nor is investing in time so that the developers can implement their new ‘best practice’ which they don’t understand. Their drivers might be to protect the data, to enjoy their work, to be the best or to make money. Then again – it is probably something totally different.

Step 3 – features and benefits

When you have a good relationship with the blocker at your organization and you understand what they actually care about you are ready to start a conversation about CD… But hold your horses. If you show them a slide like this they will run a mile:


Why would they run a mile at this? Because this slide is full of features – not benefits.

Think about Susie who only cares about performance tuning and protecting the data from them pesky developers. “Automate everything”? “If it hurts, do it more often”? “Keep everything under version control”? How do these help her?

Think about Jason (I just decided my non-technical business ‘product guy’ is called Jason). Why does he care about “Building quality in”? As long as it looks like a Porsche and it sells like a Porsche why does he care that it is a Skoda under the hood? “Repeatable process”, does he even know why this is important?

There are very real benefits to CD for both Susie and Jason. I know this, you know this. The feature is that you release frequently, the consequence is that you reduce failed deployments (still just a feature). The benefits are:

  • Susie saves time, Jason gets his product to market quicker
  • Jason is richer, Susie gets on board with a great process that is good for her career
  • Jason, the ‘product guy’, has more feedback from customers so he can make better decisions
  • Susie has more time to spend performance tuning or working with the dev team

All you need to do now is match the benefits of CD with Susie and Jasons’ drivers and the implementation (the features) become the details. Good luck!

A final note

I’ll leave you with one piece of advice. Big changes can have a way of getting peoples backs up if they aren’t handled well. People need to be included and given new toys to play with to make their job easier, as opposed to a new process they don’t have any say in being dictated at them. If you approach this badly you will end up making the walls between functional groups bigger, not tearing them down. People like to be persuaded – they don’t like to be beaten.

And one more final note

Re-engineering both code and people for CD takes a long time – be patient. However, unfortunately some people won’t change. You cannot win them all. Try hard but learn when to cut your losses and turn your attention to polishing up your CV and LinkedIn profile. At the conference it sounded like lots of great companies who love CD are hiring. I know we are. And if you are the sort of person who makes an effort to improve things, even when that is hard, then you sound exactly like the sort of person that a good company will want to hire. 🙂

http://www.red-gate.com/our-company/careers/current-opportunities/

 

 

EDIT: They just posted a video of the panel discussion

If you want to hear what the other people on the panel thought, fast forward to 19 minutes in:

PIPELINE Conference 2014 – Panel discussion on Continuous Delivery from Software Engineering Practice on Vimeo.

Leave a Reply

Your email address will not be published.