S4 E19 - Andrew Clay Shafer - Unpacking DevOps Evolution and the Future of Digital Transformation
In this episode of The Profound Podcast, I speak with Andrew Shafer, a pivotal figure in the DevOps community and a key influencer in the industry. They delve into the evolution of DevOps, its current state, and its implications for the future, particularly in the context of digital transformation.
The conversation begins with a reflection on the early days of DevOps and Agile, highlighting key milestones and the ongoing relevance of foundational principles, such as those proposed by W. Edwards Deming. Shafer emphasizes the timeless nature of these principles and their application beyond any buzzword lifecycle. The dialogue then transitions to the challenges and opportunities within the industry, addressing the impact of macroeconomic forces, the rise of AI, and the buzz around platform engineering.
A significant portion of the discussion revolves around the importance of organizational learning and the necessity for companies to understand and adapt their processes to achieve true transformation. Shafer shares his insights on the common pitfalls organizations face when adopting new methodologies, stressing the need for contextual understanding and incremental improvement rather than superficial adoption of new terms or tools.
The episode also touches on the concept of platform engineering as a continuation of the DevOps philosophy, rather than a separate or novel idea. Then to wrap up, we discuss the marketing dynamics that drive the emergence of new buzzwords and the critical need for genuine integration and alignment within organizations to realize the benefits of these practices.
You can find Andrew Shafer’s LinkedIn Below:
https://www.linkedin.com/in/andrewclayshafer/
Resources and Keywords:
Books:
"Deming's Journey to Profound Knowledge" by John Willis
"Profound Stories" by John Willis
"Crystal Clear" by Alistair Cockburn
Concepts and Methodologies:
DevOps
Agile
Platform Engineering
Site Reliability Engineering (SRE)
Learning from Incidents
Observability
Chaos Engineering
People:
John Allspaw
Paul Hammond
Eric Ries
Peter Senge
Websites:
Ergonautic website: ergonautic.ly
Transcript:
John Willis: [00:00:00] Hey, this is John Willis. This is The Profound Podcast. One of the things I always forget to do is, I don't have sponsors. But what I should at least sponsor is my book. So don't forget to take a look at my Deming book Deming's Journey to Profound Knowledge.
And then for those who don't know, I have , it was stories that were cut out of the original book, just the book that's out , called Profound Stories. It's like 18 chapters of stories that didn't really fit the system of profound knowledge arc, but were great stories, and didn't want to just throw them on the cutting room floor.
So, anyway, check out my two books and but I got a great guest, you know, one of my really been one of my, important, very important mentors in this industry And dear friend in, in so many ways. And We're gonna, if some of you might already know about the jumping out of an airplane escapades, and Andrew Clay Shafer, I can't, like, [00:01:00] he drives me nuts sometimes like a brother, but I love him like a brother he's, he's been one of my, my cherished relationships in this industry Andrew, say hello.
Andrew Shafer: Well, hello. I'm, I'm, Really certain driving people nuts is my core competency.
John Willis: It's what makes you. Yeah,
Andrew Shafer: I think I might be the, you know, first victim patient zero on that.
John Willis: There you go. There you go. We do
what
Andrew Shafer: we
John Willis: can. So we've done a number of podcasts on my old you know DevOps Cafe, and then we've done, I think we've done one earlier here on Profound, and I thought, I think one of the things, you know, we did one at KubeCon that I did for Alan Shimel once, where I sort of, I think it, I didn't call it, but it's like Andrew Clay Shaper Unplugged.
But like, just you know, I think it's always fun to just hear what your thoughts are about You know, what's going on with the industry and probably best place to start with, like, what's going on with [00:02:00] DevOps? It's going to be 2025, man. What is this? What's going on with DevOps?
Andrew Shafer: So how many years are we in?
I just saw the email for the 15 year anniversary one. Yeah, 15 year
John Willis: anniversary in Antwerp. And that wasn't even really that was that was a cloud camp actually. But yeah, the well, I mean, what? It was the 2009 was the first DevOps day, right? And then
Andrew Shafer: the first one again was 2009. Yeah. Yeah. So there's a, there's a long history of this.
And in my recent ramblings on some of these topics, I, I say that DevOps doesn't really have a beginning, right? It's like these principles. And then I think this is central to a lot of the topics on this podcast, but the, the timeless way of building the timeless way of building organizations predates any buzzword and then, and will [00:03:00] persist past the, the life of any buzzword.
And. All of the same things that Deming talked about and he's not the only one right there's all these other principle based people that we, we big borrow and steal from to try to make sense of this but the, the current state I feel like the buzzword itself right now is in a weird place because there's A lot of macro, forces.
There's the economics, there's the enthusiasm around AI, which you're definitely a part of contributing to. There's the attempt to create a buzzword around platform engineering. You know, there's just a lot of these things. And then I think there's a natural arc to this, which. I witnessed the kind of middle and end up with agile where people are getting the words, they're hiring people who [00:04:00] probably didn't know what they were doing anyway, that say those words, but have good marketing.
And then. Then they're surprised when the little to no changes that they made had little to no impact on their work and the cycle starts over again, you know, with the new buzzword and you kind of need that new buzzword, you know, the new, the new Gartner word to low oxygen to getting funding for whatever shenanigans your organization's about to undertake.
John Willis: But we do, we make, there is progress though, and maybe at the, at the macro level and I mean, I, I guess that's the thing you, you know, like I, I, I jumped in post agile, right? I was a mainframe guy. I did large, you know, scale, Tivoli stuff. And then, you know, I think I, you know, I, I remember, you know, I was saying one of the stories for me of like, is I knew you, you know, cause I, we met at an early O'Reilly conference.
It's logic. That's right. You, you were founder of Puppet and I, I was [00:05:00] sort of, you know, trying to drag around Luke, you know, begging him to hire me for a year or two. And then you were one of the founders there. So I guess you're responsible for not hiring me too. So, but the hold it against me.
Yeah.
But the but we, we hit it off right off the bat and, and then sort of like you know, I remember I started hearing, you know, watching you speak in your presentations, and I think even before it was maybe the second Velocity that I met you at where you did that famous agile infrastructure, because I thought I remembered you sitting on a podcast with Michael Cote and Israel Gatt, and you started explaining to them agile operations or agile infrastructure, and I remember driving in the car listening, and then we drove over to the side of the road, but I wasn't really an agile guy, But it's like for the first time I could see how Agile and what I do connected and I reached out to you.
So, so the long winded point is you've seen this in [00:06:00] Agile, you've seen it in DevOps. Why, why do we keep not, like, we, we make some progress. You know, like these things don't exist without some substance. But then in the end, we're always sort of, like you said, having to come up with new names, like, whoa, just
Andrew Shafer: so we'll come back to whether we made progress or not in a minute but I want to go through a little bit of this story and I've told parts of this before, but my, my birth as a, as a software developer, really these, these kind of like formative goals that you have, I ended up in a startup that was doing this agile thing right after I'd come out of working In an academic setting, really, but I was doing software development and I hated it.
I hated every bit of it. And mostly what I hated was the idea that someone who was the quote unquote scrum master [00:07:00] could just dismiss inquiry into things that were obviously not working by saying, Oh, that's not what agile people do. And that started this, my, my own inquiry into what agile was. And then I ended up spending a lot of time around a group that had sort of centered on Alistair Coburn in, in Utah.
And if you know the whole agile story, then the agile manifesto was signed in Utah and the main reason it was signed there. Not the main reason it was signed or that that group came together. But the reason I ended up in Utah is because Alistair advocated that they go to Snowbird and they, they have this, you know, gathering of people.
And there's a bunch of things to critique about what Agile was then and then what it evolved into. But the ideas that Alistair himself had in some ways, I think, mirror some of the points I'm making right now, because Alistair had this book called crystal clear, and it [00:08:00] has a bunch of these. Points and we could dig it up.
I actually feel compelled to write a blog post about this stuff he did. So he, he was doing research at IBM, I believe. And he wrote his kind of, we'll call it manifesto crystal clear before the agile manifesto. I think 97 or 98. And he, he outlined these things that he thought were critical success factors and he had, he had seven of them.
And I can't remember all of them off the top of my head, but one of them is definitely psychological safety. There's a thing about having CI, ICD and you know, what looks suspiciously like a platform retrospectively through the lens of what we do now, you know, he even used the word configuration management.
Then, then iterative or, or kind of like small delivery access to expert users or the, the customer. I can't remember all, all seven, but I think that's, that's enough to get the spirit of it and, [00:09:00] and Alistair in many ways. Lost this marketing war to scrum. And so then when you say agile in most conversations, what people think that means is that you have a daily standup and you stop writing documentation.
And it doesn't, it doesn't make any comments on really how the work is done or anything to do with the technical or the excellence of that kind of capability in the organization. It's just this abdication to the magic of the ritual. That will somehow make the software out. And, and that's what got adopted under the banner of agile in many places.
And I think that Alistair's wisdom, if you will, kind of got lost in the sauce. And, and I think it's also hard. And I, I run into this in my own work when people want an easy answer, right? Is they just want to put, they want, they want, you know, tab a to go into slot [00:10:00] B and then you have DevOps and. That's not the way this works.
And that's not the way. You need to work copying what someone else did with their, their particular work, because they, you don't have the same context. They had, you don't have the same pretty conditions and you don't have the same winning conditions in most cases. And a lot of people copying. The Netflix, the Google, whatever, you know, change the word to SRE if you want to but you, you're not trying to build a big web app, right?
You have this cyber physical thing, or you have all these other considerations that are critical to your contacts and to your winning conditions. And, and you're trying to copy this thing that wasn't born. To be fit for your purpose and calling that, you know, DevOps and whatever the, whatever the word of the day is, but that that's what I think happens is that you, you have this kernel of, of the [00:11:00] truth.
That manifests itself as an advantage in a context, and then people see that that advantage, and it legitimizes that that practice and those words, and then they want that they want to have that advantage, but they're not in a place in many cases, or they're not empowered. They don't have the, the, the social capital and organization to really make the changes.
And then as soon as that gets legitimized, the buzzword scavenger consulting practices are all saying that same word. And it's, it's nearly impossible to distinguish that the, you know, the moth to the flame. That whoever has the best marketing kind of wins. And that, that's the, the dynamic that I was describing with, with Alistair's work is that the nuance and it depends and you got to figure it out.
I mean, I'll give you just a little bit of the crystal stuff, but if you go into crystal clear or you go into the, the, the book's called crystal clear, but he breaks [00:12:00] down these dimensions of scope, scale, criticality. And he talks about how, The process that you need, you know, the minimum viable process for each of these contexts is different, right?
As you get more complexity, as you get more people, then it shouldn't look the same. If you have, if you have three people in a dorm room trying to hack some together, then you don't need to solve that with, with process at some point. You know, if you have, and this is stuff I put in a lot of my DevOps. As well as there's a spectrum of criticality where on one end of the spectrum.
The DevOps conversation, at least for the, you know, referencing velocity, which we already mentioned, it's the, the problem that Allspaw and Hammond were trying to solve was how can we put cat pictures on the internet? More or less. And that, that manifestation of what it takes to do 10 deploys per day [00:13:00] is going to be somewhat different than as you move along that spectrum towards the transactions and people having money in their livelihood. And then you can go even farther till you get to these systems where life and death is. It is central to the software working right if you have medical devices or weapon systems or some of this other stuff and the the margin for error and the consequences for errors are very different than than just Oh, let's just roll back to or roll forward from whatever we just deployed,
John Willis: but isn't that the sort of bow.
I mean, you know, like The, the, I mean, I think the 10 deploys day, I mean, there's, there's two ways to look at the John Allspaw and, and Hammond's 10 deploys day one. You know, I, both of us were, I think, in the room when he gave that presentation. And, you know, and I just joked that
Andrew Shafer: that's the, that's the birth of the word DevOps.
In this context too. In this
John Willis: context, yeah. Yeah. Right. Or at least all the, the technological pieces of it. Right? Like, you mean I,
Andrew Shafer: I mean specifically just the word, using the [00:14:00] word DevOps came from.
John Willis: Yeah, yeah, yeah, no, you're right. You can get the historian part of like, because you tweeted it out, right?
That's because I've had to correct that that you were the first use of DevOps. The word DevOps. But here's the thing back to like, is there been some good, right? Like, you know, the glass is definitely half full. Based on what John Hammond did by exposing that we could, and there was a lot of prior art, right?
There was Eric Ries, there was all this stuff going around, but it was, that was the story, the story that that sort of broke the news. And like, things did change for the better. So that there's like, there's the. Glass is half full. In other words, that story created a momentum of things that did get better, but the glass is half empty because I totally agree with your point that, you know, that, like, there's a big difference between, you know running nuclear power [00:15:00] plants.
And and putting cat pictures on the Internet. Am I making sense?
Andrew Shafer: Yeah, this is a deep, deep well to dive into. But when we say something got better or didn't, then by what measure? And I agree that there's definitely been these examples, these exemplary things that legitimize certain practices. But if you go into and this is, you know, Related to work that we both been part of, if you go into a lot of these enterprises and you look at what they're doing with these tools, you know, go back in time to the puppet and chef and then come forward to, you know, whatever they're doing with the cloud or with kubernetes and they got this CICD initiative and you look at how they're actually working.
I don't know that it's necessarily always better. In terms of their, their capability as an organization to deliver software at [00:16:00] scale with velocity, you know, there's been progress, but I would not. Here's my take. And this is something. I, I put on some other talks too, but it's a metaphor that I really fell in love with.
During the pandemic, I went down this rabbit hole trying to learn languages and, and I got into this research about how people learn languages. And one of the things that sticks out to me, and I think it's related to the, this technical question. And so stay with me is that we only learn a language to the level of our necessity.
So if you spend Whatever kind of time in a, in a learning thing, that's great, but you don't, you don't learn language from classes. You learn language from usage and to really acquire the language. As soon as your needs are met, you won't, you won't need any more and you'll stop learning. So the. The trick to make progress towards fluency [00:17:00] is that you need to set up this, you know, intrinsic need to make progress to have certain conversations.
There's a whole other deep thing about fluency that I think applies to technology because I think there's a lot of parallels to learning the, the spoken language that humans all use to communicate and learning technology languages and, and being fluent in those. And, and the related thing is. And this, this actually came from a conversation I had with one of my teachers, where I said, what do I need to do to be fluent, right?
And it's kind of the same question is what do I need to do to do DevOps? Or what do I need to do to do agile? And the answer that I got was you're thinking about the wrong way that it's. You're not even fluent in English. And, and he gave a personal story about how he, cause the reason I was with this person who is it's a long story, but he was not native to the language that he was teaching me, but he could speak at a native level of fluency now.
And he told me this story about [00:18:00] how he woke up one day as he was making progress and he, he had all the rules and all the grammar, he can make all the pronunciation, but he could only have conversations about certain topics. Okay. So when we think about our technology, we can only we can only express our DevOps or agile in certain topics.
And if we want to get better, we have to keep pushing into that discomfort at the edge of our capability to become fluent in that new topic, right? So he was saying, I can have topic about this thing. And and I could talk about food or clothing, but I couldn't talk about politics. I couldn't talk about science, right?
So you got to find the boundary of your capability, not think DevOps is something that's done and keep pushing into those edges. But then it comes back to this previous point. Do you really need that? Do you need to be fluent in all aspects of DevOps? Of, of, of quote unquote DevOps to get some benefit, probably not.
And this is like an athletic metaphor, but if [00:19:00] you, if you're on, if you're on the couch, the 5k program, you don't need to be, you don't need to be a hundred percent, you don't even need to be 90%. If you do 60 percent of what it takes, you're going to be able to get to run a 5k. Right. If you want to be an Olympic athlete, it's, it's the, it's that last 5%, 2%, 1 percent the separates those athletes, but for you to just make progress.
Then, then you don't need to do a hundred percent. You just need to do 60%, right? And that's, that's where I think most of these enterprises are. There's a whole nother thing. And, and remember, I don't remember, I don't know if you remember it, but I had a a fond memory of the DevOps enterprise summit talk I gave about, you know, human performance and trying to make metaphor connecting back to that's a great talk, people should go watch their talk, but I I've since.
And, and we won't need to, there's a lot of rabbit holes here too. That, that is the, the presumption of that talk is that you [00:20:00] are healthy. Right. And that you can just kind of improve your performance by doing these exercises that are designed to improve your performance. But I would say most organizations are not healthy.
So if you just go right into this training regimen, where you're trying to Push the boundaries of your performance. In some cases, you're actually going to injure yourself. You know, and this is a metaphor that I think holds for a lot of the a lot of the enterprise, quote, unquote, process is really accommodating some injury that that organization is Some scar tissue that they're holding that they're, they're not, they haven't worked through yet.
John Willis: Well, that's the, I mean, right there, I was going to say that, can we just simply say, you know, something that you've been very passionate about is, you know, are you a learner? I mean, you know, my, one of my favorite all time quotes is you're either a learning organization or you're losing to somebody who is, is one of your quotes.
Is it as simple as a [00:21:00] learning organization? But I think what you're saying is. You know, we buy, an organization buys, gets attuned to the term DevOps. They're, they've, they've been sold that that's the way they have to fix their problem.
Andrew Shafer: They read it in Gartner. Right, or,
John Willis: or, you know, or they saw, you know, even your or my presentation and figured, okay, this is going to be great.
And they didn't, you know maybe they just sort of heard the parts they wanted to hear, or there's some you know snake oil salesmen trying to sell them. DevOps, but either way, your point is they're not, you know, like if they're just trying to bolt on and they're not healthy, but they don't, their, their problem is they don't want to hear in most cases, the like way first, we got to fix all this, no, no, no, no.
I just want that thing. I saw you guys present, you know, that, I mean,
Andrew Shafer: I'm not sure you need to fix all this. What I would, what I would say, you need to recognize. where you're at, right? And why [00:22:00] you're there. And then you can make, you can make lots of incremental improvements towards whatever your goal is.
But I, I think most organizations don't go through that reflective assessment, right? This is the, this is the core lesson of what I would consider agile. But I also think it's the root of everything from Sengi or, you know, all these other kind of people, system Sengi people. It's, it's inspecting and adapting, right?
Most people do no inspection and very little adaptation. They just say, Oh, this is what the, this is what the book said. So we're going to try to do this, but they didn't, they didn't set any context for why they were doing that in the first place. Other than, other than this is what the cool kids do, right?
This is the legitimized practice.
John Willis: Yeah, it's sort of like the copy culture or whatever you call it, right? You know, I want one of those, just give me one of those, but yeah I mean, I [00:23:00] think the the systems thinking is an interesting, right? Like, like, I think, I keep thinking like as you're describing like what are the pieces As a tribe or an industry that we've missed, like I said, there, again, there's definitely glass half full in that, like, there's some, like, we've aggregated a lot of knowledge over the last 15 years.
We've, I think people have better understandings of different points. I mean, you know, again, at the risk of maybe getting you all riled up, I think learning from incidents is, you know, is probably doesn't happen without DevOps. And, and things like, I,
Andrew Shafer: I feel like those, those are little sub genres of DevOps, right?
Like you have, right? Yeah, yeah,
John Willis: yeah.
Andrew Shafer: The learning from incidents, the observability, the chaos engineering, all, all those had kind of primordial, kind spanning and conversations in that same community that came outta velocity.
John Willis: Right. [00:24:00] So that my, I guess the question then is. What is the missing piece? Are we not should have, we should, yes, we, or the aggregate like body of people that work in concert that never happens, but should we have like really focused on learning organization or systems thinking or both, or we just didn't have the, the pyramid of what we were teaching in the right angle.
I mean,
Andrew Shafer: so, so in some sense, nothing's missing. Right. And it's not even an argument that anything's wrong. It's just. What it is, and it's similar. You know, I've already kind of use these metaphors about individuals and their performance and their health, but we see the same thing in our, in our you know, advertising for weight loss or advertising for bodybuilding or whatever, right?
Everyone wants to be. This better version of themselves and they're susceptible to having their hopes and dreams sold back to them that they can just take this [00:25:00] pill or do this easy thing. And all of a sudden, they're going to be able to get to this next level that they want to get to. But in reality, there's not, there's not a secret.
It's just, you just do the work. You just got to do the work. And that's the, that's the thing that's missing from a lot of these. And like we do it as individuals, right? So we can't necessarily. Hold it against any of our organizations, but everyone wants to easy button. Everyone wants to take the pill.
Like, why not? And maybe we get there. Sometimes, but for what we're talking about, in most cases, there's. There's just not a path that doesn't involve doing some work and it looks suspiciously like hard work and oh well if I just pay this one vendor that promised me the world then I'll get it and then they pay and then they're like wondering why it didn't work.
John Willis: One of the things that I thought you you know, we worked together at Red Hat, right, you talked about [00:26:00] making the, well, it's making the, the, the right thing. The right thing easy. Yeah, I thought that was, you know, maybe that, I mean, I, I, I'm not going to argue that there is anything missing or not, but like, maybe that we don't focus on that.
Cause I thought that was, you know, that had a lot. I think
Andrew Shafer: there's pieces of that in, in the evolution of the conversation around platforms. I mean, that's the, that's the central driving kind of platformification argument that I make is that you have all this work you have to do, and you have all these different incentives across your organization, right?
Like the classic conflict between dev and ops comes because. They, they're literally trying to do two different things. Right. And, and so if you, as a organization can make it so that it's easy to do the right thing, then it gets a lot easier for, I mean, it's not illogical, but the, the, [00:27:00] the platform should be able to.
Make and keep promises to both sides and if you don't have that and you're just sort of counting on the conventions or the the goodwill of all the people that have these incentives that are in some cases set against each other, then you end up with all those things. Those classic DevOps pathologies, right?
That those, those two groups, Dev and Ops, have different incentives. One is literally incentivized to try to make the system unstable, and the other one's on the hook to keep it going.
John Willis: Well, so then, you know, going into platforms and, and You know, so the dust is settled, right? Platforms, probably as much as we know now, are the right way, is the right way to do things.
And
Andrew Shafer: I, I've been advocating that platform is the right way to do things for 10 years.
John Willis: I know that. Yeah, no, I knew that. But so and, and I like, I, I don't want to over rotate on DevOps versus platform engineering, but like, if you're going to get the full show from [00:28:00] Andrew, you probably should at least explain, but I, I think, why do we, I'd like to hear, you know, like, why is this nonsense?
I know why it's. I want people who listen to hear why you think it's such a nonsense, but more importantly, why does it get conflated in the first place?
Andrew Shafer: I don't think it's nonsense in the sense. That there's, it's this, it's this kind of Hakuna Matata circle of life that as one buzzword starts to lose its shine, someone else needs to have a funded initiative. Right. And it goes back to people miss the point and they didn't end up with a platform. And I would say that's not just DevOps.
That's every other buzzword. I don't understand how you could, Conceive of doing continuous integration, continuous deployment, microservices, or DevOps without a platform. My, my own personal understanding of what those terms mean. If you're trying to do [00:29:00] microservices without a platform, you're in literal hell.
Like what are you trying to do? But at the end of the day, if you go back through, you know, work I did, you know, some stuff coming out of Pivotal, like there's a bunch of these conversations that go back 10 years. And you didn't end up with a platform and you think platform engineering is, is like a novelty, then, then find the novelty.
Cause there's literally not a single novelty. There's nothing in any of those conversations that wasn't already made explicit 10 years ago in, in a DevOps days. And that, that's fine. But then the second thing, which is related to a bunch of the other themes we've already kind of pulled, pulled out, Pull the threads on is it's, it's the, it's the necessity of marketing, right?
The novelty and, and there's, there's new vendors that have some, you know, little nuanced thing that they want to add as a point solution to that and call it [00:30:00] the platform, you know, more, more or less you have these kind of. service catalog type of things that try to help people make, make sense of their Kubernetes environment.
And they're like, Oh, there's this novel thing that if you buy our product, then it'll make this one part of your problem easier. Although it's usually sold as a panacea. So it's just, and then, and then once Gartner starts making a report about the word or this novelty, then that's fine. Like, okay, we're going to, this is why we can't have nice things, but at the end of the day.
At the end of the day, there's, there's not a single novelty in, in that conversation n neither. A socio one or a, or a technical one.
John Willis: Yeah. So and, and the, your point is like, oh, we've known all this stuff, right? Like, if we go back if we've been at least paying attention, like to, you said, like Pivotal and you know, even. If we saw what Google was trying to do, or, you know, about, like, there's nothing, there's no novelty to any, like, [00:31:00] like, we've had enough strong messaging about all of this fitting together for quite a long time.
Andrew Shafer: It goes to the root of the need for novelty, right? And the, and the, as, as an organization realizes that they've spent this time, they've spent this money on these initiatives. And their expectations were not met that there, there needs to be some new way to inject. Change into the system, right? So then you're you're, however, many years now, 20, 20 plus years into your agile transformation, 15 plus years, 10 plus years into your dev ops.
If someone shows up and they're like, I'm an expert in dev ops, you know, and I'm sure you've seen this before. They're like, Oh, we, we have the dev ops. We, we do the agile, right? And it's like, well, okay, well, you know, You're not good at software or you can't keep your systems running, but, you know, by [00:32:00] all means get a new, new word.
John Willis: Yeah. Yeah. I got it. And so platform engineering becomes the new word.
Andrew Shafer: Right. And we already saw this with the SRE, right? SRE there, there's, there's this like brief moment where there's like SRE versus DevOps and then everyone with a clue, including most of Google is like, Oh, it's just our, it's just our DevOps.
Right. Like we, that's right.
John Willis: Right.
Andrew Shafer: And then that kind of died off. And then now there's like, I mean, there's blog posts, multiple blog posts. I've seen. I actually feel like platform engineering kind of got past AI now because the shiny thing is AI, but the there were there were the series of DevOps versus SRE versus platform engineering, and it was, it was just a pile of straw men, you know, army of straw men set up to say, oh, you know, DevOps means you build it, you run it.
And. And SRE means that you, you measure [00:33:00] metrics. It's like, okay. Yeah. I'm like,
John Willis: yeah, I'll take one here. Here's, here's 50 grand. So I guess I'm trying to think, so where your current company, like, you know, you, Jabe Bloom, Sasha, like, how, how are you guys, I saw your you know, we were in Amsterdam last year together and, You gave a domain driven platform.
And so how, how are you guys seeing how you're trying to solve the problem? Like, you know, you're, you're clearly three really smart people. You've had credible interest, you know, experience. You know, both of us say, Jabe is probably one of the smarter people we've ever known. The, like what, like how, put us all together.
Like, how are you guys trying to help organizations? What, what's. What do you kind of want to ask? What do you
Andrew Shafer: do?
John Willis: So
Andrew Shafer: adding to a lot of the stuff that we've already brought out around organizational learning are, are kind of central ideas that you [00:34:00] should own your process and engineering your process.
You shouldn't abdicate that to trying to copy what someone else did and that you should start with your current capabilities and, and assess Your desired capabilities and then start to build from there. And our, so there's, there's kind of like the team scale stuff that everyone sort of has from Agile and DevOps.
And then there's the larger organizational issue. And what we. Are trying to get people to realize is most of your problems are not always inside of a, of any single capability, right? Like, yeah, your devs could be better. Your ops could be better, but a lot of what your problem is. And this is not just between dev and ops.
This is with security. This is even I'll say between sales and marketing is that you're the boundaries between these capabilities. Have have this kind of turbulent thing. So we're trying to get people to [00:35:00] one recognize the need for these value streams that are cross cutting in the organization to be reconciled against whatever incentives.
At the level that you're empowered. Right. If you're, if you're the CEO, then you have a different conversation than if you're the director of something in the, in the engine room, but you, you try to build coalitions that are spanning these capabilities and, and set up the right kind of metrics and the right kind of cadence to not initially ensure alignment, but give alignment and laminar flow between those capabilities of fighting chance.
Right. So that, you know, If you, if you have, if you have an organization, it's got a DevOps team, an SRE team and a platform engineering team, and they're not all working together and they're not aligned to an outcome before you even get to the developers and the conversations around what platform means to them and developer productivity means to them, [00:36:00] you're going to have a bad time.
So let's look at what you're actually doing. That's, that's the starting point. And we did assessments and this kind of stuff together. I learned a lot from some of the work you were doing and some of yours engagements as assessments, but let's look at what your work needs to be and look at what it is and find interventions and hypothesis that we can test to improve the, the work as done, right?
Not work as imagined, but actually the work that you're doing that, that has, that that's a principle based approach to trying to get metrics. We call them ergo metrics where we, we look at. Okay. This is the, this is the cadence. This is the handoff between these different levels of this organization. And I don't know, I don't know how much time we want to go into my propaganda, but you have if you, if you imagine an idealized org chart, that is, you know, some executives, some middle managers, and some practitioners, [00:37:00] then if you have a disconnect between the, the levels of the hierarchy, we call that D lamination, at least that's what the word we're using right now.
So that is. You know, the C suite has a different idea about what, what the reality is in the practitioners and maybe, you know, there's disconnects at each of those levels. And then you also have all these different capabilities in organization to deliver some value, right? So in, in a web shop as a service shop, you got your dev and your ops and maybe some security, maybe some, you know, sales marketing.
If you get into some of these cyber physical systems or different things, and it gets even more complex because now you have different things with that have, you know, they're depending on the manufacturing, you know, hardware. You know, a bunch of other engineering life cycles that are kind of different cadence than the software life cycle.
And you got to account for that. If you get separation between the communication alignment and incentives of [00:38:00] those capabilities, we call that disintegration. So you have lamination and disintegration in an org, and we're trying to help people think about holistically, are we aligned and are we kind of laminated and integrated.
Between the different levels of our understanding from our leadership to our practitioners, and across the different capabilities that we need to deliver value to the customer, and help people say, okay, well, this is, this is, and this is another thing I say all the time, I've been saying for a while now, is if you show me your org chart, and the funding model, I'll predict everything that's hard for you.
John Willis: Can you break that down? You say that a lot and I love that, you know, and I often quote you with that, but can you break, because it should be obvious, but like, what do you, like, break that down a little bit if you don't mind.
Andrew Shafer: It really goes back to my, my game theory framing for how the, the org chart and the funding [00:39:00] model are essentially setting up a game that everyone's going to play.
And if I can see how you've organized your people and how you're giving them these incentives, then you can kind of predict. Okay. These people are not aligned with these people because of how you've set up this funding.
John Willis: Right. Okay. Yeah. I just realized that was sort of a stupid question. Yeah. No. So Hey, everyone's going to play to win their game.
Andrew Shafer: Yeah. And so we, this is the language we started adopting in our internal conversations and maybe we should make a t shirt or something, but you, you have, you have, I get upset sometimes when people call other people stupid, right? And, and this is a discussion you have all the time where, you know, the, the ops people are stupid or the dev people are stupid.
And, and I. Have whatever reaction to that for whatever reason. But the, the thing that I try to get people to realize is [00:40:00] those people are not stupid. Those people are winning the game that was given to them to play. Right? And so the, if their incentives are misaligned with yours, then their behavior will not seem rational to what you think it should be.
But it's locally rational to them. So the thing that we started our mantra about ergometrics and some of the stuff I'm talking about with integration and lamination is about making the organization globally rational. You can make actual strategic decisions at an executive level and have the work that practitioners do support that strategy.
Because right now what happens is people think they have a strategy, but because they're disintegrated and delaminated, they put that strategy into the machinery and what comes out the other side has nothing to do with supporting that strategy. And if you ask people in a lot of organizations on the Practitioner level what the [00:41:00] strategy is they don't know and how their work relates to that strategy like they don't know in some cases they don't care either because they're not incentivized to so well
John Willis: and because actually like going back to like the the qualitative analysis stuff I've done the you know the sort of is that They, they get apathetic, right?
Because they realize that if the leadership does has no strategy or that they cannot comprehend, why, why should they worry about the strategy, their strategy? If, you know, like, they see such inconsistency, you know, that, I mean, the biggest complaint you get. When you start literally you know, I always say talk to the people who have their hands on the keyboard is they, they have no clue what they're really supposed to be doing because they can't seem to get an answer from anybody above them on what
Andrew Shafer: it's obscured through all these layers of communication that go in both directions, right?
Because you also have that the way the way many [00:42:00] organizations are. set up and incentivize that you have the watermelon report where everyone at the, at the practitioner level thinks it's on fire and red and not working. And then by the time it gets to the C suite it's green, right? So there's this roll up and, and that's, that's doing the executives a disservice too, because now you're trying to make these strategies, but your information is disconnected.
From the reality of the, the ground is like the ground truth is disconnected from what you think you're delivering. And, and then you've, then you put on top of that, this like game of thrones thing, right? So in a lot of organizations, you're incentivized for. Basically kingdom building. Right? So, so you don't get compensated.
You don't get whatever kind of accolades. If you don't do these certain things. And a lot of times that looks like consolidating these big orgs, right. And, and, and not [00:43:00] necessarily cooperating with these other people that you're Well, you're, you're competing with for those promotions and then, and then the leadership did, it doesn't reconcile that because that's the world that they were brought into.
That's the world they're born into. And I just ends up being, you know, this is related to the comment I made earlier about the, the scar tissue and the injury that all these organizations carry forward. So when there's a new buzzword, that's a chance for some, some new champion to get a budget and build an org.
And if that's a possibility. Of course, why you have a new initiative.
John Willis: You know, it's funny when I would do those qualitative analysis, getting near the end, you know, you, you come in, you know, first couple of days, people are like, I hate DevOps. So I'm like, good. Cause I'm not going to talk about DevOps, you know, and then, but what are you going to talk about?
You're a DevOps guy. I'm like, yeah, let's Bear with me. And in the end, they're like, they're getting excited. Like, they're actually getting, they're getting to tell stories of things that are happening. And it's that, like, total disconnect, right? And and then there's this point at which they realize, you know, I'm going to [00:44:00] leave.
And then they start going to, like, Okay. You think anything's gonna change, you know, like, you know, like, like they've had fun. They've like, really feel like they're getting to talk about what the real things on you earn their trust. Right? And and then they're like, well, now the panic sets in. Hey, he's leaving.
What if nothing changes? And the 1 thing I do say is. Yeah, your CIO paid me to be here. That's a good design. Like the fact that most companies wouldn't even invest in that, like, why would we want somebody to just talk to 300 people over three months? Wouldn't that be a total waste of time? They could be writing, you know, the, the, why aren't the shovels being dug deeper into the dirt, you know, the Tayloristic.
And so, okay, you're, you're, you're a CIO is at least open minded to this idea that maybe, Okay. He or she could learn something, but then, you know, like you, you, you sort of do the readout, and then you start getting like John, I don't believe that happens here. You know, McKinsey told us we're the best at audit, you know, like, okay, you know, like, [00:45:00] I would say like, here's your report.
You're going to pay me regardless of whether you like it or not, you know, from the C levels. Yeah, yeah, yeah, yeah. I mean, I've had many times where like they, I was sort of, I, you know, me, I like to put color onto it, but like I walk into their, their, their Oak, you know, like Art Deco, like beautiful office. I put my dirty sneakers on their desk and I would really love to hold a big stogie cigar, even though I don't smoke cigars and say, and they're like, okay, John, how do we do Bob?
Friggin terrible, terrible. Throw the ashes on his desk, miss his ashtray, right? And then, yeah, but what do you mean by that? You know, well, Bob, if you build airplanes, I wouldn't fly on them, right? Like, but like, and they, they, they have very rarely do they have a positive reaction to that. And I'm like, I didn't make this stuff up.
I'm not that smart. I got this stuff from your people, but then they'll, they'll fight me. And like, I, I just can't believe that's true, John. I just don't, I, you know,
Andrew Shafer: I think this goes to the [00:46:00] core of the earlier comments about, is it really better or how have we gotten better? And I've had similar or the same, you know, and you're, you're paying me as a expert to come in and analyze what you're trying to do, and this goes back to early days of this and, you know, fortune will like a low number size companies and you, you go through what they're trying to do.
And I, I, I also learned to. Soften my language a little bit. So you're trying to avoid the immune response to it, but you essentially have these conversations where you lay it all out about what they're capable of doing and how they could improve and what it would look like. And, you know, there's an org design.
Question and there's technical excellence and platforms and all this and, and the response you get from some of these leaders is is there some, is there some way to do DevOps without changing anything? [00:47:00] And it's like, well, no, right. You're not, you're not going to be, you're not going to run that race.
You know, maybe you don't need to run a marathon, but that's not, that's not going to help. There
John Willis: is DevOps without changing anything. Go ahead and bring in McKinsey.
Andrew Shafer: Yeah, I mean, this is something people threw about. And I think there's a few different variations of it, but you can, you can you can buy DevOps, but you can't really.
You know, it's like or or or the way that I I also say it is you get the devops you deserve That's right.
John Willis: You can buy devops, but you don't want to eat it. Well cool. People sell devops, but you can't buy it. I think it's yeah, that's right. There you go. That's a better way. So, So tell everybody where you're you know, what, what, what you guys are doing and how they find you and, and And how do people find you personally?
I mean most people who listen to this Know you are there might be some new listeners because of my book that [00:48:00] oh this Andrew guy is pretty sharp So but I think most people who listen to this podcast will probably know you and you know Probably don't need direction to find you but but in case there are some people out there
Andrew Shafer: So, let's see, where should we take this?
I love Deming, first of all, and I always love Deming and I I'll take some credit for the, your fascination with Deming, but I learned a lot from reading the book. So there's that and, and just having the stories and, and getting a little deeper in, in understanding that that's great. But right now we're at Ergonautic.
And we have a website ergonautically. ly and that is E R G O N A U T I C dot L Y. We have a good time. This is basically organizational learning and the evolution of DevOps in theory and practice is our, is our fundamental mission, trying to change how all this stuff works for [00:49:00] the better. And we, we have a bunch of stuff that we, we talk about and we try to help people do relate to all the themes that we talked about today.
And then if you want to hit me up on, I, I, I hate the, the, the artist formerly known as Twitter, but I'm little idea there. And I'll still. Check that. Although I don't, I'm not very active anymore. Cause I feel like it's a black hole. And then LinkedIn, Andrew Clay Schafer, it easy to find me. And I'll, I'll respond.
If you send me a message and say, you heard me on, on John's podcast.
John Willis: There you go. And then maybe you heard it here first, but maybe not. We we, we think we're going to try to pull off this conference called jump. Con
Andrew Shafer: jump. I feel like jump con almost deserves its own episode, but
John Willis: yeah, you're right. It will.
It definitely will.
Andrew Shafer: We, we jumped out of an airplane together. And that was a great experience for me personally. I [00:50:00] think everyone involved had a good time and mostly wants to go do it again. But then we thought it would be fun to do a conference based on risk and then give everyone the opportunity that wanted to, to go jump from 13.
I think it's 13, 500 feet. Yeah. And
John Willis: that first 4, 000, man.
Andrew Shafer: Woof.
John Willis: The Yeah, no I think we, we, it was about, there was a bunch of us went, did it together, and you can sort of, backtracked and why and the what, but we realized, man, this would be fun. And then just invite everybody and anybody wants to jump, we'll just go, maybe two days of like cool conference technology.
Third day, we'll go out to the field. Anybody who doesn't want to jump, we'll have a big picnic and party. And everybody who does jump can party after they jump.
Andrew Shafer: Well, in some ways GRC never went through the DevOps transformation. And so that's part of our motive too. Is to get that conversation a little [00:51:00] more juice and, and get people excited about thinking about risk and how risk relates to all these other things we were talking about with developer productivity and operational efficiency.
And then it's an excuse to jump out of airplane. Okay, cool. All right. And if you're, if you're so inclined, no, no, no, no
John Willis: one's I think that was our mistake. It wasn't really jump con one, but we said you had to jump and then we lost a lot of people. So this time we'll be, jump is optional. Sounds good.
We're
Andrew Shafer: serious about jumping. And
John Willis: if you, if you want to take the risk, and if somebody like me at 65 can do it, you can do it. All right, my friend. Awesome. Always a pleasure. Hope
Andrew Shafer: the, hope the people like it and don't be stranger. Sure they will.
