How do you make those darn code monkeys do what you want? Just give 'em a little nudge

SHOCK NEWS: Positive reinforcement gets results

Nudge theory – brainchild of Richard Thaler, a professor of behavioural science and economics at the University of Chicago – uses positive reinforcement and indirect suggestion to influence behaviour.

For example, in a supermarket or canteen placing healthy food on display at eye level rather than banning sales of junk food. Ensuring litter bins are available accompanied by adequate signs rather than imposing on-the-spot fines. It was seized upon by politicians, including former Brit PM David Cameron.

The theory, as articulated by Thaler in his book with Professor Cass Sunstein Nudge: Improving Decision about Heath, Wealth and Happiness, is now 10 years old.

Cameron is gone, a decade has past and Thaler was last year awarded a Nobel prize for economics. So why should we care? Proponents say there is much to be gained by applying its principles to DevOps.

As you've no doubt heard, DevOps is not about technology, it's about people and practices.

DevOps at its core is about empowering individuals so they are no longer just churning out code to deadline or for a bonus but, rather, participate in the ops side and therefore think about the long term. The cultural challenges of this shift are not to be underestimated.

Aligning the autonomy of individuals with the bigger goals of business is tricky, and this is where behavioural science comes in. No matter how empowered teams are, they're not always inclined to worry about support and optimising application performance.

Rather than hope for the best and prepare for the worst, the idea is that applying Nudge theory can encourage engineers into making better choices for themselves, their colleagues, and the business.

Sarah Wells, principal engineer and platform tech lead at the Financial Times, is a passionate advocate and has been banging the drum for Nudge at various DevOps-themed events.

Her employer moved to DevOps around three years ago and talking to The Reg she explained how the FT's coders were persuaded to change their ways and to start thinking bigger picture and operations.

"We started asking developers to think about things like monitoring and resilience. It's hard to tell a team that they may be woken up at 2am if it breaks. You have to give your teams a level of power to take decisions. So instead you have to think about what you can do to influence their behaviour."

The idea is you change the "choice architecture" – how people arrive at decisions. But how do that on a day to day and systematic way?

Welcome to EAST – Easy, Attractive, Social, Timely.

This is a philosophy developed by the Behavioural Insights team – a social purpose company jointly owned by the UK government, innovation charity Nesta and its employees. Why the government, of all people? The unit was created in 2009 as a way to alter the behaviour of the Great British public into ways that would have them follow the law. It came to the fore during those long-forgotten early David Cameron days.

BI lists among its customers a raft of Whitehall departments, local authorities and other UK state agencies.

While Whitehall might have it's own peculiar and particular problems when it comes to IT in general, the ideas of a EAST can – and have – been applied to DevOps.

Each element of EAST can be applied to software development to more effectively influence teams to do the things you care about as a company.

Easy

If you want someone to do something, you should make it easy: both to understand what the benefit is and to take the appropriate action. Clear, simple messages, and a good choice of defaults go a long way.

"It's about saying to people if you choose this database, we've made it easy for you to use. And that makes a difference because nobody wants to spend their time doing functional stuff," Wells says.

At the FT, making stuff "easy" includes supplying checklists, APIs, example code and libraries. Similarly it's about allowing people to try your stuff out without having to wait for someone to allocate a key or set up a user account. And be customer focused – make sure people know who to contact, she adds.

Nudging developers to do the right thing when it comes to performance and support has to be easy. This means serving performance insights immediately and in context of their daily work. Information should be presented as they perform that build, together with granular insights into which application and infrastructure changes are causing problems.

According to Christian Owens, founder and CEO of developer tools startup Paddle, dashboards of "contextually relevant" information help focus minds on key metrics before they become a problem.

"It's about being more proactive about picking up on early warning signs that a problem may happen. And if something does happen, people are very responsive and reactive to it," Owens says. "It makes it easy to think about things upfront because you're not fire-fighting." Bear in mind too that not everything has to be an alert. "Passive access to information can be just as valuable."

Michael James, head of technical architecture at Altus Consulting, says gamifying development can help inject a sense of competition into processes and nudge engineers to achieve higher "scores" across important metrics, like fix rates or even pain-free gambling to get teams to estimate how long, how much. "Generally people have a good gut feel," says James.

Attractive

According to the Nudge unit, we are more likely to do something that our attention is drawn towards. This holds true for developers, but very hard to achieve with traditional performance monitoring tools – especially those that flood them with email alerts, false positives and noise.

There are two senses in which you need to make something attractive: firstly, attract people's attention so they know what you are asking them to do. Then you need to explain why they should want to do this.

"You want people to understand this possibility is here and to make it attractive," Wells says. The FT uses Slack, email and even posters – the important thing is to find people in the channels they're in. "And talk about it until you're sick of it. Make it attractive by writing example code. Make it cool," Wells adds.

Social

Too often teams operate in silos. IT leaders can foster networks to encourage highly collaborative behaviours to spread across the organisation.

This could be as basic as systems administrators attending agile stand-up meetings, but tools can help too. For example, providing a single collaboration app that integrates all architecture issues and metrics so cross-functional teams have one point to react, decide and solve problems – collectively.

"In software development, we can show how other people are doing: for example, wherever possible we want our teams at the FT to migrate to Amazon Linux, because it saves us money – and we have a website that shows each team how much they would save," Wells says.

"We also encourage people to talk about things that have worked for them, in lightning talks or blog posts. When we share information we can show how easy it is to do something and show what people can gain from it."

At enterprise cloud management vendor SignalFix that has translated into short, regular meetings that give people a voice and let them to talk about their work in an informal way. CTO Arijit Mukherji told The Reg: "It's about nurturing with an environment where people help each other and recognise each other's achievements."

Team structure and individual roles play an essential part in all of this motivational stuff. "We don't have specific DevOps engineers," Owens says. "We have one platform engineer for each engineering team, typically or around six to eight people. They are responsible for guiding the team and helping to train team members. We don't want engineers not to think about the wider platform implications of what they're building."

James warns of the dangers of allocating what might be regarded as outdated or highly specific job titles. "I made the mistake of introducing someone as a lead programmer into a team and the backlash was incredible."

Timely

Timeliness is important in the world of Nudge. Getting somebody to do something usually depends on when during the work cycle they are introduced to the idea – not necessarily on level of remuneration.

The FT employs an engineering checklist that covers what the teams are expected to do. For each item, there are links to documentation, libraries, code examples etc. When teams need to get something done, they're given all the relevant information right then and there. Having a checklist also makes it easy to do the right thing, and applies some social pressure on teams to do what the other teams are also doing, so it works across several of the levers.

These are not the only factors that can be used to create a culture of influence.

Puppet reckons you can improve the performance of software development teams through a combination of smaller units of work, higher visibility of work and building collaboration into processes.

Exposing engineers to customer feedback helps them to see the bigger picture – feel pride in their achievements or learn from things that don't work so well. The shift from a waterfall methodology to DevOps at Compuware wasn't without its challenges but David Rizzo, vice president of product development, highlights celebrating success as a key motivator.

"We do virtual town hall meetings every two weeks and everyone contributes. We also have a celebration party every quarter and that has gone a long way to getting people motivated. It's about understanding the connection between what we do and the benefits to customers," Rizzo says.

Ultimately, the secret of Nudge is treating the members of teams as individuals – something that's easily forgotten in big development shops when the pressure is on. "People want to be seen to have a positive impact on things with you as a conduit into the bigger governance picture. The trick is to be inclusive," James says. "Nudge is common sense and not treating people like it's a factory – that motivates no one." ®

We'll be covering DevOps at our Continuous Lifecycle London 2018 event. Full details right here.