Grant Fritchey

14 February 2023

3 Comments

What are the biggest challenges organizations face in their digital transformation efforts?

As part of a recent Redgate Summit which focused on digital transformation and data modernization, I was fortunate enough to be able to interview Pramod Sadalage, a Director at Thoughtworks. There, and I’m quoting here, he enjoys the rare role of bridging the divide between database professionals and application developers. He’s usually sent in to clients with particularly challenging data needs, which require new technologies and techniques

That said, I thought it would be valuable to publish the Q&A session I had with him during the Summit, where we talked about data and DevOps and the typical challenges organizations come across in their digital transformation efforts.

So here we go. I’m asking the questions, and Pramod is providing the fascinating answers.

What do you think is the biggest challenge faced by data management people today?

It’s the exposure to modern development and testing practices like version control, and the migration-based approach to deploying changes. As you shift testing left in the software development process, you are pairing more with the developers where you have a lot of influence to change how the software is designed.

Generally what happens is that we complain about the design implemented by developers, saying ‘Hey, this is not good’, but by that time it’s too late to change because there are committed release dates and lots of development budget has already been spent.

I would say go to the place where the design happens and pair with the developers so you can influence the design. That’s super valuable, because developers sometimes lack knowledge about what happens in production environments, so it’s really critical that pairing happens. It’s one of the key tenets of what I always propose: pairing should happen and that will take care of a range of things.

What steps can an organization take to smooth out the friction that is going to be caused by making changes to the culture when introducing DevOps?

The first step most organizations should focus on is enabling people to have their say. Many times we are put in silos and we are used to being measured on certain factors. Now you’re going to ask me to do something else, so there is a big misalignment.

The leadership should give a big safety net to everyone by saying ‘Hey, we are going on this journey, we are going to learn a lot and, if you fail, if you have issues, that’s okay. We’ll cover you, we are on your side, let’s just go through this learning journey first.’ So give that safety net for everyone.

At the same time, provide some kind of framework for learning. You can’t just say to a whole organization we are going to be transforming ourselves and we are going to be DevOps-enabled and just leave it at that. You should have a program, and some kind of learning mechanism, and probably some outside training if that is needed. You should have days set aside, maybe even give employees 80% of the time to do normal work but 20% to learn something new.

This framework of learning and enabling is really important for people to upskill themselves. Think in a different way and basically be happy about the journey that they are on because once people are motivated and happy, then a bunch of stuff starts happening.

The moment you start, you won’t see a jump in productivity. Probably it will go down and you’ll be worried because you thought it was going to be more productive. But that’s the learning curve. It’s not just learning something new but unlearning what was learnt before that is also important.

So you will see that bump. During that downtrend, leadership should be supporting, saying ‘Okay, we’ve got this, it’s hard and we understand. You’ve got the support, let’s go on this journey and learn something new.’ So that support from leadership is really important.

What’s the best way to start DevOps?

First of all, I think it’s the cultural side. Many times we miss the culture and we go directly to the tools and think about what doing DevOps means. What are the parts of the organization that are going to be affected and what needs to change for that? We can even go directly into automating a little bit of infrastructure creation and call it a day, but it doesn’t give you that wide impact that you are looking for. That’s one way to look at it.

Another way to look at it is to start with a small team that is going to do a lot of these things. They will probably take one outcome-driven team and say: ‘Okay, you are going to do everything in this new culture’, and let them do whatever they need to do to deliver that outcome. So they then learn and they can disseminate that learning with the rest of the teams. Then you can slowly start to create new teams focused to other outcomes. So that’s one of the ways to do it.

Do you have any tips or suggestions on promoting that buy-in and engagement from the business in order to successfully launch a DevOps initiative?

It’s a two-edged sword because when that productivity I spoke about drops, the business people will say: ‘Look, I said this is not good for us’. That’s when you need leadership power. But at the same time, the inverse is that when a new concept/feature can go into production within two weeks, that’s when the business people will say: ‘Ah, this is really good for me.’

So with the first team that does this, the outcome they are looking for should be laser-focused on a very small outcome. You can’t say: ‘Hey build me this whole thing’, and then say: ‘Where’s the outcome? I’ve been waiting for two weeks now.’ That’s not feasible. So define what you are going to measure in the beginning and the type of people you are going to work with. Maybe even include people on the business side who are highly motivated in the first outcome that you are going to achieve.

Some people are very open to change, some people are about ‘Show me the results first and then I’ll think about it’, and some people are ‘I don’t want to change.’ So if you know those people who are willing to change, include them in your first pilot project so you can have this nicely done and then you can evangelize that particular concept.

What steps can you take to increase trust between developers and DBAs?

I’ll tell you a story instead of answering that …

I was a DBA and I had a project in England at the time and we had DBAs on one side and developers on the other, sitting in different teams and even different buildings. We literally had to walk five minutes to get to them.

So the first thing we started was to meet once a week and have a cup of coffee in the cafeteria to just discuss what was bothering each of us. That was it: once a week we met and we talked about what was coming down the pipe. So we would mention that we were looking at a prioritized feature and they would say something along the lines: ‘We’re going to upgrade this summer, we have to do that’.

They kind of liked this early feedback and notification of what was coming down the pipe, so they said: ‘Why don’t we meet every day?’. I said: ‘Okay, we could have a stand-up and I could give an update on what’s happening among the DBAs, and you could give you an update on what’s happening on the developer side.’

So they started liking that and this took maybe two or three months to happen and then at some point, because of the synchronous communication that was happening, they started liking it. Then they said: ‘What if one representative from our team came and sat near your team?’ Perfect, awesome, we’ll make space for the person, they can sit right beside us where all the conversation is happening and we can go from there. That’s how we moved from two teams in separate buildings, to one person coming and sitting with us.

The point is you need to build this trust over a period of time. It’s not an instruction that comes from leadership to say you shall collaborate. That’s not how it happens. You need to build a camaraderie because of the outcome when something happens. If the app is down because of something in the database, people are going to say: ‘The app is down’. If the app is down because of something in the app, people are still going to say: ‘The app is down.’

It doesn’t matter whose fault it is. The ultimate thing is that the user is not able to use your system. That’s why I think aligning all of us towards the outcome is really important and building this collaborative camaraderie in the team is really important to deliver that.

What is one thing that all the people out there right now could start doing to future proof themselves when introducing DevOps?

Oh, version control everything. Put everything in version control and say you are only going to deploy what’s in version control. If changes are not in version control, you are not going to deploy them, and if changes are not already built from the version control, you are not going to deploy them. I don’t want someone to check out and compile on the production server for example. So that is the first practice I would start with: put everything in version control and then better outcomes will follow.

This is an edited transcript of my Q&A session with Pramod following his Keynote at Redgate’s Database DevOps Transformation Summit. If you’d like to know more, you can watch the on-demand recording of the Summit, or read the highlights from Pramod’s Keynote, Enabling digital transformation – and data modernization – with DevOps..