Why Redgate believes in the need for DevOps coaches

The coaching role at Redgate has gone through a few evolutions, from coaching specialist skills in testing, documentation and agile delivery, to more general technical coaching, through to a more transformative, DevOps-oriented approach.

We sat down with Gareth Bragg, one of Redgate’s coaches, to learn a little more about the role and where it’s headed.

Let’s start at the beginning. What even is a coaching role at Redgate?

We’re here to continually build an environment where it’s easy for people to do the right thing, in the right way.

Beyond that, the constraints are really quite loose. We’re trusted to identify and prioritise ways of helping Redgate evel up its approach to building, designing, and delivering software.

A big part of that is working with the different lead roles, who really own the “how we work” part of building products at Redgate. Building and maintaining those relations is key, since we’re working with these people to build a better, more rewarding place to work.

That sounds a lot like agile coaching. Why the focus on “DevOps”?

Redgate knows we need to move with the times if we want to continue to deliver incredible tools. We’ve been heavily involved with agile development practices for a long time and have always taken continuous improvement seriously.

We think we need something else now. The world is changing, and managing data safely is one of the hot areas in IT. Bigger companies are looking to us to solve larger, more complicated problems. If we want to meet those expectations, we need to evolve how we work at a far faster rate than we have done before.

That’s what’s hiding behind that “DevOps” term for us. It’s not about any particular practices or tools. It’s about adopting a more holistic view to our tools, how we build and deliver them, how they’re used. It’s about equipping ourselves to meet the increasing demands on our products and making that step change from “tools vendor” to “company that solves complex, enterprise-scale challenges”.

On the more pure “lean/agile” side, Redgate has four Dev Leads. They work more closely with our engineering teams on a day-to-day basis, supporting them with the more fundamental parts of how they work. Slicing work thinly, effective communication, continual improvement. That kind of thing.

Our DevOps coaches support that work, but our focus is purely on transformational change, with less time supporting incremental improvements.

How do you go about this sort of work?

We talk a lot about “influence over authority”. We’re free to engage with any part of how Redgate delivers software, but don’t have the power to “tell” anyone to do anything.

That means stepping back and experimenting with how the system works and introducing ideas that can bring true value.

We’re big on practicing what we preach. Right now we’re experimenting with PopcornFlow, a framework to support rapid experimentation. Dogfooding new ideas like this give us invaluable insights into techniques may be useful, rather than promoting the latest hot topic from the conference circuit.

On a more logistical level, we do high-level planning at least twice a year. That helps us to prioritise the areas we want to work on — currently communication and learning & development — and we use that to draw up initial experiments to run. That’s why something like PopcornFlow appeals to us!

We try to use Objectives and Key Results to keep us on-track and see the impacts of our work. We track the hoped-for outcomes of our experiments, and review those at least weekly. If we’re not seeing the impact we’d hope for, we harshly ask ourselves why, and if we need to change our plans.

What do those changes look like at Redgate? What sort of changes to you make?

The pithy answer is “whatever will make things better”, but that’s probably not helpful…

On the team level, we support people in adopting unfamiliar practices. We’ve had some great success with a zero bugs policy. Some find that a controversial approach, so our supportive and experimental approach was crucial in getting it to land.

We’ve built new hardware to make build statuses immediately and constantly visible for teams. That’s moving us towards a zero-tolerance approach to broken builds and failing tests, which is proving hugely powerful.

I like working at a more meta level. The book Accelerate has generated excitement about the “Four Key Metrics” of software delivery. We worked across our product organisation to measure and visualise these and make them a fundamental part of our process. That’s enabling a cultural shift, thinking more deeply about our approach to delivering software and the impact of changing how we work.

Even more meta, we’re looking at Redgate’s learning & development culture right now. That’s been a wide, long-running area of interest. We’ve been doing marketing and branding work, so people better understand the L&D opportunities they have. We’re considering frameworks to support people of different seniorities to figure out their own L&D pathway. We’ve been running events; training courses, workshops, open spaces, you name it. We’ve done guest lectures at a local university. We’ve supported an offsite engineering conference for the last two years. That’s been so successful that it’s growing in 2020 to include our entire Cambridge-based organisation, and I hope the whole company in 2021.

So yeah. I guess it can be a varied role…

What makes a good DevOps coach at Redgate?

I wish I knew! I’ve been in this role for almost four years now, and it’s been a constant “journey of self-discovery”. There really isn’t a manual for these things.

We’ve definitely found a few key things that we’d look for in a new coach, though.

You’ve probably got the idea, but flexibility is important!

Being able to think strategically comes up a lot. It’s so easy, and appealing, to laser in on the low-down detail of how things work, but we really have to take steps back and focus on the bigger picture. The “outcomes over outputs” rhetoric gets used a lot.

An open, creative mind is valuable. Your favourite idea may not work out, and you need to drop it. Something that sounds awful to you may be the perfect way to move forward. Again, it’s all about those outcomes.

Willingness to fail. As a team, we fail. All the time. There can be weeks where you feel you’re banging your head against a brick wall, but that’s a powerful sign we’re not really solving a problem and need to pivot. This is something I’ve always struggled with, and I consider myself pretty resilient, but we work hard to support each other when we’re having a hard time.

I also think a technical background is important. Just as understanding customer pains is crucial to delivering great software, understanding the challenges of designing, engineering and delivering great software is key to really improving how we work. The best way to really appreciate that is to have lived it for a while.

Finally, and I can’t stress this enough, people skills are crucial. We work with so many people, which is challenging on its own, but we’re not here to be busy. We’re here to encourage effective change, and that requires healthy, high-trust relationships with people. Building those takes more than time, it takes building connections with people.

That sounds tough. Is it always such a challenge?

It’s always challenging, sometimes frustrating, and sometimes rewarding. That’s part of the appeal. I’d hate a job where I can stroll into the office, rinse & repeat the day before, then stroll home. I’ve been there, and it’s boring.