Inspire the Nation Podcast Episode 1: DevOps
Mark Solomon, QA’s DevOps Practice Director gives you the ins-and-outs of DevOps:
- What is DevOps?
- What does DevOps mean?
- Why DevOps is critical in achieving business goals
- Why you should be interested in DevOps
- Do agile & DevOps fit together and how?
Watch the video, listen to the podcast, or read the transcript below.
Inspire the Nation Podcast 1 transcript:
Intro:
- Paddy Dhanda: Welcome to The Inspire The Nation podcast. We at QA are super excited to be bringing you a regular dose of thought leadership, industry insights on all things related to tech and learning. I'm Paddy Dhanda and I head up the Agile Practices at QA. I started off as a software engineer and I accidentally stumbled into the world of learning, having headed up the agile learning for a global bank and playing lots of Lego along the way. My biggest passion lays in creating engaging experiences through elements of visual thinking, gamification and storytelling. This is my colleague John Gordon.
- John Gordon: Thanks Paddy, so I'm so John Gordon, and I am Software Practice Director for QA. And really what we want to use this podcast for is to inspire anyone into technology, regardless of background. Personally, I really fell into software... if I go back 10 years ago, I was working in air traffic control in the military, and by chance, I got into a software development project. What we want to use this [podcast for] is to meet some amazing guests with a real inspiration for trying to get people into tech jobs.
Episode 1:
- PD: So I guess John, how are you feeling today? I was a bit nervous this morning, with this whole new adventure ahead of us for the podcast.
- JG: Actually looking forward to it, obviously it's a tough time for everyone. So this is one thing we can do to try and inspire people into jobs. That's really what the whole aim of this podcast is.
- PD: Yeah, fantastic. I've done a few podcasts on my own previously and obviously we've done lots of talks separately, but I think today the stakes are really high, and especially when we're representing QA, one of the UK's largest tech learning organizations, I feel we're really having to carry that banner and do a great job. So yeah, let's see how it goes.
So today I'm super excited, we have one of our practice leads who's going to be talking about DevOps and giving us all of the ins and outs of DevOps. Mark Solomon is a master technology architect and an IT strategist, with over 21 years of experience designing and delivering innovative IT solutions at scale using DevOps and agile practices... welcome, Mark.
- Mark Solomon: Thanks a lot Paddy, good to be here, good morning.
- PD: Super, I believe you traveled into London. How was your commuting?
- MS: It was well, it was better than normal. I mean, better than it used to be. Everything was empty. I think I got in here in about 75% the normal time. So I wasn't timing that though, but yeah, it was good. Easy, fast. Wonderful. Hopefully healthy.
- PD: Fantastic. Mark, you've recently taken on the role of DevOps Practice Lead at QA. So I'd love to hear some sort of an overview of DevOps. For anyone that's interested in DevOps, what is it, what does it mean?
- MS: That's the toughest question to answer about DevOps, probably. Not because there aren't a lot of answers that are illegitimate, it's because you risk starting holy wars and arguments and those things. So you just better know who your friends are when you start this conversation... [laughs]
To me, I've been doing a lot of delivery and prep program delivery in architecture for years. With the idea of doing it better and faster and with better processes and automation. This was nothing necessarily new. When DevOps was coined as a phrase, maybe about just over 10 years ago, that stuff was already in place. Continuous integration, continuous delivery. Those were common practices before anyone ever said the word DevOps. So what was DevOps for those of us who were doing it? That's feeling like myself when I was doing it. I was interested, it caught my ear because I was thinking, hey, this could get me home earlier at night. I could spend more time doing what I want to do. So I really embraced it when I first heard of it.
I started to research and the first time I ever heard [of it was] a lecture about what DevOps was. It was a classroom experience. I looked right past DevOps and got to the next thing that the faculty said, and it stuck in my head ever since. This is the definition to me – he was talking more about the lean BizOps. He said in DevOps is where you take the Dev and the Ops, and they work together and you automate things and you break the silos. And eventually, you get to the point where the business and the IT are combined, all the silos are broken, and you go very quickly from idea to delivery and you get that feedback loop. That was beautiful to me. That idea was amazing to me. It was transformational.
I imagined this group of scientists in a room with white coats on, all collaborating, all different experts, thinking about, how do we solve this business problem, this unsolvable problem, only through some sort of an experiment hypothesis. And they come up with something and they put it into this amazing machine, which is DevOps. And the machine runs everything automatically. And it comes back out to that same group of experts. And they look at all the results and all these dashboards, and they gimmick, they mumble, and they do it. Then they make the next thing, they make the next iteration. And that was always the vision for me, that it was really that business goal that we were getting closer and closer to.
And over the last six or seven years, since I've been more involved with the DevOps movement, more of an evangelist for it, I just see things getting closer and closer to that. The technologies are getting closer. The monitoring capabilities, the AI on the Ops side, the low-code environment. So business people can get their hands more on, make the changes... I should say less technical people can get their hands on and make the changes quicker. And so you're getting to that fast feedback loop. To me, that's what it's all about.
There was a definition I heard once which rang true to me and tried to brings us together, which is, DevOps is an engineering discipline that brings business results. Every word of that's important. An engineering discipline that brings business results. It's not practices, it's not defined by a specific technology, or Git, or Jenkins or whatever. And it's not about getting higher IT operational efficiency. It's about business results. That's what it is to me.
- PD: That's great. That's a really good and in-depth definition. And I think for me traditionally, when people talk about DevOps, it's always about the techies. That the techies are always talking about it. I guess from your definition, sounds like the business side is pretty important, right? So in an organization, who should be really caring about DevOps?
- MS: That's probably the other million, $2 million question. Of course, the answer is everybody, because of the way I just defined it, it's a discipline. It's a new way of doing things. And I do get quite evangelical about it. I believe that what we're dealing with here is not a new technology, a new automation, a new product. What we're dealing here is with a revolution in the way that humans are productive, the way that we solve problems, the biggest problems on the planet, whether that be global crises, pandemics, traveling to the furthest regions of the earth, the universe, whatever the hardest problems we have, we need to find ways to be more effective. We need to find ways to be faster, more collaborative. DevOps encapsulates a lot of this and brings it together. So if you're interested in solving problems, and being more effective and being smarter and quicker, then you should be interested in DevOps, in my opinion.
An anecdote I have, I remember, this was before I'd heard the term "DevOps". It was about 2010... I was an enterprise architect for a program in Singapore. And I was realizing how powerful this idea of really amazing DevOps architecture would be to build, highly automated, everything was trackable. I think there was a zeitgeist at the time and I was caught up in it. And so I took my dev team... I had a bunch of developers and I tried to get some of them off to the side and say, "I want you guys to really define the process. Define the process of how we make code, and we're gonna draw it up and we're gonna automate everything. It's gonna be beautiful." Well, this didn't work. A couple of days later, no process drawn, no process drawn code. People did go in and finally, one of them, probably the most outspoken of all of them, took them aside and said, "We're not process guys. We're technology guys." And this was before I'd heard the term Dev and Ops, but it epitomized it perfectly when I heard about it, I remember that individual. My thought to him was, we're all process guys, man, we all do things on a process. We may use technologies, but if you don't know your processes, you got a problem.
So the movement of Dev and Ops is all about DevOps, is about merging those together. Everyone's got a process and technology is just too powerful now to not be involved in almost everything we do. So if you don't have your head around both of them, if you're not thinking that way, then you're going to get left behind. And that's what we're seeing in so many markets.
- JG: Mark, we've got a quickfire round. So it's not going to be really about DevOps. It's going to be finding a little bit more about you, if that's all right.
- MS: Oh, mercy. Okay.
- JG: We've got three minutes on the clock. And so, first of all: what is your favorite productivity tool?
- MS: Oh, mercy. I use Backlog. So they took my favorite productivity [tool], went off the market.... personal Kanban, I guess would be the answer to the question. I use Trello, not the world's biggest fan. I had a pro program called Swipes, and I got an email from them about six months ago. And they said (I loved their emails), "Because we're not able to make a sustainable business model out of our program... we recommend you use these programs," and they just took it offline. I loved those little personal Kanban boards, especially the simple ones that allow you to say, this is what I'm doing now, give yourself a little work in progress. You get to gloat over the big, long list of things you've done. And then you can agonize over the long list of things you haven't done, but you can also coordinate and organize. So those are my favorite tools. I've used a bunch of them, but Swipes was my favorite, it's gone, you're not going to get it, too bad [laughs]. Trello is good. That's what I'm using now.
- JG: A really related question then: So of all the technologies everyone's speaking about, AI, and all this kind of stuff at the moment, what's your buzz-word technology that really excites you at the moment?
- MS: Buzz-word technology... I've got my own names for some of them. So that's it. I'm very excited about event-driven architectures. It's not really a technology, it's a pattern, and as an architect, it's where my brain gravitates to. There's a number of products where we implement this and there's a number of ways to do it, but what's exciting about it as someone who was drawn to modeling and patterns and philosophizing about how to solve problems most of my life... I was into the big monolithic architectures and trying to be the beautiful, strong lattice of programs and structures, maybe up to 10 or 15 years ago where you had the massive enterprise architectures.
But there was something that never quite modeled reality well enough with that, and I think it's because ... you have to always know what's going to happen, and encode that. You have to take very complex organizations or anything. The world is too complex, and you have to understand that, I call orchestration logic, what happens first, then what's the narrative. And nobody knows in there, that's the key. But you have to program this and to control our logic... I don't want to get too detailed about it. But event-driven architecture puts this on its head. And it's a driver. It's the pattern behind the whole microservice and the evolution of the evolving architecture. Everything becomes its own little entity and they define – these are the events that I'm concerned with. And these are the events that happen with me. And you get experts. You get teams wrapped around that little piece of functionality that are experts, not just about the code and the technology, but also about that domain experts. And they define their world and set some events and they react and ... if you do it right, and if you manage the obvious extra complexity that comes into doing that, especially on the infrastructure side, then you get this amazingly powerful, complex adaptive system, potentially adaptive system, but you can't get [that] from a linearly or structured orchestrated system. And you get these amazing capabilities for data, new data architecture, it's like data lakes, and these high-speed cues, and you get all sorts of AI applications where you're streaming and looking at the data as it's coming in from all different sources.
You kind of let go of a little control, to get power, which is a really what's behind DevOps also, right? It's the same thing. It's saying, look, we don't need to command and control everything, let's unleash the beast, let's unleash people and innovation, and we'll get how the world works, how it is. And let's just sit back and put guard rails on it and monitor it. So that would be event-driven architecture.
- JG: Nice. And getting to know you a little bit more then, some personal questions. When you're not doing amazing DevOps-related stuff, where's your favorite place to visit in the UK?
- MS: All right. That's a tough question during the lockdown, right? I was going to say my kitchen. Because it literally popped into my head [laughs]. I haven't gotten around the UK as much as I'd like, but some of the places that I've been that I really, really enjoyed, first of all, was Dover. I went there right when I got to the UK a couple of years ago. And it's, you know, I'm sure anyone who's been there, anyone who's even seen pictures, know how striking and beautiful it is.
- JG: Yeah. It's beautiful.
- MS: And there are so many places... in a previous life, I used to travel for work a lot. And I was always taking the morning trains up to Manchester, out to Swindon. And I can't tell you how many times I just faded out of whatever meeting I was on, which you can't hear on the train anyway, because the sun is rising in the mist over the English country landscape. So breathtaking. So maybe that's my answer. Maybe just outside London. You know, what I mean. And not that I don't love London, but you get a little bit further out there and suddenly you see things that just stop you in your tracks, and you're forced to look at them. I will say that I spent some time last summer in Edinburgh, with the family. We took our family trip up there and I really, really, really enjoyed that. Especially just the graciousness of the people, and the welcoming environment that was up there. So that was a wonderful trip also.
- JG: Yeah. Edinburgh is one of my favorite cities too. So the final question for you: I'm a massive sports fan, but who's your favorite sports team? If you've got one, that is.
- MS: I can't show you the picture, because I've got all my stuff... These guys, the Falcons, the screenshot, all right, they're starting Sunday. I expect everyone to be watching the game. All right, the Falcons have a non-glorious history, but this year things are going to change. So...
- JG: What do they play? I've never heard of the Falcons before.
- PD: I was gonna say the same. I've just seen the picture, I was thinking, is that basketball, ice hockey, I've no idea.
- MS: Cut, this meeting's over, this is done [laughs]. 'Cause it's humiliating, okay. The Atlanta Falcons are the American football team from my hometown of Atlanta, Georgia. They have an inglorious history, full of all sorts of goofs but they've got a winning spirit. And I think they're going to have a good year this year. So if you see me very emotional in any direction over the next four months, it is most likely on a Monday after the game.
- JG: Nice.
- MS: Be prepared.
- JG: Well, back to you, Paddy.
- PD: Thanks guys... Me selfishly, I guess my interest is agile. And I think - should I be thinking about DevOps, and how do agile and DevOps fit together? Well, do they fit together?
- MS: They do fit together. The question is... and I think we have maybe kicked this one around before but not in any depth: are they instances of the same thing? Going back to the pattern... There are manifestations of lean... If you take lean as a set of rules and principles - any process could interpret those principles and therefore come up with practices, i.e. agile practices, DevOps practices, which are on the practice level, they're discernible, they're clearly different. CI is a DevOps practice. Well, maybe even though you could argue depending on what side of the fence you're sitting on, my point is that there are certain things that are specific to a certain area of the process. So wherever you draw that line in the process, which is the agile side, the fuzzy front end, this is the DevOps side, where things are a lot more determined. I like to think of them more as one overlapping thing, to tell you the truth.
And maybe that's because in my own career, and maybe the last six or seven years, I spent a little bit less time doing actual hands-on delivery and architecture, and more time being pulled into the strategy conversations, which I think is what we're all seeing right now. And I think it's because the understanding of DevOps and agile has become so important to so many leaders and to so many analysts out there that they're pushing it. And there are so many great writers and minds out there who are selling the idea. So a lot of larger organizations want to know how to do it themselves. So those of us who have been in there and in the trenches doing it, we get pulled out. We spend more time talking on whiteboards than working with teams.
Where am I going with this? The reason for this is that in that context, to me the lines get real blurry. It almost becomes a tipping point of its own, so well because I see organizations that don't want to define what that agile thing [is] and what they do, they actually make different teams. This is my agile team, and this is my DevOps team... and to me there's something wrong with that.
The both of them are about the entire software delivery life cycle, right? Both of them are, like I said earlier, from that business idea to implementation. And in my opinion, if you're doing it right, both the business and the technology feed back: "What just happened? Okay. Let's think about that and do it again." And the faster you can spin that piston, the better, the more revenue, the more value you're going to generate – that to me has a lot to do with it. So if you start saying, well, this side of the piston is agile, that side is DevOps, okay. It may be useful as a construct to explain things, but at the end of the day, when you're trying to solve the business problem, the whole thing becomes, end to end, it's the manufacturing line. Admittedly.
I forget the person who said this, I keep referring to him, but that fuzzy front end, that's where agile is, it's harder, it's less deterministic. Ideas take time to percolate and get through. And that's why design agile practices like design thinking, which I probably know less about than I should, but those things out there that they're meant to manipulate, those harder, the more challenging harder-to-define processes. Whereas DevOps is, I mean, I hate to say it, but it's coated bureaucracy. It's worse than your worst manager, it's code. It will make things, it will make steps happen. So it's rigid versus fortune which is a little bit fuzzier. But at the end of the day, what I've noticed is, even that rigidity starts to move up the path a little bit, there are ways to automate and structure even the fuzzy front end with agile, so that blurs the lines even more. Ideas like BDD (Behavior Driven Design), even HDD (Hypothesis Driven Design), and a lot of the amazing tools that are out there right now help us capture innovation, management tools are able to capture ideas and start to structure the metadata all the way through to development team and development task. These things are making those concepts less relevant.
So I hope I haven't made it foggier, but it's a bit funny to me. And I could see a time where those terms become a bit antiquated and we focus something on a term, maybe a term that hasn't been invented yet. I've struggled over this for years. It bothers me how bad the terms are. I don't like the terms agile or DevOps, and I have yet to hear the right term to describe at all. So maybe we could do a competition or something to see if somebody can solve this horrible quandary.
- PD: Nice. I think we can safely retire if we get it right, hey Mark, if we figured that out.
- MS: Well, there you go. And let the robots take over.
- PD: [Laughs] Fantastic. So it sounds like having a DevOps mindset really requires us to start thinking differently right from the outset. So I'm going to ask a question to John here, actually: You head up our software engineering practice. I guess, from your perspective, when you're looking at software engineering, learning, what are some of the impacts you're seeing of DevOps? Have you had to change your approach? Are there new ideals that you're having to bring into that learning because of DevOps? What impact does that have?
- JG: Yeah, the concept is so costly, really... I think about my last projects that I was delivering. So one, before we ended the team we were in, we started a DevOps methodology. It was purely chucking it over the fence. All the software engineers were building the features, and then they built the package and then threw it over to the Ops team. And then it was up to them to get it running in production. And then all these different editors hopped in... and the whole blame culture. And then on the final projects before we moved over to QA, and we really started embracing DevOps as a culture, and this quality process of building codes and having that whole methodology – you're not just there to build the features, but I'm going to empower you to actually get that in a quality way – really changed the whole philosophy of what a software engineer does.
I sometimes think about it as a software engineer and a DevOps engineer. It's just a great person who wants to build some code to solve a business problem, but they just don't want to do that in a silo. They want to take that and they actually want to get into production in a quality and an automated way where we can look at the metrics of how to improve that process, or as much as being a business process expert as a software engineer.
- PD: Fantastic. Yeah, I absolutely relate to that. I'm thinking about my background as a business analyst. And for years, with the business analyst I used to work with, it's almost this role where we would create requirements and hand them over the fence, off to the next person. And it was this button in a relay race where I'm done, I can have a break now and I'm going to give it to the next person in the line. But really, that DevOps mindset is about breaking down those silos. And from what I'm hearing from you guys, is it's really about working together right from the outset and making sure it's collaborative all the way through. And just as you mentioned, Mark, that the lines between agile and DevOps, they are blurred, because both really believe in this collaboration approach. So to me, I absolutely understand where you're coming from... Absolutely, they've got their nuances and perhaps specialisms, but they're trying to achieve the same thing, I think, in some way.
- MS: Yeah, absolutely. I wanted to say something else that John said there that I think is really critical. He was talking about working together to get to accomplish something. And the word that came to mind there, which I really think is important, and if you're not thinking about this, you're not doing I don't think either agile or DevOps – that's outcomes, right? They're working towards an outcome. There's something amazing about that. And like I said, this is about human productivity, right? It's about outcomes. It's not about finished code, it's about outcome. The most pertinent outcome is that business layer, and maybe it's not business, maybe it's a charity, maybe it's a science, maybe good, but whatever that outcome you're doing, the reason why, the why behind the why, right? Why are we building this system? Why are we writing this test? whatever... Because we're trying to accomplish something real for humans, right. For mankind.
And that's what it's about. I'm reminded that they said that in the book, Accelerate – Gene Kim, Jez Humble and Nicole Forsgren, they made a big point out of that. That in DevOps, one of the biggest challenges they see about dysfunctional DevOps attempts is that they focus too much on, frankly, results or measurable metrics, as opposed to that overall outcome. And I think that's key. It's hard to measure some of those things sometimes, which is what I think is a blocker, but if you're not doing that on day one, if you're not getting that into people's mindset, then I think you're going to struggle.
- PD: Do you have any examples of where you've seen DevOps really work well? Any recent projects, or teams that you've had to work with, where they've gone from this to great.
- MS: Well, there are endless examples on very small scales, right? I mean, you can make one yourself, you can try to do something one way, and then you get a small team together and do it together. It's sort of a laboratory setting, you can do that. But there is certainly a challenge at scale. And this is what a lot of organizations are finding. It's difficult to get enterprise-wide capabilities and organizations and structures and get them to work at that speed, which is why, again, the lines start to blur between agile and other things, such as cloud and modern architectures, like I was talking about. These things become very relevant.
This is why I'm also very interested in just the whole idea of cloud native. Another name that's not optimal, but it describes really what happens when you try to create an entire environment, both the practices, the architecture and maybe even the people. The culture that allows for that speed. And if you can do that at an enterprise level, then you can accomplish it. There are many examples in the industry. We're all in the UK. There are lots of examples in the UK here. A lot of the financial services industries have made great, wonderful progress over the last couple of years. And there's a wonderful story at ING in the Netherlands... at Sky, I could name all these people. But I think these are all publicly known stories that are out there and you can check them out, and there are wonderful examples.
A personal example I have, and I like this example I want to give here, because you're not going to hear much about technology. And this, as a technologist at heart and maybe a bit of a hobbyist, I say this with some pain but it's also with some just amazement. And that is, I inherited a team a couple of years ago from where I was, right. Where we were running a global... it was a DevOps platform, frankly. We were providing DevOps services for thousands of organizations around the world. And the team was not doing very well. What I had was basically a siloed operations team, supporting DevOps, which was a bit bizarre but we decided to take the SRE movement, [which] had become quite popular. And the thing about the SRE movement, people would debate whether that is DevOps or not, but again, on the principal level, it's about empowering people. It's about using automation. It's about reducing toil, and it's about empowering people to get the information and the decisions made at the level or at the information at the level where the decisions are being made or vice versa.
So what I had was a team of about 15 operations folks, they had a backlog of, my recollection was over 500 tickets, incidents tickets, things that just... some of them were ideas. Nobody even knew what was in the backlog. It was awful. Pandora's backlog. So the month I took over the team, it was right after Christmas, we ran 45, 71 and 72 incidents that month. That means the system was out 45, for thousands of teams around the world, expecting their DevOps pipelines running and all the services we provide. We provided source code management. We provided build services, deployment services. The whole nine yards, my team was overseas. So I flew over there, brought some folks with me, brought a team over there, and got together for about a week. We rented out a room in a hotel, a big conference room, and just figured it out. By the end of the week, the backlog had gone from 500 tickets to 24. The number of team members, this is key. We had increased the number of team members, from about 15 to just under 30, right? And we did this by strategic budgeting, right? We made some moves. We removed teams. We leaned up in other areas. And we beefed up this capability. What were we doing? I wanted my people to have breathing space. I wanted them to be less utilized. The problem was not that we had bad people, and this is everyone's problem. The problem was that we had great people who could not get the work done. We were making them do robotic ticketing work. They have wonderful ideas they were never getting to.
There's a great anecdote. Oh, I'm blanking on all the names today. But one of the founders of Netflix, when Netflix got so popular with us, it really exploded and got on the market. And somebody said, where did you find all your amazing people? The response came back. "I hired them from you" [laughs]. So this was the same thing. We tested this theory. And we put our money into the people, into these folks. We sat there and we learned what was going wrong. We literally took that entire backlog of 500, and archived them, archived them. Boy, we didn't throw them away, but we archived them. We used them as a knowledge base. And we said, we're going to make our backlog right now. What is the best things we could be doing right now? You're the smartest people in the world to know this system. What do we need to be doing? We built up the backlog. We drew some architectures. We applied DevOps practices. We made sure that we weren't forgetting any of those. And I'm telling you, within four months, that team went to one incident pretty much from 44, 45 incidents in January to May – in that five months – it was down to one incident, one Sef one incident in less than 10 total incidents. Right? We had upgraded our entire platform, basically new versions of all of our tools. We had cycled it all out. And I did zero architecture work on that. All I did was get out of the way and made sure no one else got in their way. They had the bandwidth, they had the people and the breathing room. They had the confidence and they... well, they had the budget and they made it happen.
So that would be my story to you, don't forget, don't just come running in there with Jenkins or whatever. If you believe in this stuff from the top, you need to invest in it. And I guess that the exciting thing was that by June of that year, we were no longer kept keeping up with tickets. We were building new stuff. We were building new capabilities, new revenue streams. We were introducing new tools to our system. Right. Which meant that we cleaned up all this technical debt, and now we were IT people [who] were generating more income, which is what's supposed to be doing.
- PD: 500 that turned the bandwidth against 24. That's phenomenal.
- MS: Well, I mean, like I said, we spent a couple of days, we tried it the wrong way, which is good. We embraced failure. We tried to start going through this. And everyone took a cloud and they were going to say, prioritize. You get this room with people and you can just see the pain on the faces. Everyone's like, there's backlog? Oh yeah. I wrote this one last summer. And I don't think it's even relevant. You get that stuff and it just keeps going through, and it's like, you know what? All we're doing here, you all know what you need to be doing. This is the point of DevOps. This is the point of all of this is that you get knowledgeable people that understand the domain, know their job better than anybody sitting off in the big room, right. They're not going to know it, right. Empower those people. Just don't worry about this big backlog of stuff. What do you think you should be doing right now? What would make your job faster? Right. Number one thing. And we named about five things. And then we brought those five things from an epic level down to about five subjects. And it was feasible. I mean, it was down to size and we were able to handle it. Everyone knew what they were doing at work that day...
I didn't mention this earlier... But with that double time, we implemented a 50-50 rule. That's why we doubled the size. And my management team had to track this. Everybody was required to spend 50% of their time fixing stuff. Right. This is right out of the Google book. We didn't make this up. There was some theory that if you [do this] less than 50% of the time, then technical debt will spiral back out of control. Just depends on which way you're going. So if you're balancing it then you're spending as much time running into problems as you are solving. I know a better way to deal with that. I know a new piece of code I could put in there, do it. You get next week off, not off, but you get next week off the ticket system, and you build it in there. That was the process we did. And it worked.
- JG: So Mark, the key question and the whole theme of the podcast is to inspire people into technical jobs. So what would be your suggestion for it, for someone to start a career in DevOps?
- MS: Yeah. Well, that's a question we deal with every day, and especially as we try to build our own teams and try to inspire people to get in there. And sometimes I worry that those of us who have been in the industry for a while, and grown up with DevOps to some extent, we have a different perspective that's hard to communicate. Back in my day when I was a kid, we didn't have these fancy tickets, and I feel started the same way, because the thing is, you guys, and myself, many of our colleagues in the industry, we've seen the other side. We lived with it. We were in that. We were in the income and we were in death marches that were expecting to be death marches. It was like... well, you got into this industry, didn't you, chap. So it was ours to fix. And when the revolution started, in maybe 2005-ish, AWS came out and DevOps, and Patrick Dubois, and all this wonderful stuff. And CICD started coming in. That's why the stuff is grassroots, because we brought it there. It was like this will get us home on time. This is what we want to do.
I wonder if that stuff doesn't land well, I think sometimes folks who are just starting an industry and they hear DevOps and they think, oh yeah, that's a great industry, I'll always have a job there. But beyond that, the CI, the CD, these innovations, which were life-saving and changing for us in many ways, to them is just, it's like object-oriented programming. "Now I gotta learn this thing. I don't know how to do it. It doesn't make sense to me." So I suppose what I would really think, is if you're very interested in this, and this goes for non-technical people too, to be honest, if you're really interested in it at all at any level, and you want to get involved and want to adopt in the way you do your work, I would really recommend that you gotta go all the way back. Maybe no further than the 1990s, and start to understand the rationale and the thinking behind it.
Because until you get the why – take a look from Simon Sinek, here – until you get the why, it's going to be hard to interpret the what and the how. And that's one of the reasons why DevOps is difficult to explain, because in many cases it's a why. And if the what and the how changes next year, because there are new vendors and technologies, or even a new practice, then it's still the same why. And if you're not passionate about that why, for whatever reason, either because it was a game-changer for those of us who lived through it, or you realized the power of it, if you're coming into it right now, the differentiating disruptive power of it, then you're going to struggle.
I found a lot of inspiration from some books that a lot of technologists probably may not find very interesting, which was some of the works of Clayton Christiansen, in the 1980s and 1990s about, oddly enough, marketing and how markets move and how innovation is basically about innovation, about why innovation is important. Geoffrey Moore, Crossing the Chasm, early 1990s, especially if you are very interested in looking at some kind of a startup environment or working in some experimental lineup; of course, the lane startup, Steve Blank, these are folks that'll talk about DevOps, but they're not going to talk about the technologies. They're going to talk about what it enables on a business level.
But there's another piece of that. There's some other stuff that I think that you'd be interested in, and that is the psychological side of it, because let's not forget the culture, and we haven't really talked about it much here, but maybe this is the most powerful piece. It's that whole bit about unleashing the person, unleashing the people. And that's another thing that DevOps does. And that's why I think it's so revolutionary by human productivity, as opposed to more traditional models, where we have more of a command and control, which can be very powerful. I know it's not everyone's favorite, but bureaucracy is powerful, right? You can go in there and to scale, you [have] hierarchical structures and everyone does their part, and this is the way everything gets done. But I think as you transitioned from a task-oriented worker, where you just turn in the screw and go on to the next one, and to a knowledge that we're expected to be innovative, and you're expected to be contributing on an intellectual level and prompt solving problems, that doesn't work. And psychologists have been spamming us with research studies since the 1950s on that, there is something not working about this. We can't just give people more money - and then suddenly they paint the Mona Lisa, it just doesn't work. It's not a function of how much reward they get. I think there's some very inspiring stuff by the work of Edward Deci in self-determination theory on the psychological side, or Dan Pink writes some great books on this stuff. And there's some good stuff on YouTube for that too. Check it out. It talks about autonomy and mastery, purpose, right? The ability.
And you see this in some of the most successful organizations that started off in startups and blew up, they've copied that formula. They've enabled their people to do what they want to do. I mean, I'd love to... everyone likes to be on a team of hard-working professionals that are good at their job and do their work. But everyone loves to be on a team on the weekend or at night when they have the time of people just shooting hoops or kicking a ball around or doing whatever they do, because they love to do it and they want to get better. That's what I want to see. That's what I think the work environment is. And that's what I think organizations like Amazon, or maybe Google, some of these wonderful organizations, Netflix, that's what they've captured. They've captured unleashing the human spirit. So you need to be aware of these things. If you're getting into DevOps in the real essence of the world, you need to be aware of the psychology behind it, and the adjustment and the business ideas behind it, because it'll help you navigate the technology to navigate your own career.
- JG: Thank you, Mark.
- PD: Superb. Thanks for that, Mark. I guess it's a really different way of looking at things. I think for me, often people are focused a lot more on the tools and the techniques, but hearing from you about the psychology behind it is really interesting and insightful. So thank you for that. We are at the end of time. So I just want to thank you so much today, Mark, for those amazing insights. It's been a real education for me personally. So I don't want to speak for John, but I know he knows a lot of this stuff already, I definitely saw him nodding away throughout. So that's always a good sign. And I just want to thank you for your time today. I'll now be rooting for the Falcons at the weekend.
- JG: Go Falcons.
- PD: Go Falcons. And yeah, hopefully we can have a celebratory virtual coffee maybe next week, when we celebrate the win.
- MS: Falcon fever. That's what it's called.
- PD: But then any last words from you Mark, before we closed the show?
- MS: Well, just that, thank you very much for the opportunity here, gents, I always like to talk, and it's also wonderful. I've been with this as my first year with QA, and it's wonderful to be working with you and the whole team here. Speaking of that team where everybody's is going for the hoop at night, that's what it feels like here. And it's a great environment to be in. And I really look forward to what we can do here and working together. Cheers.
