Voices in DevOps- Episode 17: A Conversation with Steve Burton of Harness

Guest

Steve is CD Geek at Harness. Prior to Harness, Steve did Geek stuff at AppDynamics, Moogsoft and Glassdoor. Steve started his career as a Java developer back in 2004 at Sapient. When he's not playing around with tech he's normally watching F1 or researching cars on the web.

Transcript

Jon Collins: Hello, and welcome to this episode of Voices in DevOps, where I’m here to speak to Steve Burton. I’m already laughing to myself because we were trying to work out a title, and it went everything from VP of Product Marketing to Audit Management to Northern Brit. Now I’m looking at your Twitter, and it’s all kinds of things, Petrolhead. It could’ve been any of them, but we’re here to talk about DevOps. I guess we better limit ourselves to that. Hello, Steven. Hello, Steve.

Steve Burton: Thanks, Jon, for the interesting welcome.

Yeah, I know. It’s all downhill from here, isn’t it, really? We’re here to talk about DevOps. We’re here to talk about you first... about how you got into a place where DevOps became a normal element of conversation, so maybe start there, if it is a normal element of conversation.

Yeah, sure, I think a good place to start was my first job out of college where I experienced [it] firsthand. I did a degree in Java and got a job as a software engineer. Ironically, my first task was to man a helpdesk for a website like Expedia, and I was given a cellphone. It was like, – ‘if this phone rings, you need to answer it and resolve everything that breaks,’ and that was my job for the first year dealing with website outages and everything you can think of.

Then, after I obviously did well at helpdesk, I was then allowed to write code. It always appeared [strange] to me... why didn’t I write code first? Then I’d know how to better support it in a live production environment. I guess my employer had different ideas.

That’s already suggesting the kind of logical thinking you needed to develop. I’m fascinated by working on a helpdesk as your first job. There’s a guy called Barry McGibbon. He actually wrote books about OO back in the day. He’s probably retired now, but he was a mentor of mine. I know that he said he wanted all of his kids to work at McDonald’s or anywhere that was public facing, as one of their first jobs, just to understand what people can really be like. I wonder if the ‘working on a helpdesk first’ really set you up in terms of – not just what can go wrong but how people react when things go wrong, which isn’t always that pleasant.

Yeah, every day was a party and not a good party, ones where you had people shouting at you. I was 21, and I had the CEO of one of the biggest websites in the world shouting at me daily. It was definitely character building. I think what I learned though, was the business context or the interaction with the business. Typically, when you’re on a helpdesk, you think it’s just tickets and phone calls, but actually, you’re the first of the application or the first of the service. For me, it was fascinating to engage with these business executives that had no idea how to build software but yet think, ‘hey, when are you going to fix it? When’s it going to be ready?’

It’s always your fault when it goes wrong.

Yeah, so if you don’t like being bland, it’s not a great place to be.

It’s like the Turing Test where if you can’t tell it’s artificial intelligence by sending messages, then it must be. With a helpdesk, they just don’t know that there’s anything behind the helpdesk person. It’s just “Can’t you just sort it out? Couldn’t you work it out?” Then you went into development, but you did a Java degree. Does that exist?

It did back in the day. It was 1997, so Java programming was in its infancy. I think it was 1.1. It was in Lancaster. It was one of the first colleges to do Java, so yeah, it was a three-year degree in computer science.

It’s showing my age, but I still think of Java as a slightly new language. There you go. That’s a bit awkward. Now we go back to things like Go, which is almost C, I think. I haven’t had a go with it. It almost takes me back to where I started, so fingers crossed on that. How did you get – it’s not so much how did you get to where you are, but it is kind of. Also, how did you see the journey evolve from doing programming where you started after your helpdesk experience to this world of DevOps? Have you seen the whole industry mature across those past 20 years, or has it been a sudden thing over the past few?

I think I noticed the transition five or six years ago, primarily in the US, where the process of managing risk goes completely out of the window, and they almost embrace risk versus battle against it. I think my first memory of that where I was like, ‘wow, that’s different!’ was probably listening to the Netflix stories in 2010, 2011 and listening to the likes of Adrian Cockcroft. He’d stand on a stage and be like “this is completely different. This is what we do.” Everyone just sat there with their mouth open going ‘what?’

I think a lot of the industry has shifted towards that type of model where it’s like breaking down the silos, moving fast, doing what makes sense, and getting rid of the committee meetings, the red tape and the bureaucracy and everything you’ve done to manage risk and almost tearing all those walls down. I still bump into companies where it’s very much that [way]. You’re thinking ‘how are you still in business?’ I had said the last three or four years in particular, it’s gone mainstream.

That’s interesting. You take me back to Adrian Cockcroft. What a great, lovely guy. I thought he was. We had a beer a few years ago, [and] everyone appears lovely when you’re drinking beer, but it takes me back to the point where, before Netflix and before that world, suddenly these huge companies [were] appearing out of nowhere with very, very different practices. It’s not that we take it for granted now, but it is seen as the ‘why aren’t you doing it yet?’ kind of mode; whereas back then it was nobody was doing it.

It was a completely new way of scaling up. It wasn’t new to do iterative development. It was new to build an entire business that was going to wipe Blockbuster out, and everyone else, by doing iterative development. I think that was the big change.

Yeah, and more of a shift was empowering developers. When I was a developer, I wrote code, and literally, when we finished the tests, we packaged it up and sent it to Ops. That was the end of it. We never heard anything more, and we moved on to the next project. I think similar to what Google did with SREs where now you write, and you support your own code base and the full stack engineer. Just appreciation of operations’ functions I think is more carved to what a developer is today.

We had a dedicated DBA [Database Administrator] when I was a developer, and everyone hired him. The reason everyone hired him had nothing to do with his personality or him as the best person. It’s because we all knew how much he was getting paid. He used to joke and laugh about it, but I mean, that’s how sad, back in the day, it was. Even an Oracle DBA who specialized in the kind of collaboration between it was often restricted for the wrong reasons.

DBA is a special breed, though. Come on, let’s face it.

I know. They’re never wrong. If you go into that meeting in appreciation with that attitude, you’ll do well.

This is probably the wrong moment, but I had a whole conversation, which made perfect sense at the time. I don’t think alcohol was involved this time, but essentially, it was: ‘database people think, obviously, in structures, and developers think in processes.’ Is it a way this is a particle flip between the two things? Obviously, one influences the other, but structure people try and engage with process people. It’s always going to cause a few issues. I know that’s a massive, massive generalization.

Look at the techs today. I mean, Mongo is pretty developer friendly, and you’ve got Snowflake. You’ve got all these more application-centric data startups. Even the developers these days are doing a lot of what DBAs were doing in the past.

Yeah, still procedures. DBAs being developers, that’s where it all started. That’s where it went wrong in the first place.

Yeah, I even wrote PL/SQL. Man, that was painful.

Oh, boy. Yeah, no, don’t ask me if – I can do a drawing. That’s as far as I’ll take it, and then it stops there. Thank you very much. I’ve got the data. I can get on with my life.

Harness, the company you work for, is enterprise facing as I understand it, and we’re here to understand how enterprises can unlock some of this DevOps fantastic, joyful wonder, the Netflix world, the cloud-native world, etc., etc. In my experience, again and again, there’s so many things that can go wrong, and there’s so many things that are getting in the way, as you’ve already suggested.

Would you say there’s some common themes from the perspective of you and Harness or more broadly? I’m literally reading off your website now, and this isn’t about you pitching. If you’re about continuous delivery made easy, are you seeing continuous delivery ‘made hard’ out there? I guess is a starting point.

Yeah, for sure. I think part of the reason is the DevOps organization structures. So what is DevOps in an enterprise? It varies significantly. I think the enterprises that get it right have different pockets of DevOps things that start at a small scale and gradually grow over time, maybe for one or two applications, and they get some quick wins. They’ll learn the processes, and then the story gets told internally.

The companies that get it wrong is where they’re like, ‘hey, we’re going to have a DevOps team that sits across all business units and all applications, and it defines standards.’ They’re trying to boil the ocean from day one. Trying to hire that many DevOps people to set the standards to build the automation and do it at scale I think is – it’s ambitious, but it’s unrealistic. Maybe, in terms of continuous delivery, another kind of anti-pattern is thinking you can build it all yourself.

There’s two modes we see with DevOps team: the ones that move fast, and speed is very much what they’re about; there’s other DevOps teams that focus on being important and having job security and being the experts and being known as the gatekeepers to automation and to a lot of what’s going on in the business. The best DevOps engineers are the ones that are aligned to the business. They just get stuff done really quickly, and they move on to the next project. We see lots of DevOps patterns in the enterprises and so, yeah, happy to share any of those examples.

I’ve got a couple of really dumb questions. One dumb question is – I’ll ask the question as what’s in my head, and then I’ll put caveats on that so I don’t feel quite so dumb: What’s the difference between continuous delivery and DevOps?

The reason I’m asking that question is because I think there’s a lot of companies out there that are doing continuous or starting or trying to be more continuous in their delivery, and they’re referring to it as ‘We’re doing DevOps.’ Does that reflect your experience?

Yeah, it’s all over the place, or I would define it as ‘DevOps is a culture and a mindset and that people follow every day.’ It’s almost like a set of things that they try and demonstrate by doing their job, whereas continuous delivery is really a process, or it’s a set of tasks that automate how you deliver software to your customers. The two are often interlinked, and obviously, vendors are not doing the market a service. They tend to throw the DevOps word around like ‘we’re the next DevOps platform and blah, blah, blah.’

Yeah, you can do DevOps and continuous delivery very well, and continuous delivery with a DevOps culture is going to achieve a lot more than just having a continuous delivery process. It ultimately comes down to people. The culture is obviously a reflection of the people. Yeah, that’s how I’d define the two.

The term continuous is both an aspiration and a symptom, isn’t it? Just delivery is already a good start, and then delivery more frequently is quite good. Delivery up to a point where you think ‘wow, we’re pretty fast at this.’ Then you starting to get it.

It means things to different teams and different organizations. If you’re a bank and you’re used to releasing code every quarter, going from every quarter to every week is still continuous. It’s just obviously not as fast as a West Coast San Francisco startup that delivers code a billion times a day, and it really is continuous. I think, continuous: it’s all relevant to the companies and the industries and what’s normal, I guess, for those individual companies.

Here’s my other question, which is back to what you mentioned, that some organizations try to boil the ocean, and I’ve seen that. I can think of some retail examples, some finance examples. That does lead to situations that create different problems of just how do you engage this thing that’s trying to make it all perfect with a world that isn’t perfect and the friction that’s caused there?

Is the starting point just ‘keep it absolutely really simple’ or is there a middle – I genuinely don’t know the answer to this. I’m not feeding you a line. Should you start with tiny things, or should you start with the big thing, but not that big so that it’s boiling the ocean?

Good question. I think you can achieve it in both ways. Where I’ve seen it work more successfully is where an outside team or an outside individual is brought in to change and disrupt the status quo. I think it’s really difficult for any team to change with 10, 15 years, even 5 years of legacy doing things a certain way. I think you almost need fresh blood or a disrupter to come in and change the status quo and be empowered.

There’s certainly things that can change, but I think to get the change and to get the momentum you need, you need to go and recruit people that don’t have any debt, or legacy, or exposure to what happened previously. That might be the wrong way, but the companies I’ve seen that work in the best [way] – I’m just thinking of one large financial organization. They actually made an acquisition, a small company acquisition, and that DevOps team now manages most of [their]financial and DevOps operations. They were so good at what they did, but they knew nothing about the past and the legacy of that financial enterprise.

It’s harsh but fair. I spoke to Crédit Agricole in France about – they created a more DevOps-y world, a whole app store, a financial application store setup. I said to the guys, ”Why did you do it as a separate business?” They said “because there was just no way it would’ve ever happened if we tried to do it within the mothership,” I think was his term. We had to create a satellite, and then grow it from there.

One customer that comes to mind is Ross’s open bank, the digital banks. If you engage with that team, for me, that’s one of the best examples of DevOps done properly. Everyone’s empowered. Everyone moves fast. They obviously have the constraints of being a financial company. You just get a sense that things happen every single day there. I engage with other banks and associations, and six months later, you think nothing’s really changed. I asked the question; how are you empowered to make all these changes? It’s just like it comes from the top, our executives empower [others] and accountability and freedom. It’s back then right from the executives all the way down.

I’m just thinking out loud here. One of the issues we’ve got, as any person who’s talking about this stuff as opposed to doing it – I’m talking about me as an analyst now, is I generally talk to people that are doing it, and I talk to people that have had some success in it. I haven’t had Voices in DevOps [with] people that say “Nothing ever works. It’s all been hopeless, and so we just stick with what’s full,” which maybe I should. That’s a very good note to self.

You’re doing it right there.

You get a positive reinforcement loop going on where – you’re saying things like, “well, it’s only going to work if you get board level involvement. It’s only going to work if you get empowerment from the top. It’s only going to work if –” and then you said earlier that when developers can just engage with the business and work that out and actually then deliver something and move on, that all sounds great.

What if you’re in an organization where you don’t have that absolute top level buy-in and empowerment, and you don’t have necessarily the ability to switch out the entire team? Do you just say, ‘oh, well, never mind’? You’re broke and just give up. Is there a way forward for these sad organizations that don’t have these wonderful systems in place already?

One option is – if you distill DevOps down, it comes down to communication, transparency, and feedback and learning from mistakes and doing what it takes to fix things and move fast. I think you could take an existing team and get them in a room. ‘Why does it take us, I don’t know, six months to deploy code and production? Let’s whiteboard it together. Let’s figure out where all the friction is.’ Then just do briefs some way. Things happen. Why do we need 20 people in a room to sign off on a change ticket? Why do we have all these tools that no one uses? Why does it take a deployment a whole day with ten people?

The people in IT, they’re smart people, but I think part of it is they’re doing things because that’s the way they’re being told things have been done for 10, 15 years. Why not... let’s deconstruct the process of delivering software or of delivering business innovation and look to optimize it? I think feedback and EQ training, getting the teams to work together, to listen as opposed to be judgmental and be very, ‘well, I don’t believe you.’ Every time someone says that, it’s wrong. I think just training people to give and receive feedback would have a big impact in any organization. Not just [for] IT and developers.

That’s partly what DevOps is, is understanding and getting on and not being of the mindset of blame and fear, which is – I think growing up in the UK in the 80s and 90s, that’s certainly how I saw employment. It was a fear. You were managed with a stick. You have to come in at 9, and you have to leave at 5. You have to wear certain clothes, and you have to act in a certain way. In Silicon Valley, people are very open at doing things in different ways. Maybe you have more freedom and creativity and ability to make an impact as opposed to, in the UK, it’s very restrictive, and you can’t make a mistake at all costs. That would cost you your job.

That’s very interesting. Funnily enough, knowing that you’re from the northeast of England, that’s exactly what my other friend Steve, from the northeast of England was saying about the difference between America and Britain, which is a bit of a sad indictment, but hard to avoid that whole ‘blame culture’ thing.

Yeah, it comes down to just people skills, right? It’s listening to people and understanding and not being judgmental.

I’m very interested. Maybe as we start to go down the other side of the hill on this podcast, wrapping things back around into a helpdesk experience. A lot of DevOps – I spoke to Andi Mann about this at Splunk, for example. It’s big Dev and it’s little Ops. It still is a little bit over the wall or at least it’s push. We’ve developed something, and now we can shift it out there anyway.

All operations is going to be automated, so we don’t need to worry too much about that; whereas the operational world and the helpdesk world and the service world is still alive and kicking and problem solving and diagnosing and everything else. Given the fact that you started there, how would you see what people see as full cycle feedback loops, etc., or are we really just trying to simplify getting stuff into production?

I think we’re trying to reduce the time it takes to go from an idea to getting it in the customer’s hands. Unfortunately, to do that, you need to remove the time and sometimes the people that are involved and make it ‘hands off.’ If the competition is doing it faster than you, you’re probably going to lose that market. Change is sometimes painful.

I hear you on the Devs and the Ops and Ops feeling left out. Why does it take the business – I don’t know. Let’s say: why does it take a bank 90 days to take a change and put it in the customers’ hands? That just doesn’t seem right. When you understand the timeframes and the teams and the people and you try and optimize that, there’s going to be casualties.

I do think the role of a developer these days is wider, and there needs to be more appreciation for operations. It’s because it’s ongoing. I deploy. I see my code. I need to verify it. What’s the business impact? Do I need to roll back? Do I need to make a quick change? It’s almost giving developers that instant feedback loop to what’s happening.

I think what they also lack, and I think both operations and development are guilty of this, is the business context. They’re all managing these artifacts and these infrastructures, but what was the business outcome of the changes of the work that they did that week and next week? I definitely think any part of DevOps is: why are you doing DevOps? Is it to make you feel good because everyone else is doing it, or is it to move the number, or is it to increase customer yields, or revenue, or orders? What [are] the business KPIs behind your DevOps initiative? I think that’s a big void right now in many companies that we engage with, and I’ve seen a lot of the kind of DevOps stories that I saw, business alignment, business visibility.

When I was on the helpdesk, I literally – I could see the revenue numbers every day, and if those revenue numbers were down, I wasn’t going to have a good day the next day. Developers need to see that. Hey, I deployed this code. Suddenly, you know what? That new service I shipped, it created all these orders. The business was great. Why can’t we celebrate the positive stuff that developers and operations people do as opposed to always focus on the negative stuff?

That’s brilliant. I was so wrapped up in what you were saying. The future then, final thought: are we there in terms of… the situation that we’re going to have where some organizations are brilliant, some are not so good, and I mean, a bit like the rainforest? Or maybe [that’s] a bad analogy at the moment with the fires but essentially, it’s going to be in a constant state of change, and something’s going to be dying while other bits are going to be growing, etc.,? Or are we progressing towards another place, in your mind, and in your experience with your customer?

I think there’s always going to be evolution of people with new ideas and new ways of doing things. DevOps is just a lot of those things coming together at the same time around 2010, and thinking ‘is there any way we can do IT at scale?’

With new technologies around the corner, I think serverless is going to empower developers even more. That type of shift is definitely going to be big. Even machine learning and AI, no one quite knows what’s going to happen. I think that makes things interesting. There’s opportunities to get creative and push the boundaries of what can be done. Part of working in tech is it’s exciting. Nothing stays the same.

The old Chinese proverb is so true at the moment: “May you live in interesting times.” It’s only going to get more interesting from here.

To give you an example, though, yesterday someone tweeted a video of two people in a Tesla X fast asleep on a highway. To think a car can do that and drive itself is crazy.

My mouth is sitting open briefly there for the audience. They can’t see me doing that, as were theirs.

You should see the responses on Twitter.

Oh, that’s going to be my next important call. I’m going to go and have a look. While I do that and while we wrap up, are there any last things? It’s your moment to just say if there’s one thing you could do, or here’s the next thing to try or whatever for people out there looking to do better DevOps?

Simply put, I think ‘be kind.’ Get along with people. Learn how to communicate. Feedback is the biggest thing that’s going to help you continuously improve, whether you do DevOps or whether you don’t do DevOps. I think having an appreciation for when things go wrong and understanding why things went wrong and lessons learned. I think that is super key.

If you’re going to do DevOps, it’s probably a good idea you hire people and recruit them and teach them those types of things. The EQ is as important as the IQ. Yeah, I think just simple human skills go a long way, regardless of whether you’re building cars or whether you’re building software.

It’s something I’ve spent some time a few years ago thinking about. The conclusion I reached was that if technology doesn’t turn us all into an autometer, then it will enable us to be more human. I think that’s a fantastic note to end on. Thank you very, very much, Steve, for joining me on this podcast. I look forward to speaking to you more on these subjects.

Yeah, thanks, Jon. Appreciate the time.