Skip to main content

Team Titans Season 2, Episode 3 - Matt Saunders

Ryan Spilken
Ryan Spilken
22 January 21
team-titans

Join hosts Ryan Spilken and Heidi Araya in conversation with Adaptavist DevOps guru Matt Saunders about the overlap between DevOps and Agile, Psychological Safety in teams, and the trends to look out for in the future of work.

Transcript

Ryan Spilken:

Hello and welcome to Team Titans, the stories of people with unique perspectives on work itself. They're defining processes, building tools, leading teams, and sometimes they're breaking those processes that they then just made. I'm Ryan Spilken and I'm joined today by my cohost, innovation product manager Heidi Araya. Heidi, thank you so much for joining me today.

Heidi Araya:

Thanks for inviting me here today.

Ryan Spilken:

And I am so excited to be speaking with you with our guest, because you're going to be able to really prod and poke and get some deeply insightful answers out of today's guest, Adaptavist Head of DevOps, Matt Saunders. Matt, thank you so much for joining us.

Matt Saunders:

Thanks, Ryan. Always a pleasure.

Ryan Spilken:

So good to see you, Matt. You're role as head of DevOps has seen you move away from necessarily client facing work to working with our CIO team. So are you doing DevOps still? Are you still the DevOps guy?

Matt Saunders:

Am I doing DevOps anymore? Oh, that's a good question. Am I still actually the DevOps guy? Yes, I think I actually am.

Ryan Spilken:

Oh, good.

Matt Saunders:

So let's talk a little bit about what's happened since I came into Adaptavist three and a half years ago. I came in with a fairly nebulous title of head of DevOps. I talked to Simon and others in the business around here, "What does that actually really mean? Should Matt be doing DevOps and getting his hands dirty and doing things that are DevOps all day long?" And we kind of came to the conclusion that the business is doing some DevOps. They're sprinkling DevOps everywhere. Let's do more of it. And so I kind of floated a bit around between internal teams doing DevOpsy type things, whether they are cloud engineering, working with Amazon Web Services or tools like Kubernetes and Terraform, but also going out to our customers in the consult team, our professional services teams, where they need some help in doing DevOps, whether that is with tools or in the more organizational process, culture type level of DevOps in terms of the way people actually work.

Matt Saunders:

And so I've been working in the innovation community of practice recently. We've good friends, John Turley, Jon Kern, and more recently as well with Heidi, which has been brilliant, but actually we're at an interesting time in Adaptavist where the company is growing fast and some of the things we've been doing for our customers we can do with applying internally a bit more. So, yeah. So I've taken that new role under the CIO, under Neal Riley to help bring more DevOps to us internally. It's quite interesting how the things that you go off and do with your customers and you tell them things like release software as often as you can, have lots of tests, have cross-functional teams, how easy it is to not actually implement those sorts of things internally.

Matt Saunders:

And so one of the things that I want to do, and that Neal wants me to do is to bring all that stuff out, make sure that we are actually one of the leaders in how we develop and run internal services because they're much the same as what our customers are doing. It's a classic bit of dogfooding. So just to finish off on that. So I was a head of DevOps, I think I still am a head of DevOps. We've been very lucky in Adaptavist in the acquisition we made. It has brought a whole load more of DevOps people and more heads of DevOps. So yeah, DevOps should be everywhere? So I'm really, really glad that I've lots of DevOps and lots heads of DevOps around.

Ryan Spilken:

So one thing that I look forward to speaking with you about today is something that I've seen you do as in your role as head of DevOps and that is almost like team psychologist. I remember sitting down with you for a team meeting and thinking, "Was that DevOps? No, it was just an aspect of it," but I certainly do look forward to chatting through that.

Matt Saunders:

Well, yeah, it is. There's a psychological element here, which you, of course, have directly experienced. I remember that session very well. It was excellent. And it can be a surprise. When you think of having a discussion about DevOps, which to a lot of people is all about tools, maybe Jenkins or things with bizarre names to onlookers. Let's do some Terraform and some Kubernetes and some EC2, but actually is, at its more fundamental level, it's so nicely with things like agile and flow. Now, how do you actually get work done? And we'll talk a bit, I'm sure, in the next few minutes around how agile intersects with DevOps and how there's a whole class of stuff that's looks like you should be doing, but actually it's just masking the interesting stuff, which is all about delivering value.

Matt Saunders:

And so the session that we were, that Ryan's referring to, was one that wasn't really about technology. And I think that's why we got a lot out of it because we were looking at how do we get people to be able to do their best work and how do we get people to be able to deliver stuff? So, yeah.

Heidi Araya:

That's interesting. In late 2016, early 2017, I happened to attend a conference and I met a DevOps consultant there. And after attending that his intro to DevOps, I walked up to him and I was doing agile coaching at the time. And I said, "We're saying the same thing, only you're just approaching it from a different angle." And so we ended up collaborating on a talk called DevOps, a Catalyst to Enterprise Agility. And we spoke at a conference there a few times, a few different conferences, but I'm curious what you've seen as when people approach DevOps and thinking about it from a tools perspective because that's exactly what we found, is there something that you normally start with when folks come up to you and say, "Hey, I want to do this DevOps thing." How do you start?

Matt Saunders:

Well, how do you start? Well, you find somewhere to start and you've got to, sorry, that sounds like a terrible answer. But what I mean by that is people generally want to talk about the tools, and you can go in and spend a hell of a lot of money on getting in the right tools and consultants to put in the tools for you. But I would encourage people to start small. I mean, if you're talking about doing things that are transformational, whilst every company is individual and has its own particular needs, for most people, it is all focused around getting software delivered and you're only really going to find out the things that are really unique about you and your organization by going off and developing this stuff. It kind of helps that people start talking about tools because, well, you can go in and give them some tools.

Matt Saunders:

But I think the attitude you take to that is critical. If you take it from the point of view of like "We've delivered a lot of tools, therefore we're DevOps," hey, fantastic. Then all you've ended up with is a load of extra complexity, probably some more friction in letting people actually get stuff done. I try and see the tools as being a bit of a focal point around what's going on around the tools. Who's actually running the tools? How does that tool interact with the next thing down the chain? Other people who are not directly running the tools, use the tools, they'll get value out of the tools. And bit by bit, you start to unravel the whole system and by system, I mean, not just a computer system, but the system of how you get stuff done. Right? So that's the key there.

Heidi Araya:

Oh yeah. I was going to ask when folks approach you with tools, much like they may have approached me for agile coaching, I find that it could have been impacted by the organizational culture and hierarchy. So how do you handle that? When someone just wants to implement a piece of the tool somewhere.

Matt Saunders:

I generally do a very big sigh a bit like this. Okay. Sorry. That's very kind of old worldy kind of cynical type approach. You've got to take people at face value. You've got to appreciate where they are on their journey. Prior to Adaptavist, I worked in consulting for a while and we had a sequence of engagements which were very much like this. It was like, "Yep, we got this man or this woman who wants to go and implement some tools. Matt, go implement the tools for them." And you're like, "Okay." And the worst thing you can do is go in and start challenging someone. You start to talk about something else. Somebody asks you, "Can you do the tools for me?" And you're like, "Well, no, because of this, this and this."

Matt Saunders:

And quite often you find that when I say this, this, this, it is all about process and culture, exactly what you're talking about there, Heidi, you'll find that possibly the person who's asked you to do that sort of thing doesn't actually have any influence in those other areas, especially in the larger organizations. And so from that point of view, you're in a bit of a tricky spot. It's a bit like if you've got a picture that needs to be put on the wall and somebody's given you a saw and they say, "Can you use this saw top put this picture on the wall?", well, yes, we can probably do it somehow. Actually, maybe not with that. Terrible example. But it's the wrong question. So what I will be doing is asking the [Ingrid 00:10:08] questions around how do you see actually deriving value from this? What is actually the value?

Matt Saunders:

And given the right sort of culture in the organization, those questions go down well. I've had it work both ways. There's some terrible examples of pathological culture, which is actual thing, if you look up Westrum's definitions of culture, for example, the pathological, where there are people are not really allowed to operate outside of their own silo. And that sort of initiative is frowned upon because it might make somebody else look bad. Meeting those sorts of organizations, you can tell fairly quickly what type of organization you're working with. And the problem with those is it's almost tragic, in that the organization desperately needs to change to not become like that but you've got no possibility of doing that. In those sort of cases, you're a bit stuck. All you can do is work within those narrow confines.

Matt Saunders:

Those things tend to end up with a nice new DevOps team where there wasn't one before and I'm being a bit negative about DevOps teams. Sometimes it's a means to an end, but ultimately trying to work out how value is actually delivered, the last bit of that is kind of DevOps. And if you don't consider it as being a part of a bigger whole, like somebody has an idea for a product, somebody wants to write some code and then somebody wants to deliver that, that whole thing you got to take that into consideration when you're putting in tools. Otherwise at some point it's all going to fall down.

Ryan Spilken:

So for a second, if we could, let's step back to a company that is maybe not grown to the point where it's gotten that sort of parasitic culture thing happening, right? And there is still like some uncertainty and it's growing and somebody up top says, "You know what we need is a DevOps strategy," because they read it in a magazine and they think it's a good idea. But they're starting fresh and things are a little bit fuzzy. How are they going to go about developing a strategy to be successful in this arena?

Matt Saunders:

I think the fundamental thing behind a DevOps strategy is that, great, that it's being mandated from the top. It should stay at the top and it should continue to be at the top because these sort of things are fundamental to how companies are delivering value these days. So much of what any modern business does is around software these days. And you can trot out examples like Uber, for example, taxi companies that used to be about getting vehicles on the road, but actually it's technical. It's a software problem. Everything that they do, well, not everything, but fundamentally in its core days. So yeah, DevOps strategy. See, you want to have a strategy. Okay, cool. Are you going to align everyone in your products world, in your development world, your marketing world, around this DevOps strategy? This is why you should.

Matt Saunders:

Because these things are so key, it's got to fit in and it doesn't just have to be a DevOps strategy. It could be a more all encompassing thing, because again, ultimately, and I've said this a few times already, it's about how do you flow? How do you get the flow of value to your customers? And that just ain't DevOps. And if you treat DevOps in isolation, then you're not going to get there.

Heidi Araya:

It sounds like you might be thinking about also start with the vision and the outcome, not actually what problem is DevOps solving. Much like agile, we're implementing Scrum or we're implementing an agile framework here and so agile ends up being the goal or DevOps ends up being the goal without really thinking about why do we care about that? What's the bigger problem at hand?

Matt Saunders:

Totally. Yeah. There's a danger there in that you can say, "Oh, I'm not going to go and install Jenkins on that server for you, because we need to think about DevOps as an overall strategy," and they're pitting to agile and everything and high level, but refocusing the discussion to be slightly wider is always a benefit because yes, you're absolutely right. Especially in big organizations, these things can be intangible unless you make them tangible. And every time you make them more tangible, like delivering, I don't know, an environment where you can do SAFe, for example, or an environment you've got a CI system installed and running tests every X minutes or whatever, could accidentally move you away from some of your goals. So you've got to be very careful to make sure they're all aligned or within that wide scope.

Ryan Spilken:

We've kind of danced around the issue a little bit. I think we just need to talk about how DevOps and agile sort of overlap, right? Because you're both saying pretty much the same thing about the bigger picture, the strategy, where are we going? Not here. And you're coming from, like you said, Heidi, in your talk, you're talking about the same stuff. So where are the overlap pieces? Maybe you two could highlight some of the differences as well.

Matt Saunders:

That's what we want. Differences. Yeah.

Heidi Araya:

Well, I'll start out with the agile piece. So agile really is about delivering value to customers frequently so we can get feedback and we can make better decisions. That's really what agile is about. I mean, I can say when, when I'm thinking about how DevOps adds to it, well, it helps us get releasable now. What kind of feedback are we receiving? How are we going to receive feedback and get feedback in ever smaller and smaller loops so we can reduce organizational waste? But Matt, please add your perspective just as an agilist. I'm coming in here with mine.

Matt Saunders:

Yeah. Well, so this is a terrible interview because what you want is a bit of conflict, you want disagreement. No, it's like, "Er. Grr." But, yeah, it's two sides of the same coin. Here we go. I'll try and be slightly controversial. Those damn agilists wanting software delivered like all the time because they can't make their mind up on what's going to be the right thing and wants me to move out their product. I'm just a poor ops person with my servers in a room. And they want to release 17 times a day and they've got 17 different things on the go. So I need 17 different environments. That used to be a point of contention. If you look at DevOps the word, dev and ops, dev throws stuff over the fence to ops. But yeah, you lot want to deliver value, or you want to do your experiments to work out what is the right thing to do, because let's be clear.

Matt Saunders:

It's almost impossible to work out what the right thing to do is a planning stage. That's why we don't do Waterfall or anything like that, because it's wrong. It's inevitably going to be wrong. Information that you find out later down the development process re-informs your decisions and you have to go back. And part of agile, of course, is acknowledging that that is a fact of life, regardless of how much we want to be able to plan things. So, yeah, there was conflict, dev and ops, between the CIS admins and the coders, because, well, basically we ops just want stable systems. We don't want people changing stuff because stable systems, things that aren't changing, don't break in new ways. Maybe they break in old ways because they were always breaking but at least it's the same old ways. Fine. Great.

Matt Saunders:

But yeah, and here's where it all comes back together. A definition of DevOps could be that it is actually providing the environment that agile people need to be able to prove the value in terms of delivering it, getting it out in front of customers. One of the key things that I always come back to on this point is a blog post, an old CTO of mine, a guy called Benjamin Wootton, when I was working at Contino, he wrote, which is around how environment provisioning was a key differentiator between high-performing ops teams and non high-performing ops teams. This was written before the State of DevOps Report came out, which talks about what those differences actually are, but they're all kind of tied together.

Matt Saunders:

And so, yeah, I've been that person with servers in a basement and have coders come and be like, "Oh yeah, we got this new thing. I want to try this out. Not really sure if it's going to work. Can you give me a box to try it on?" And I'm like, "Oh, here we go again." We can do all that stuff. Now we can automate it. Virtual servers. You want a server, click, click, click, bosh, there you go. New environment. Exactly the same as the last one, it click, click, click. Okay. Maybe wait a few minutes from the database to get provisioned, but fine. There you go. There's your environment. It's disposable. Do what you like with it. Do your experiments on it. Be agile. Brilliant. We're there.

Heidi Araya:

That's one of the things that, and when I was collaborating with this DevOps consultant a few years ago, I ended up thinking, gosh, looking at the manifesto and the 12 principles, I thought they have the DevOps mindset in mind. So luckily with us, we have working with us, we have Jon Kern who is co-author of the Agile Manifesto so I was able to ask him. And he said that actually he had been preaching and practicing DevOps-like things driven by the need to see frequent, tangible, working results. I was happy to find out that just as I thought, they were really thinking about those things when they were writing and crafting the Agile Manifesto.

Ryan Spilken:

Jon Kern was our first guest on Team Titans. So if you want to listen to that episode, we'll include a link in the show notes.

Matt Saunders:

It is a mindset thing. I mean, we talk about an agile mindset and there is a DevOps mindset as well. And they are highly compatible. When both sides of the relationship work in harmony, you've got agile things going on, DevOps things deploying them, reporting back on them, giving you feedback back into the cycle. It's something you have to work on the balance a little bit on. It can't be all one way, but ultimately, that is one of the keys to delivering stuff. It's being able to implement agile and DevOps in a mutually compatible way. And it isn't actually that hard.

Ryan Spilken:

Well, this brings me to an interesting question, right? You've just described a scenario where things are happy and harmonious, where there are birds singing and unicorns frolicking in a field, right? What about when things start to break down? How do we reconnect people? How do we reconnect teams? How do we refocus on delivering value to the customer?

Matt Saunders:

It comes down to people. I was just going to say, it comes down to empathy. You've got to have empathetic people. If you, and again, these sorts of things inform how pathological or otherwise your culture actually is. If you look at how people are rewarded, how things that cause them stress in their work, the kind of even the joy that's brought, sorry, if any of those things are out of whack, then you start, you do, you start to get these little problems. Maybe there's a perception that the environments that the ops people are building for you aren't actually good enough or are not providing the right sort of feedback. And for whatever reason, you can't actually actively collaborate on those things. But in a lot of companies, you can, and I would stress those. It's a significant thing around leadership to make sure that those avenues are always open.

Matt Saunders:

We're moving somewhat away from this kind of siloed approach where this team does this, that team does that. These people write code. These people write tests. These people provision infrastructure. These people respond to alerts in the middle of the night, and you kind of need that to scale to an extent, but giving everyone else an appreciation for what everyone else is doing can lead to some interesting positive effects. So we talk about things like T-shaped people, so people who have... Maybe you're a coder, but you have an understanding of everything else. And one of the traps is that people feel like they have to kind of understand everything about everything. And in an ideal world, that would be true. It's a lot easier to... One of the problems with silos and people doing these very narrow roles is that it can be hard to understand what's going on at the interfaces between the silos.

Matt Saunders:

So if you're handing something over, any bit of software over, from dev to testers, you've got to explain to the tester what the intention of the software was. And there's a whole series of informal discussions and contracts that go into that. And taking this to its logical extension, you can get yourself into a better position where everyone has an appreciation for the whole flow, the whole cycle and so much more than that. Another example is stuff like being on call. Traditionally being on call has been something that ops people would do. I've been there, going back, even back to the 90s, pager goes off in the middle of the night, something's gone down. I have to get out of bed and fix it. So I'll go and fix it. The next night happens again because I just bandaided it. It's been fixed temporarily, et cetera.

Matt Saunders:

If you put your devs on call and they get the page, but they probably don't get it in the middle of the night because they probably see it earlier. And they see, "Oh, what I'm doing there is causing this thing to go down at three o'clock in the morning," so they can fix it. So there's a lot in there, but ultimately it's the working together. You consider yourself to be part of a wider team, getting appreciation for what other people do, really gets you along. But you have to have the right sort of people in the first place. First time I ever, sorry, just one more point on this. First time I ever did devs on-call, I was really surprised by the reaction. People don't really like being woken up in the middle of the night. That's fair enough. Right?

Ryan Spilken:

Funny.

Matt Saunders:

Thank you. But actually, there's an interesting thing going on there, which is that a certain class of person doesn't like somebody else being woken up in the middle of the night for something that they did wrong or that not that they did wrong, but with hindsight, they could now do better. And so the first time I ever did devs on-call, it was a tiny startup back in 2009, I think. They loved it. The devs loved it. They were like, "Oh right, okay. We can be involved in this stuff right at the start when it breaks and stop it breaking again." So that then leads to, "Oh yeah. That sort of thing wakes people up." So you write some code, I don't know, a month later, middle of the day. Oh yeah. You get an appreciation for what sort of things go wrong. So in that environment, those who went on call, people stopped getting woken up because people were coding better. You get all those sort of benefits from that. I can't remember what the original question was. I probably landed on for about an hour on that one.

Heidi Araya:

It sounds like empathy. It sounds like what you-

Matt Saunders:

Empathy, exactly.

Heidi Araya:

Yeah. Yeah. So I have a question because you mentioned the word flow a few times in this call already. And so I'm curious whether you feel the concept of flow has been intuitive to folks or challenging for them to understand.

Matt Saunders:

I think it's really challenging. I think we spend so specializing on things, especially technical people. We're encouraged to do that. We're encouraged to specialize, be really good, be a really good Java coder, be a really good Terraform engineer, et cetera, be a really good HTML slash CSS slash angular slash react slash whatever the hell front end's written in these days type person. But the more you specialize, the less you can see your individual part, which actual cog in the wheel you actually are, if that's not a terrible metaphor. And so being able to take a step back and be a bit more general to see actually, yeah, so I'm doing this work and I'm probably motivated and my own serotonin levels are heightened by solving problems in my own particular world.

Matt Saunders:

But actually that's not the same as what my business is trying to do or the business that I work in is trying to do or the organization, whatever it is. The reality is you look back at agile, DevOps it is all about flow. It's the flow of ideas from something in someone's head to somebody who writes some code to it getting actually delivered out. And if you look at it from that point of view, that your system is always moving, stuff is always flowing through it. It's transactional and the faster you can get these things, though not necessarily faster, the more efficiently you can move things from one state to the next governs how fast you can go. Yeah. That's flow or value streams, any of these words, but it is. It's not what we're encouraged to think about or we're encouraged to go into, especially going into computer science and its related disciplines.

Matt Saunders:

It's actually around perfection, specialism in things. We all know perfection is the enemy of finished or is it the other way around? And you get this interest in conflict in your mind around what should you be prioritizing? Is it getting them through the system or is it making them really, really good? And, yeah, that's a wake up call for me when I realized I'd spent months working on a particular project, just trying to make it perfect and meantime that the business had moved on. They were interested in something else and that thing I'd made perfect didn't need to be perfect. What about the flow?

Heidi Araya:

So Matt, we've been talking about quite a few things over this time and what are the current trends that we should be paying attention to? What should we be looking out for?

Matt Saunders:

I think it's kind of more of the same. I think DevOps as a thing, it's been around since... I can say I've been doing DevOps since when I first started using a computer, but really it started in 2009. So seminal presentation around flicker doing 11 deploys a day. So yeah, we're about 11 years in DevOps now, I would say. So in a lot of ways, there are a lot of companies who are doing this well, doing DevOps well, getting the flow delivered rapidly and effectively and efficiently. I think it's very easy for us to take our eye off the ball at this point. There's a lot of people saying they're doing DevOps or maybe they are, maybe they implemented DevOps in a change and they transitioned three or four years ago. And so now we're all DevOps. I think there's, in terms of the principles, the concepts that are going on, there's not a huge amount of change going on there, but we are still seeing...

Matt Saunders:

New tools are still coming out. Systems are becoming simpler. If you look at some of the things that the cloud providers, people like Amazon, Microsoft, Google are releasing, there's not only new tools, but refinements of old ones and some solidification, particularly technically, around using specific platforms. We're seeing a rise of doing things in a serverless fashion. So not necessarily just Amazon Lambda, but I mean that concept where you're not having to think about infrastructure too hard to be able to get your stuff delivered. And there seem to be now two camps. So people who can do serverless and people who can't. Rise of containers as the technology, things like Kubernetes, not that I'd encourage just anyone to go off and run Kubernetes, but you can buy that now. And those sorts of things are becoming much more commonplace in organizations.

Matt Saunders:

Big trend around companies who previously couldn't use cloud for whatever reason, for example, if you're a financial institution or a government institution. That is now changing. People are moving away from things like hybrid cloud environments where you'd have some of your workload running in house and some of it running on a public cloud provider and people are actually realizing that the effort of hybrid cloud is more than actually just having a migration strategy, in case cloud A racks its prices up massively. In terms of the people and culture stuff, again, quite a lot going on there. I would point people at The Unicorn Project. It's come out quite recently, actually probably a year ago now, where Gene Kim talks about the five ideals of how to create that environment where you can get your ideas flowing out into production, through product ideation, through coding, through testing into the ops world.

Matt Saunders:

Again some very, very interesting insights in that. Those are the big things as I see them at the moment. But yeah, the good thing is it's still on the ascendance. Look at the State of DevOps Report every year. More and more organizations are doing things well and moving on to the next challenges.

Heidi Araya:

Thank you.

Ryan Spilken:

Matt Saunders, that was really fantastic. I learned a whole lot today and thank you so much for your time.

Matt Saunders:

Always a pleasure talking to you, Ryan, and thank you, Heidi, so much.

Heidi Araya:

Thank you.

Matt Saunders:

Great. It's really, really good to riff off such a well respected agile expert as well. So yeah, I really appreciate that. Thank you for listening to me rant for however long that was. I really enjoy doing that. And actually now I probably shouldn't do any more of it, but there you go.

Ryan Spilken:

And Heidi, thank you again so much for joining me as well.

Heidi Araya:

Yes, you're welcome. Thanks for having me today.

Ryan Spilken:

And that's it for this episode of Team Titans. Make sure you subscribe to get all the latest episodes of the Adaptavist Live podcast channel and connect with us on social at Adaptavist. For Matt Saunders and Heidi Araya, I'm Ryan Spilken and we'll see you next time on Adaptavist Live.