From DevOps to a DevOps Culture

If your organisation is more than five years old, chances are you are familiar with the pain of the monumental shift of your legacy stack towards small, more deployable software, running on cloud infrastructure. Oh, how we all envy the start up! We worked hard to get there, but where has this left us?

Our teams ship software daily and work autonomously but is that enough to claim we are high performing? In this session we will talking about taking stock when the dust settles, and what you can do to help your team build a strong culture in a DevOps world.

Alternative title: How CD killed my culture

In the early days of Michelle’s career deployment involved floppy disks literally going from workstations to on-premises servers… and it never really seemed to work, it’d be all-hands heroics, pizza, beer, and thank yous at the all-staff meeting every other launch.

Going forwards a few years, to monoliths in data centres. Now you have to go through a bunch of forms, send them off to a third party and cross your fingers that everything worked as intended. And it never did. So it would be all-hands heroics and thank-you lunches again…

Then the cloud came along and everyone tried to lift and shift, which didn’t work so well and led to creation of microservices and SPAs. Lots of learning required to figure out how it all worked. Lots of heroics and celebrations again…

Now we have CI/CD solutions that mean people don’t have to come together to figure things out any more. This has created siloed teams and individual contributors sitting around with their headphones on all day. People can get along on their own so much that they aren’t practised at banding together.

We have evolved to belong in tribes. When we don’t feel connected and share a purpose with our team, motivation drops.

Who is on a team matters less than how team members interact, structure their work and view their contributions. – Google 2015


Without moments of adversity to bind the team together, we need to work out how to build those connections in other ways. Generally this means building trust.

The five dysfunctions of a team (Lencioni 2002) all start from a lack of trust. Psychological safety is critical to build high performing teams. You can start by asking key questions that investigate evidence of the five dysfunctions.

  • Build personal connections – if you are butting heads with someone, go sit down and have coffee with them. Find common ground, connect and even just acknowledge that you aren’t getting along and want to change that.
  • Be vulnerable – admit you don’t know things, be ok with mistakes, make it ok for others to follow suit.
  • Cultivate a feedback culture – give and invite feedback


Do you have shared stories that are not about work? Do you know anything personal about your colleagues?

  • eat together – it’s that simple
  • celebrate birthdays, bring cake or even just some Tim Tams
  • find reasons for frequent, small celebrations


Just appreciating the contributions of peers can help build trust. Do you tell people you appreciate their work? Does anyone say that to you?

Tangible things like kudos cards make gratitude permanent, it gives people a reminder later on. Make them visible.


Somewhere along the line of automate-all-the-things many people stopped thinking about software as a craft. Some thought microservices didn’t need tests because you wouldn’t maintain them, you’d just throw them away!

Do you have PRs that stay open for days? New starters take a long time (2+ days) to ship code? Do you have to delay releases if someone gets sick, or do people change holidays to avoid impacting the team?

  • clean code – produce code that is easy to read, write and maintain (and produce a culture of shared understanding and desire for quality)
  • TDD – this encourages small units of code
  • pair programming – this is not only a good way to work, it builds connections

Many of these things are hard or uncomfortable, but people have to push past discomfort if they are ever going to grow.

  • experiment – You can make things look less threatening by running it as an experiment for a limited period of time, before a review.
  • create a team charter – workshop core values that the team can align on

Learning and collaboration…

Working in silos leads to groupthink, as people only seek ideas from their direct team. It’s better to grow a network across all teams.

Do people attribute failures to other teams? Do people avoid seeking help across teams? Do they break things you rely on?

  • lunch and learn – good way to start sharing knowledge
  • code retreats and dojos – work on the same code kata for a day, with different people. You throw away the code, the point is to learn how different people approach the same problem.
  • create and support communities of practice


Take one thing that resonates and take it to your team. Maybe run an experiment or do a lunch and learn. Go for coffee with someone you don’t see eye-to-eye with. Push out of your comfort zone.

Create a workplace people are happy to come to.