Well here we are at SpringOne Platform 2018. You want to introduce yourself real quick? Sure. My name is Kyle Campos. I lead continuous delivery at Smarsh and previously at a large insurance company. Now we just had some crab cakes. Yes. Now would you describe that as a roll that we had it on, a sandwich? You're like me, you're from the West. Yeah. So this is an issue I always have is like you got rolls, you got hoagies. It didn't feel like a roll to me. It didn't feel like a roll. What would you call a roll? I needed a little more height on the bread itself. This was pretty flat. So it was more like a crab cake torta to me. Maybe an untoasted panini. Can you have a panini that's untoasted? I should look this up. Or is it the toasting that makes the panini? It probably is the toasting mechanism because that's a panini press. Yeah, because otherwise it's just a sandwich. Or it would be an unpressed panini. Huh. Huh. Well, there you go. Well, you have a... That's for your other podcast. Sandwiches today. That's it. Let me write that down. Maybe there's a dot sandwiches. Don't mind me. So you have a talk tomorrow. Yes. And I assume it's an evolution of the one you've given before, right? Yes. I like that look on your face. So what's the talk going to be over? So it's essentially around the collision of continuous delivery meeting traditional change management processes. Namely, ITSM and the crosshairs for this one. So the sort of historical pattern of how we get stuff from an engineer's laptop in the production. And then what happens when platforms like PCF come along and just kind of throw healthy fuel to the velocity fire.
2:01Healthy fuel. And then like deal with this now. Yeah, yeah. You know? So yeah, how to manage that. And then also I guess the twist on this talk will be last time when I gave it, I was more kind of pleading with people to believe me about like continuous delivery of pipelines and like that there's a way forward here, guys. Nobody should be, you know, you don't have to panic. There's more a plea. And now there's been a lot of data that's come out to, you know, certainly I didn't author that says I'm not crazy. And so now this will be a little bit more like dancing on the grave than of ITSM than it would have been like pleading with others to like say, believe me. Now I'm just like, yeah, it's just fact. Well, being a grave dancer as it were. Yes. Like you remember that scene in the beginning from Blade Runner where he's like, tell me only the good things about your mother. So tell me without having to shoot me. Okay. So tell me the good things about ITSM. Well, I mean, I think the outcomes of it are admirable. I mean, we don't want production breaking. We want some measure of control. We want some assurance that things will behave in quality ways. So, I mean, you're not going to really come across any of the outcomes and be like, oh, that was totally like ill-conceived. Yeah. It's just how you effectively get there. And whether or not any or many of the processes of ITSM actually deliver on the outcomes is highly debatable. Yeah, I mean, to interrupt you, like, in thinking about the last version of your talk I saw, it sort of like, it reminded me of a conflict I always have in my head of,
4:01I guess it's a baby in bathwater thing of like, is something like ITSM is easier to say. Is something like ITSM bad because it doesn't work or because people suck? Right? And now there's a third option, which is it's bad because people suck. Which is to say it should have structured itself such that it could account for people sucking. Yeah. But on the other hand, it also makes me wonder, like, maybe the problem is, as an ITSM advocate would say, they're not actually doing ITSM. Yeah, I mean, I think it's a natural tendency, regardless of framework, that you get that the principles or outcomes get too prescriptive over time. Yeah, yeah. And so you can, I can imagine continuous delivery ending up the same way. So, you know, in my talk, I might reference pipelines in a kind of specific way, implementation-wise. And then people could, like, say, that's the way continuous delivery should look. And then that becomes the continuous delivery paradigm that none shall violate. And then somebody, you know, the next iteration, somebody's going to kind of like, well, there's actually a better way of doing this. So I think it's just kind of the natural outcome of getting distracted from the outcomes, getting overly prescriptive on how you execute on them. And then you just get rigid frameworks that can't adapt to technical, you know, churn and just advancement, innovation. It can't deal with that. The framework is too rigid. So you need the framework to be, what would be the word? It's probably fresh, not generative, but it needs to be able to evolve itself and have, almost have that learning mechanism built into it. Yeah, yeah, yeah. If I, the last time I read ITAL stuff was, like, version 2, and I think they're on version 5 or something now. I can't imagine it's much different. Yeah. You've read it? Yeah. Well, I read one of the books. It's because I worked at BMC a long time ago.
6:01So we just had these books, like, floating around. And, yeah, and I wanted to know, like, what is the big deal with all this stuff? So I read through it, and it seemed fine. Yeah. Yeah, I mean, it does make me wonder, like, we've almost seen, I don't know what we means, but in the DevOps world, there's this frequent argument between DevOps and no-ops. And I think maybe the no-ops people have learned they should just not talk. Because the argument hasn't come up very much. Yeah. But, like, more and more, like, the idea that I would have an operations person on a product team is not quite as crystal clear as the DevOps name would say, right? Right, right. I mean, what experience do you have with, like, that kind of, I'm going to have, like, three developers and two ops people. Yeah. Does that actually happen? So, I mean, there's some current instincts I would have around that based off of, you know, the app team or the product that is at hand. But, you know, following my own advice about not getting too prescriptive about it, I think that it is, it does seem to be a sort of ephemeral solution for something you want to just kind of push off the table of concerns. You're like, we're attacking it with people that are doing it in a, you know, reasonably modern approach and doing the best they can. And God knows in engineering, we're only doing the best we can at a given moment with what we, you know, frameworks and technology sets we have. So, I'm fine with it. I do, like, present day, I do think embedded DevOps people is, you know, at least an iteration better than, you know, two different, you know, an app dev team that throws over the wall to DevOps people, which isn't really any better than throwing it over the wall to ops people.
8:02Yeah. So, I do think, you know, sort of small, agile teams that it, as long as it, there is no external team that prevents you from getting from your local environment to production, that's really all that really matters to me. Like, I don't want external dependencies. Other people are saying, nope, I'm blocking that. If they have the authority to do that, then they need to get in with, sit in with the team and get that concern pushed as far left as possible. So, that's kind of the guiding principle. And then how that org structure works out across the company, I guess, really depends on the product. Yeah, yeah, and maybe that's like the structural issue with ITSM and ITEL or whatever stuff is, I mean, this is the snarky, imprecise, unhelpful way of saying it, but it assumes that it should exist. Right. Or, you know, from what you were saying, that instead what we should focus on in, as they would say, service delivery, I mean, that's service, that's a whole other conversation. Service is an interesting, it's a problem that having, like, almost had an English degree, you think about words too much. Right, right. Service is a very telling choice of words. So, anyways, the point of service delivery is to figure out how you can have the developers do it all on their own. And developers is a loose term, but to have the product team do it all on their own without needing to put a request in. Basically removing dependencies, which that, to me, that's sort of like a, you know, non-grave dancing version of what's wrong with ITSM. It's just that, like, it's just too much. Like, you don't need that. You can put something else in place that does that whole delivery of the software for you. I mean, that's kind of, you know, the dream of a PAS is to facilitate that. Right. And so, yeah, I agree.
10:03Like, that's the outcome that I want to see develop. Now, interestingly enough, having been through this journey a couple times, it's weird when you get pushback on that from those teams, depending on how baked into old delivery models. Like the application teams? Oh, yeah. Yeah, yeah. So, I've experienced it, for sure, where you're like, you guys are going to get all the control, responsibility. Don't worry about all these other folks. You've got it all. And with that comes some responsibility, right? Yeah. And sometimes it's not attractive to that team. And they don't really want to, they're like, hey, the old paradigm, I just, my unit test passed or whatever. Or maybe they don't even have unit tests. I threw it to this QA guy. And I slept all night. And I don't even see ops problems in production. I don't even know how it's running in production. And that can be appealing to certain app teams. So, I think it's, I think sometimes we kid ourselves that everybody is aligned to the dream of what past delivers. But, I do think, at the end of the day, it's sort of, if we go back to outcome alignment and business value, if the business seems value in higher velocity, higher quality deployments, all that type of stuff, you know. Day two overhead crushed, all that type of stuff. Well, then you get a little bit more top-down pressure on app teams that don't, that are enjoying their sleep too much or whatever. I don't know. Yeah, yeah. Yeah. I was telling you over those, not roles, as it were, like, I remember when, this is like in 2004 when Scrum was introduced in the programming group I was at. But I was, like, I was the kind of person to be self-aggrandizing who had, like, you know, a bookshelf full of, like, agile books.
12:03And I was just, like, excited to, like, go do it. And I remember, I forget how old I must have been, man, in my early 20s. And I was, like, I don't understand why everyone's not super jazzed out of their mind to do this. Like, finally, we're getting to do this thing. But it was interesting to, like, see that actually people aren't interested in that. Yeah. Or not even that. They're not interested in changing how they do things. So, like, that's something else we were talking about is, like, how, I mean, this often falls under the description of changing culture or whatever. Which, like I was explaining to you, I have difficulty figuring out what to say about it in a concise, helpful way. But, like, what, how do you, I don't know, how do you go about changing that culture? Or, I mean, not front load it too much. If someone's reluctant to do things in a new way, what do you do with them? Like, how do you work with them? Yeah, so, I think being clear about the end state, the vision, outcomes that we're driving towards. Like, if there's already philosophical misalignment, like, I don't want the future you want, that's important to call out up front and easy to deal with up front. Much harder to deal with as you get, like, if competing forces are at work, you really don't want that. Like, you can get in a room, draw up the vision and, like, here's the future. We all good with that? Yes. Now, when the challenge comes in the implementation, I think that's easier to deal with. And that's, and actually, I think it's probably healthier that there is a lot of challenge in that, in that implementation. So, I'd say, deal with it ahead of time if it's philosophical. Then, there's no other way but to just get in the trenches after that. If it's, no, we agree philosophically, let's see how it works. I think identifying, so, if I have a working premise that culture, there's a lot of great definitions of culture, but my working premise will be that culture is the collective instincts, like, what people naturally do or want to do.
14:21Instincts are, at least in engineering, and large parts of life are learned. Right. We weren't born not writing unit tests. Well, I guess we were born not writing unit tests. We certainly weren't born writing them. Well, you know, no one is born liking mayonnaise on their french fries, but if you spend enough time around it, that's all you want on your french fries. Exactly. So, we're developing tastes, as it were, to continue that metaphor, we need to develop tastes for the right, that put us on a trajectory towards that vision that we laid out up front. So, you develop tastes by forcing habitual change. So, you were doing, you were eating this today, tomorrow we're going to eat this, and every day, the same thing, over and over, until you sort of metabolize it, and then you crave it, right? So, and the idea inside of that was that you find enjoyment, and people will demand more of what they enjoy. I mean, that's just the reality of people. Yeah, yeah, yeah. They become self-motivated. Yeah, it's what drives, and not only will they demand it, they'll work better, they'll create better products when they love it, right? So, I think at that point, you start, the filtering becomes, who's doing this out of compulsion, and who's doing it out of joy now? And I think the work, and the products, and the good work gravitates towards those who will, who are doing it out of joy, right? Right, right. This is, not only do I know this is good for me, it's what I enjoy doing. The folks that are like, I reluctantly believe it's better for us, but I really hate doing it, you know, you gotta, I mean, that's where, in the trenches, that filtering kind of happens. Like, okay, well, maybe not a good fit for this project, or this, whatever. There's plenty of places that do it the other way. And do you think there's, well, you seem like an optimistic person, so I think I know the answer to this, but do you think there's enough, like, joy and work to go around for all the work that needs to be done?
16:29I don't see why not. We're all, like, the robots haven't won yet. Close. Yeah, yeah, yeah, like, as you were talking, I was thinking, like, you know, back to ITSM, there's always some poor person who has to, like, reset passwords. And, like, who wants, who wants to be on the, you know, the wrong side of the help desk resetting passwords? And I was thinking, like, yeah, but no, no, you just automate that, because no one wants to reset passwords. Yeah. Right? Like, so then, like. Now the no-password security people are coming out of the woodwork. Yeah. I told you that was. And so, it almost seems like that question of, like, is there enough, is there enough people who enjoy their work to fill the need? It's like, well, if there's something that someone doesn't want to do, you should automate it, right? Like, there probably is no reason that a person should manually be doing. Yeah. Like, it's not going to be cheap enough, and it's not going to be done at a high enough degree of quality that you shouldn't just, like, either not do it or automate it somehow. And I think, I mean, I think efficiency is always one reason to automate something, but hatred is a great motivator, too. Like, I hate doing that. And I, I mean, me, as a, you know, as an engineering leader, I'm totally fine with that justification. Like, yeah, I don't want you to hate doing work. So, I mean, if that's particularly painful, then let's not do it again. And this, this idea that you're talking about, of, uh, part of, like, cultural change is working with your organization to build up habits. Like, I think that's an interesting tactical approach because it's, well, on the one hand, because it's doable. Because I think the engineering of habits is well understood. Yeah. I mean, I'm no sociologist, so I don't know if it's all, like, valid science or whatever, but there's a lot of manuals out there of, like, this is how you build up habits and how you do things. And, and then it also seems like, intuitively, it seems like it works, right? Like, most everyone has gone through, like, trying to build up a habit of doing something.
18:30And, and I think what's interesting about building up habits, like, and I'll, it's the habits we all experience, well, usually all of us experience, we're trying to be healthier. Yeah, yeah. It's like, it's really easy for you to figure out, like, well, I'm just not trying hard enough. Yeah, yeah, yeah. Like, you know exactly what needs to happen, and so it's pretty clear that, I mean, I guess you just have to figure out what the habit is you want to build up. Yeah, and there's a, you know, there's a initial sort of hill to climb where it is very, it's a little bit more grueling. I mean, we talked a little bit about the exercise, you know, metaphor, where it's like, you know, if you're an unhealthy person, you're like, well, I know, vision-wise, I need to be a healthier person for whatever motivating factors. That first week of exercise, you're going to really not want to get up on day two and three. You're like, yeah, I don't want to do that. But, you know, everybody that's gone through that will say, after week three or four, like, I don't even really have to think about it. It's not, I just do it now, and actually my body starts craving it because it's, you know, I'm also not trained in really anything, so I don't know why there's science behind this either. But your body will start craving that type of activity, and so you enjoy it. You're like, I love going for a run now. I used to hate it, right? But now I like it. It's, I mean, to demetaphorize it, like, sometimes people suggest that, like, you should just ship one line of code. Like, you should try to apply all this stuff by finding, like, I don't know, change the color of the print button. Yeah, yeah. And see what it takes to actually ship that one line, which maybe is kind of like that first week of exercise where, like, it sounds really stupid, right? Like, we're going to ship one line of code. So there's not much of a result. And it's also, it turns out it's going to be really difficult, but then, like, the next week, maybe you can ship two lines. And then the week after that, ten lines. And so it is just, like, I mean, I imagine maybe that's another part of how you kind of manage change through is to say, like, it's okay. All we're going to do is ship one line of code. Like, let's just do that. Like, no, and you can screw that up, too.
20:32We just got to figure that out. That's one of the things that I think complex change management systems rob you of as an engineer. You don't get to sort of feel the gratification of getting code in production. Like accomplishment. Yeah, you don't get it. Yeah, yeah, yeah. You know, or it's so disconnected from you, you don't even know when it happened or if it happened at all. And that's why I think your approach about the one line is important because once an engineer sort of gets that and they taste it, then they're like, it's kind of like air to them. Like, I want to see my code land there, and if it doesn't get there, I feel robbed of my valuable time and effort. You know, nobody wants to feel that way. But when you're used to not having it, that's back to my point. Some app teams kind of reject the paradigm shift because they've kind of existed so long without even seeing that happen. They don't know what to miss. Yeah, if you're shipping like 5,000 lines of code, like who cares if some of them don't get there, right? But if you've only got that one, you can like own it a lot more, I guess. Yeah, it's like you've got to take that first taste of mayonnaise on a french fry and you'll be fine. Do you like mayonnaise on your french fries? Yeah, I like mayonnaise. There's people who don't like it. I've always liked it. I don't trust them. I don't understand. I mean, mayonnaise is like, mayonnaise is one of those things that if you think about it too long, it starts to get disgusting. But just don't think about it. No, yeah, yeah. It's delicious. Exactly. So then the last thing I wanted to ask you about in, you know, I remember you introducing yourself at some point of like you did like digital transformation or change management or something. And you're like, I don't care what it's called as long as I get to like ship code. And so, but like what do you call that, right? Like I struggle with this all the time is I've, I'm now, I've swung back to just like, I'm going to call it digital transformation until someone tells me a better name.
22:37Okay. Right. But I, I don't know if, I don't know that even that doesn't seem right. But like, is it, what do you call all this stuff? Yeah. So when I first, to be honest, when the first time that I did it, people were calling it digital, it sounded so. Yeah. Weird. It sounded like an alternate nerd universe. I'm like, I've been doing software for a long time and nobody says this. Yeah. Didn't HP buy that company? I know. Exactly. That's like, people are really saying this? Yeah. It took me a while to like, I'm like, okay, I guess people are saying it. So I kind of got in, but I mean, it's, um, when I, when I write sort of the, uh, charter out, it's larger, it's, it's concisely, uh, you know, transforming the way we build, deliver, operate, manage, whatever, software. Um, and so it kind of touches everything. Um, so it is a large transformative effort, whether you want to call it DevOps or, or I, I get, I, I tend not to get into the semantic battles with people cause I feel like I lose, like I'm just going to lose, like someone's going to argue better and like, I'm going to lose the semantic battle. Like, I don't know, I don't feel that strongly about it. So I guess I'm all right with the digital slash DevOps thing, but it is just a sort of comprehensive, um, I definitely never called it agile though. That's one I've avoided. Um, yeah, no, it's hard because like, I think cause different, there are several groups of people who think about each of these phrases as in different ways that, that was, that was no true or a tautological statement than that. But, uh, like, like for example, I think there's a lot of people who would be happy just calling it all DevOps. Yeah. Right. Which, which is not, I mean, I always think of DevOps as a subset of whatever all this
24:38stuff is. And then, and then equally people, you could conceivably call it like agile, but then agile is not, is not a, it's another subset, right? Like it's not the whole thing. And then, and then there's silly terms like digital transformation. And, and after a while, I just like, I don't know what to call this stuff. It's, uh, it's really vexing. And I, I mean, I, I, I was thinking through this a while ago. Like, I think the first time, the first many years I heard digital transformation, I thought, I assumed it meant like, you know, you're going from analog to digital. That's kind of where I was like, what are you guys doing? Are you on typewriters? Is that why you hired me to play? Which, which, you know, there's like, uh, in pivotal land, there's this, you know, famous air force example where they went from a whiteboard to a computer and I was thinking like, bam, there's analog to digital. But, you know, just playing around with the phrase I've been thinking recently, it's not that you're going from analog to digital, it's that you're transforming how you do your digital stuff. Like, like you were just going on, right? Like we're transforming the way we do these things over. Anyways. All right. I'm back in on digital transformation. I'm still not satisfied with any of that, but it is like, we've got to have a phrase. Yeah. Well, and then, you know, software delivery to me is like a comprehensive phrase. Cause it's like, yeah, from engineer to production. I'm like, all right, I'm with that. But then there's also, um, then you're like, well, I'm with that as long as like product, like the product, it's not just software, but like how we're dealing with our products is also like, and the, cause PM is probably like, okay, that's your thing. I'm like, no, no, you're in here too. No, and I, and even my, my issue with delivery is more narrower cause I think of that only as like an operations thing. Like I shouldn't say I think of it that way, but delivery to me means like maybe not the creation of the software, but the delivery of it. Yeah. And even though I like that phrase a lot, software delivery sounds cool, but yeah, I don't know. Maybe, maybe one day we'll just go back to calling it like software that, that, that
26:40would be good. Cause I, you know, I'm sure you've experienced this with coming up with talks. Yeah. Like you can't be like my experience with DevOps, agile, digital transformation, whatever this thing is. It's where the, where it really kills me is when you got to, um, write your bio. Yes. Like, God, what have I been doing for the last, how do you, how do I even describe what I've been doing for the last, you know, decade? Yeah. Like all I ever settle on, I mean, for that kind of thing is like basically, and, and you'll immediately see why this is bad is improving custom written software. I mean, cause that's basically what we're talking about, right? Like you're, you're writing your own software. You're not installing some off the shelf. Mildly improving. Yeah. So you're just, you're just improving the way that you write your own, write and run your own software, which doesn't really roll off the tongue. Yeah. I thought there was a Twitter rant, one of like, like the bad, bad phrasing for things and what I've been doing over the last 10 years. At some point, like full stack kind of came in. I'm like, and at some point it was like, yeah, yeah, that's what it is, what, what I'm doing. And that's kind of like lingered and I haven't really thought about it a long time. And that's then, uh, somebody went on this Twitter rant about like how stupid it is. And then I was like, yeah, that is a really stupid thing. I don't know. What am I, what am I, where is that on my LinkedIn profile? I'm an idiot for having that on there. I know barely anything. I don't know full stack of anything. That's funny. Well, yeah. So I got to go delete that. It's full stack in the sense of like, you know, you don't, you don't worry about the silicon, silicon, right? Like, so the stack. Okay. It's the full stack. I guess that's a referential. I'm going to put, I'm going to put most stack. That's right. That's good. Pretty much all of the stack, sort of. In minus one stack. Right. Of the things I care about. Exactly. Stack. All right. Well, if people wanted to, I don't know, you got a Twitter account or anything like that? Yeah. What would you point people towards? The Twitters is probably the best.
28:41Kcompos. K-C-A-M-P-O-S. All right. Well, great. Well, thanks for being here. You're, you're, you're from Phoenix. I am. I've, I've lived most of my life in Austin. We're enjoying the drizzly weather. Yeah. So we'll, we'll get on back to that. All right. Thank you, sir. We'll see everyone next time.