Pauly: [00:00:00] As a great conductor, I don’t know how to play every instrument, but I know how they should sound and how they should sound together.
Matty: It’s time for Arrested DevOps, the podcast where we help you achieve understanding, develop good practices, and operate your team and organization for maximum DevOps awesomeness. I’m Matt, and today we’re talking with Pauli Comtois, and the show notes for this episode can be found at arresteddevops.com/pauly. So that’s kind of a cool short URL. But first, a word from our sponsors. Arrested DevOps is brought to you by 10th Magnitude, a company that figures if you’re listening to this podcast, you must be pretty cool. 10th Magnitude empowers businesses to better collaborate across teams and achieve IT transformation using cloud. They enable customers to innovate, automate, and accelerate by leveraging the power of Microsoft Azure. You can find out more at arresteddevops.com/10thmagnitude. This episode is also brought to you by Datadog, a monitoring tool that helps bridge the gap between operations and dev teams. Datadog brings together system metrics, changes, alerts, and events from over 120 common infrastructure tools such as Chef, Docker, and AWS, so that dev and ops teams share their key data and alerts in a single place and collaborate on issues in real time. Datadog is available for a free 14-day trial, plus a free t-shirt at arrestedevops.com/datadog. And this episode is sponsored by VictorOps, built for modern incident management, VictorOps provides a unified platform for real-time alerting, collaboration, and documentation. Driven by your IT and DevOps system data, VictorOps helps you to respond to incidents more effectively so you can minimize downtime and making being on call suck less. Visit arrestedevops.com/victorops to schedule a demo or start your trial. Mention you heard about VictorOps on Arrested DevOps and you’ll be eligible for some sweet discounts too. I’ve been wanting to do this episode for a while. I’ve been talking to Paulie here and there, and we just keep saying, hey, we need to have you on the show. And he’s like, cool, let’s do that. And I’m like, all right, cool, we will eventually. And eventually is now. And speaking of eventually being now, the Cubs won the World Series the other day. So what up with that, right? Yeah. We don’t want to turn this into a sportsball podcast, although that’s what it’s been lately. But outside of that, Paulie, can you tell us a little bit about where are you today and how’d you get there?
Pauly: [00:02:30] Yeah, I guess I’ve had a very varied background. It’s sort of all over the map. I started out in, you know, of course, going to college, and then I joined the Air Force and worked on the stealth fighter, the F-117. And that was, that was a great experience for me. It was a sort of very transformative experience for me. And I got out in the late ’90s and went to work in the telecom industry and satellites specifically, doing mostly development work and engineering and I kind of got roped into being a network engineer, sort of by necessity, we didn’t have one. And I did that for a couple of years and realized that wasn’t sort of my calling and moved back into development work and then into operations. And so, I’ve kind of been all over the map. I moved to a company called Silverpop in Atlanta. That was a fantastic group of folks to work with. And that’s where I started really digging my teeth into DevOps. We had some transformations that had to happen culturally and with tools and process, and that’s where found Chef. I actually started out with a couple of other tools, some of them homegrown, and we ended up on Chef back in the very, very early days. And just a very weird circumstance, I happened to be out in Seattle and visiting a friend, and I bumped into a Chef employee. I think it was actually Lamont Granquist at a little bar called Owl and Thistle, which you may be very familiar with. He was telling me about they were looking for an ops leader, and And it just sort of was providence. It just kind of happened. And I ended up uprooting my family and moving from Atlanta to Seattle, which is a large change, both in temperature and culture. And I love it out here. And I don’t think I’m ever gonna leave the Pacific Northwest now. And that’s where I really started digging into DevOps. I was the VP of Operations for Chef for about 3 and a half years, and it was just a wonderful experience. And I got to go out and talk with customers that were at different maturation levels in their DevOps transformation, and we got to help them along that path, both in tools and getting involved in the culture and really getting an opportunity to learn from so many different folks. I received an opportunity from a company called Hearst, Hearst Business Media, and they had 10 business units. Well, I guess they still have 10 business units that were going through a transformational change as well, and each one really looking at moving from waterfall to agile and embracing lean and particularly DevOps. And they hired me on as the VP VP of DevOps. I tried to talk them out of the title, but I think it kind of stuck. I really don’t know any other organization that has this role, although I think it’s really important for an organization that has business units that don’t really interact with each other on a lower level. They really interact more on the sort of senior leadership level. And so, that’s been kind of my career for the last 2 years at Hearst Business Media, is developing a DevOps community across these 10 individual islands and bringing them all together at the engineering and product level. So that we can really see the benefits of DevOps at a very large scale.
Matty: [00:05:41] While I would agree with you that I think having someone in the role that you’re in is uncommon, the challenge that Hearst has, I think, is very common. I think it’ll be really interesting to think about how that’s been effective and some of the challenges around that, because definitely see that with my work at Chef. We actually had a scenario recently with one of our customers where, again, it’s a very large company that has very independent business units that don’t have the slightest idea what anybody else is doing. And so we have kind of, you know, a private community for that customer. And so someone from one of the business units had posted something in there and someone else said, why are you telling us this? Should we know about that? And didn’t even know that that person was from that customer. They thought they were like maybe a Chef person or whatever. And, right. You know, I, we see that a lot. I see it at shows and events when I’m, if I’m working in the booth and someone will come up and like, oh, what’s this Chef thing? We talk about it. They’re like, oh, well, we should think about that? And I’m like, I know that you already are doing it, but it’s a different part of your group, so maybe we can help make an introduction.
Pauly: [00:06:46] We experienced that even when I was working there and working with companies. You know, the first sort of major hurdle for me was to— well, I suppose the very first hurdle was to build relationships with each business unit and sort of begin that journey of trust, you know, that I wasn’t there to change everything or to take over. Clearly is not the role of DevOps and certainly flies in the face of the collaborative effort of DevOps, but it’s also a common fear when somebody comes in from the outside, especially if they have a sort of menacing title, VP, right? Once that trust was built, the next step was really getting over this concept that everyone was completely unique. And so, that sort of common, yeah, I understand that you’re working with software development and SDLC, but we’re so unique, I’m not sure this would apply to us. So that was a very common thread and very common theme was that DevOps probably works everywhere else, but it won’t work here because we’re a unique snowflake. You know, my comment to that was like, well, yeah, you’re incredibly unique, just like everybody else. And in the end, it kind of boils down to, regardless of whether you’re creating software or manufacturing something, if there are humans involved, we have a limited set of emotions to how we respond to situations, and those come into play. And those are very important in how we end up building a culture. And if you want to recreate a culture, we need to be very cognizant of what those are and how those are contributing, right? Once we started to look at the commonalities, drawing sort of this 10-circle Venn diagram, the overlaps ended up being far greater than anticipated by them in the beginning, which was wonderful. You know, you’re using mostly the same language, you’re going about it using the same types of tools, if not the same tools. The only thing that’s really different here are the people, just by name, and the process. So once we started actually bringing people together and talking about that aspect, so don’t worry so much about the tool, let’s talk about how we’re trying to achieve this, and more importantly, what we’re trying to achieve, and starting there and kind of working on the process, then we really started seeing huge benefit to DevOps. And that really comes into this sort of openness, honesty, collaboration, vulnerability between the business units. And we really started to see what I think is the real magic of this, right? Which was, we started to see people helping each other that didn’t even know each other a week ago. And then we saw people jumping in and helping each other during outages. Hey, I’m having this problem, where honestly, I get nothing other than intrinsic value from helping you. So the idea is maybe one day, you’ll pay it forward back to me when I have a problem. That was kind of magical for me. That was really looking at this disparate group of people who really have their own worries and issues and then being very selfless and coming together and working as— no kidding— a community.
Matty: [00:09:50] Yeah. I think it’s interesting that there are a lot of things that— and we’ll talk about that in a little bit about building community. But I think it’s really maybe instead of— we talk a lot about building community, but maybe it’s really more about facilitating community because you’re a community is going to create itself. It’s made up of humans, right? And you can put things in place. You can certainly stymie the, the, the, the community growing, but you can’t— I think you can’t force it. You can just facilitate it, but it’s, it’s going to happen. And I saw some similar stuff when I was, was doing more presales things with Chef and we go in to do a proof of concept kind of engagement, and it would be a lot of people from different parts of an organization, right? That because they’re like, okay, we want to get people because we want to get our bang for our buck in this POC. So we’re going to grab a couple of people from this business, a couple of people from this one, a couple of people from this one. And there’d be people who probably worked in that case, maybe even worked in the same office, potentially even on the same floor. No idea, never met before. And through the conversation of just doing this POC around something else, we’re like, oh, you do what I do. And you have similar problems that I do. And they suddenly start helping each other. And I would overhear things about, hey, let’s get together for lunch next week and tell me how you’re doing this thing with Apache. I was like, that’s cool. It makes me think of the opposite of that. When I worked at an unnamed bank, although you’d figure it out if you looked me up on LinkedIn. I worked there for a long time. A lot of people in Chicago have done so. When I went to Apartments.com afterwards, I was just chatting with some people. We would have these conversations about, where were you at before? So many many people had all worked at this bank before. And there were several people that were close coworkers of mine at apartments that we realized not only had we worked at the same company at the same time, in the same office building, in the same line of business, one floor apart from each other, and had never ever met. And but we probably worked quote unquote together a lot. Like they were dev, I was ops. We talked about, we’re like, oh, did you work on this product? Totally did. I’m like, man, I shipped your code. How did we never even know each other’s name.
Pauly: [00:11:56] Exactly.
Matty: You know, and I can tell you it didn’t work well. So it’s simple stuff like that. I was thinking too, when you talk about this snowflake thing, one of my favorite Sasha Bates quotes is that every snowflake has 6 sides, you know, because just what you said you’ve encountered with the business units at Hearst and you said you saw that at Chef. I see that at Chef a lot, which is the, okay, sure, that’s great, but that won’t work here. We’re very special. We’re very different. And like you said, you’re different just like everybody else. Awesome. But your differences are in this, in some very specific detail. And I think about it a little bit with when we talk about like pipelines and I’m getting kind of into like some weeds on some product stuff. But when we talk about like in something like Chef Delivery or Chef Workflow, right, we’re like, hey, a pipeline has one shape, but everything inside of it is what’s special about you. And it’s the same thing when we think about just continuous delivery in general. It’s like there’s a, there’s general patterns that will be successful everywhere. But by the same token, what you can’t do is go to the other end, which is to say, like, well, I’m going to just copy what Target did, or I’m just going to copy what Netflix did or what Hearst did. Because you know what? You’re not them, right? You have to— like, you can’t cargo cult it. I’m interested with these different business units, like when you were working with them and then maybe they’re looking for some of this transformation. Like, to what level does someone like yourself who’s kind of spanning across and trying to create a consistent story across the larger enterprise, how deep do you go, right? Like, where does that shape happen? And where does the stuff bounce around on the inside and you don’t care?
Pauly: [00:13:38] I think you’ve nailed it with, don’t take a framework and make it dogma, right? And I think a lot of folks end up struggling with something like Agile, as an example. And we saw this a long time ago with ITIL, where I can’t do that because clearly it states right here in the book on page 27, It should be Chef’s approach to Agile, right? You should take these frameworks and make them your own. And I went into this originally thinking, okay, let’s see where we can leverage economies of scale, which was really the wrong approach. It would have been okay to have that mindset had I not actually opened my mouth and said it, right? But as my own sort of framework of, like, I’ll pick those up where they make sense. But as an overall approach, it was the wrong one. In the same way that someone who’s leading a team for the first time comes in and may look at, how can I manage everyone exactly the same? Well, you kind of can’t, or you can’t effectively because everyone’s an individual and even a business unit will fluctuate over time, just like a person’s productivity. We all have ecosystems and environmental factors that determine how we are that particular day. So, I immediately said, okay, I’m not going to care what tools you use. I took that off the table. The reason I took that off the table was the business units really should maintain the flexibility in decision-making because they have all the context on how their business is run and how they should approach creating software for their customers. That being said, there was one level up on process where we could really look at creating sort of some common SDLC approaches so that we could at least say, okay, we’re going to not change for the sake of change. We’re going to say, okay, everything that’s currently waterfall, as an example, we’re going to evaluate whether or not waterfall makes sense for that moving forward. Project-based or cyclical work that has a defined start and end date that’s the same every year, those are maybe things that we don’t do agile on. That was a big change because a lot of folks wanted to have this sort of big bang approach. By August of next year, we’re all going to be in the cloud, everything’s going to be in the cloud, and we’re going to be 100% agile. And again, I think that For an organization that hasn’t exhibited change or experienced that type of change at that volume for any real length of time, some of these businesses are quite old, it’s sort of a shock to the system. So, you’re teaching someone to swim, but not even by just easing them in, you’re throwing them into an icy pond, and then wondering, why is this not working? We sort of backed off of that, and I said, let’s just focus on process. Let’s figure out where changing process makes sense, where it adds value. And let’s do that iteratively. And in that way, we can kind of learn the Agile approach through just changing the processes slowly over time, not even talking about Agile as a methodology for creating software. And then we ease into Agile as a methodology. And the whole time, we’re sort of underlaying all of this, this foundational work on sort of DevOps core principles and approaches, so that we’re simultaneously kind of turning the water up on the frog, where we’re saying, okay, you know, why don’t you go talk to that person instead of just sitting here making an assumption? And then we start opening these lines of communication. That’s been very valuable to us because it allows for positive change without it feeling too much like someone is dictating the change. We’re doing the change together. It’s a very collaborative approach to change, which can be— you know, process change is hard because people you get kind of emotionally attached to a process, right? Cultural change is actually even more difficult because it’s so deeply ingrained into how you even just think about your company and how you operate inside of it. And so, because of that muscle memory, we don’t even really think about it very much. And then when you say, okay, we want to change this, it has to be done sort of slowly, and it has to be done holistically. Earlier, you were saying, It’s more about sort of facilitating that change. I completely agree. And facilitation is sort of guiding rather than dictating. And also, you have to understand that in that facilitation, there are some folks who are just not going to want to come along. Some folks are just going to say, I don’t agree with any of this. And the facilitation there is to maintain a sort of positive, forward-thinking focus on that.
Matty: [00:18:18] I’ve seen similar stuff, and I’m sure I’ve told this story on the show before, so long time listeners can be like, okay, Matt, you’re selling, telling the story again. But I had a sysadmin who worked for me, and we were talking about making a change to process and how we deploy stuff, and it’s something like that. And his thing was, well, how are we going to make the developers follow this, this, this model, right? And it was a lot of like, who’s gonna fire them if they don’t do it? And I said, well, the way you do it is you make the right way the easiest way. You know, I felt validated then when I read the book Switch about change management, and they talked about the happy path, right, the easy path. And that’s, I think, really true for a lot of people because again, the change in process, I think you’re right. Sometimes we’re emotionally invested in the process, but a lot of times when I feel like anywhere I’ve been where they’re like, now we’re changing the process. And again, it could be like, hey, guess what? Our legal process is different now, or the way you request time off is different now, or anything like that. We feel annoyed by process change because doing the process or learning the process is not our job, right? That’s not our adding value. We’re like, great, here’s another thing. And now it’s not— you said it’s not my muscle memory. So everything I do is harder now because I have to do that. However, if I’m like, oh, this new way is super awesome because it’s easier, then I’m going to just go down that path. And I think when we make it such a way— and a lot of times I’ve seen where people will say, well, we should do this because it makes it better for Team A. As humans, we probably do care about Team A and we want them to be better. But when push comes to shove, if I need to do a thing and it’s like the only reason to do it this way is to make somebody else’s life better, and I’m in the middle of trying to put out a fire or ship some code or do something, all that’s going to do is annoy me. But if I am like, oh cool, this is much better. And the thing is, if it’s not making a lot of people’s life better, then we’re probably missing somewhere. And not every process is good for everybody. Again, like giving, going back to that example of maybe legal review of a contract, you know, for a consultant, you’re like, okay, well the overall process isn’t delightful for me, but is there a way that makes me happier about it? Or is Is there a way that if I’m introducing this change, there’s a win for everyone somehow?
Pauly: [00:20:32] Having run operations teams for so long, we get so mired sometimes in the day-to-day brushfires that we don’t take time out to work on fire prevention itself. We talk ourselves into believing that it’s too much effort. So, if you can show that, one, that you’re going to receive a lot more value out of this investment both intrinsically and extrinsically through it being easier and genuinely making your life better day-to-day as an operations person, you’re more apt to have people want to organically join that transformation as opposed to trying to drag them along.
Matty: It’s about user experience in a way, right? You need to, if you want to, you’re shipping a change, in this case, it’s a cultural or process change, But it has users, it has customers, and the UX of that change is super important. Because if you’re shipping a product, if you’re shipping an application and the UX is terrible, you wouldn’t kind of ship it and say like, okay, I know this UX is awful, but just trust me, it’ll get better later, but you should totally use it now. Customers are kind of like, well, no, because this is really hard. I don’t want to do that. And I’m having a terrible experience. And I don’t mean like build like a super awesome you know, Angular-based, you know, continuous delivery pipeline with lots of pretty buttons and flash and material design, the actual experience of using it, right? Like, okay, I’m going to put this new process in place. What’s it like? And I think that’s one of the things that maybe we don’t always think about when we’re designing a process is kind of going through that and saying, let me put myself into my customer, the ops person, the dev person, the QA, whoever. What’s their experience gonna be like actually doing this?
Pauly: [00:22:19] Absolutely. And one of the things, I sort of have sort of main tenets that I practice and sort of preach, especially when we’re just starting out, I think of them as core principles for DevOps. And one of them along sort of an architectural path, you should always be working with the downstream work center in mind. And that downstream work center will eventually be the customer. But along the way, as you’re saying, there’s many customers in that value stream, and they’re just as important. When you think about Mary Poppendieck and all of the different types of waste, if you think about every time that you get a product that it’s your turn to work on and you have to send it back or go back in these feedback loops because you can’t work on it right away, that’s that percent C&A or percent complete and accurate. That’s waste.
Matty: Well, it’s tough for the people that are doing this stuff, right? You’re introducing waste, and waste, maybe one of the easiest ways to make that feel like hammer home is What’s one of the things that people hate wasting the most? Their time.
Pauly: [00:23:22] Absolutely right.
Matty: Like, if it’s this general theoretical systems thinking idea of waste, that’s cool. But like, if you’re like, hey, when I do this, there’s this, this person that’s on the level 2 help desk, and I’ve just added— I’m now wasting 20 minutes of their day, or every time they open a ticket, they’re wasting time. Boy, wouldn’t that annoy me if somebody else wasted my It’s, again, it’s putting the human face on that stuff. And I think we’re doing a good job maybe starting to think about our external customers as humans, but thinking about internal customers— and I really like your guiding principle of having the downstream operators being a part of that, because the bigger you get, the more distanced you are from understanding that, or you may even be so far abstracted away to not even know that there is this role within this team, within this sub-team over there. The thing is, those folks are actually probably the ones that are going to be the most impacted by this in a negative way because they probably don’t have a voice. Everything’s a product, man. That’s, that’s the way that I look at it. And that’s what I tell people with cultural transformation. I said, think about it just like a product. Manage it like you’re managing a product. You’ve got someone owns it, someone makes the decisions. It should be based on experience, based on feedback. And be able to iterate on it. And, you know, it’s like Damon said, all this DevOps stuff, we should just call it common sense.
Pauly: [00:24:48] Exactly. Well, and that’s why when people say, how long have you been doing DevOps? Well, I think I’ve been doing it my whole career. We just didn’t call it DevOps. We called it just being open to each other and collaborating and talking to one another and just doing things that made sense. Like you said, you know, everyone is a consumer of a product. Internally and then even externally. And the nice thing about that is it also means that somewhere along that path, someone always cares about it. Someone is being impacted by it. It matters to someone.
Matty: Yeah. And if, and if it doesn’t, well, then, you know, you can, you can kill it, right? Like, that’s part of that evaluation. You may go through this and do enough and say, nobody actually cares about this. So it’s not wasting anybody’s time. It’s wasting existence time. But I think there are a lot of things in how we do stuff that really matter to people. And you have to figure out now, it may be— I almost said maybe wrong that it matters to them. That’s probably not the right way to think about it. Maybe it is wrong. I don’t know. But to kind of, again, be able to understand, like, why is this really important to you? Why do you care about it so much? And because someone there— there’s a disconnect, right?
Pauly: [00:26:03] Right.
Matty: Someone’s got to get educated. Either the person who cares about it a lot may need some education that they that there’s a way that they could care differently about it, I guess.
Pauly: Sure.
Matty: Or the other person may say, you know what, I didn’t think this was important and now I do because I now do understand because someone who cares about it has made me understand it. Because before I just saw it as a little checkbox in a value stream map and now I’m like, wait a minute, there’s this team of 6 people that do this particular thing all day long and I just knew about it in the abstract. That’s got to be really hard at your level of what you’re trying to do to understand that granularity because you’re looking from a certain level, right?
Pauly: Yeah, you know, it’s funny you say value stream mapping. The value stream mapping workshops we’ve done at the business units has probably been the most powerful and informative tool that we’ve used. I didn’t expect that to be true, and that’s really because of getting all of the players into the same room at the same time so that you get all of these sort of opinions and facts out. At once. And earlier when you said someone may care about this and maybe it’s wrong that they care about it, turns out most of the time people are voicing a concern or a care about something, but that’s not actually the root cause. They don’t actually care about that thing. It just happens to be a product of what they care about. And so you start digging into that and then you start finding out— it’s sort of like asking the 5 whys. You keep digging in, okay, why did you do it that way? Why did you care about that? And as you dig through that and sort of peel that onion back, it turns out you don’t care so much about that product or process, but that thing impacts something else that you do care about. And so fixing the output doesn’t fix the cause. I joke and say it’s sort of like saying, okay, well, I go to the doctor and I’m diagnosed with lung cancer and they say, okay, here’s a cough drop for your cough. And I’m like, Well, that’s great. I appreciate you treating the symptom. What about the disease? I see a lot of that. I see a lot of, like, well, let’s just do this thing. And say, well, that doesn’t really address the sort of underlying problem here. As an example, if product is pushing features down and you’re not getting enough information on the dev team on what you should be working on, and you go back and say, hey, I need more information here. We need to have a tighter feedback loop so that we can kick off estimations and start this whole process. And they say, yeah, we’re already working on the next feature. Just go and do whatever it was we said before. And it’s okay. And you go off and fix it. And then the customer says, well, we wanted this as blue instead of red, but that was never defined in the specifications. You say, okay, well, we’ll just change it. We’ll just change the color. But what you’re not addressing is that this is gonna continue to happen, right? Right.
Matty: [00:28:52] It’s that reactive. It’s like, okay, cool. And the customer is at the moment totally happy. They’re like, great, ’cause all I wanted was blue, you know, or whatever. But it’s like, then they’re gonna be pissed off the next time. And the problem is, the next time it’s probably not that same customer, right? So the systemic problem in the organization is never really seen, right?
Pauly: Exactly. And it becomes a self-fulfilling prophecy in that, that feedback loop that goes up through support and sales seems like the customer is happy, so it sort of validates the behavior in a way. And so we don’t really see a change. What we started doing by doing value stream mapping was showing through science and math, right? We use Little’s Law to do efficiency ratings. And we said, okay, listen, this is your lead time and your process time, and this is your percent CNA, and this is the current process. And these are all the WIP and bottlenecks and handoffs and frictions and barriers to flow, and all the issues that you’re seeing here, which you probably already had a gut— most of the time everyone’s like, yeah, my gut tells me the slowdown is in QA, is the long pole, or maybe release into prod, Right? And so you kind of already kind of know it because you live it, but now you have actual numbers to help you go back and say, okay, we’ve identified this, now let’s figure out how we create a tangible plan to resolve it.
Matty: [00:30:06] Yeah, I mean, like you said, you’re identifying it, you’re making a decision based upon data too, right? Rather than gut, because when we make our decisions based upon our gut, that’s when you’re gonna have that reactive kind of decision, right? So maybe this customer is screaming, and so we drop everything to help that customer, and Versus saying like, actually, that’s probably okay that the customer is screaming. They are just a screamy kind of person. Right. And they’re actually super happy. But in the meantime, I have this other customer who, by, based on either their organization or personal personalities, just goes along and just doesn’t renew or doesn’t, doesn’t buy my stuff. They fail the trial or something like that. And they never tell me anything.
Pauly: Right.
Matty: And, but that was all based on my gut, right? Because as a person, I’m like, if you’re yelling at me, you’re mad and I should pay attention to you because you’re yelling. Right. But that’s not maybe driven by data because I could be like, hey, Paulie’s yelling at me all the time, but geez, he buys a lot of widgets and he keeps buying more and more and more.
Pauly: Right.
Matty: So that’s, it’s okay. He just likes to yell at me. That’s fine. And then, you know, I’m like Trevor over here, he never yells at me, which is cool, but every month he’s buying fewer and fewer widgets. So maybe we should talk to him. Right. Because maybe he’s organizationally introverted. I don’t know.
Pauly: [00:31:21] Sure. Yeah. It’s better understanding of your audience and your customer. Right?
Matty: Yeah, I mean, it’s— data is everything, man, even about humans. Um, it’s just that it’s not nice and pretty necessarily, not necessarily number data. That’s sort of my thing, right? I think there’s this thing where we feel like you have to measure things if they’re numbers, and I don’t know that measurement always equals quantity.
Pauly: Sure, so quantify and qualifying, right? Yeah, yeah. It’s okay to let your gut help you, I think that’s important. In fact, you know, that’s how we make decisions as humans, is we think back on our past and things that have worked before and our previous experiences. I think where we run into problems is when that becomes the only way we do things. And we’ve experienced that, and you’ve experienced it too. You’ve been in organizations where it just kind of feels like we’re flying this plane just on sight, and it’s at night, and there’s no lights. So, it’s kind of like, where are we going? And I think that people fall into the sort of the other side of that spectrum, which is where they only stare at their instruments and they never actually look outside the cockpit. It’s a good balance, and we’ve found that value stream mapping has allowed us to really start the conversation, if not actually provide data points that help us to make decisions.
Matty: [00:32:39] And it’s a pretty collaborative kind of work too, right? Because you’re saying, okay, we’re understanding all of the parts, and maybe it’s just that, you know, my experience is sometimes it kind of like, like maybe we need an easier word for it for certain folks. Maybe, maybe that’s going to be my next mission is figure out how to like have a technical infrastructure person type word for value stream mapping that doesn’t sound— and then, then we’re like, oh, I get it.
Pauly: Yeah, it feels very salesy, VSM. You know, it’s funny too, I’ve done a bunch of these now and consistently there’s one person that that has the same body language and sits with their arms folded and just kind of, you know, sucks their teeth and rolls their eyes and just is a complete nonbeliever. So it’s kind of funny, I guess. I guess you can’t have one without that individual. It must be a prerequisite of something.
Matty: I think so. Yeah. Otherwise you’re not actually mapping your value stream if you don’t have the heels dug in.
Pauly: [00:33:41] You know what, to be fair, that person should have representation.
Matty: So, Yeah, yeah, ’cause they’re actually probably the more dug in they are there, they probably, the reason they’re crossing their arms and digging in is ’cause they have a lot of feels about how stuff works.
Pauly: Well, and I’ve also found that that person, you know, don’t let them be a silent objector, because they’re the ones that are oftentimes gonna give you the raw truth about what’s going on anyway. They’re not gonna sugarcoat it.
Matty: And I’ll just, yeah, say too that not only are they not gonna sugarcoat it, we can also miss on our body language in terms of, I mean, it doesn’t mean that they’re against it, but I can just, again, this going back to the whole thing about that I don’t know shit about anything, which is my professional everything. You know, I remember very specifically doing like a proof of concept on a chef thing with a customer. And there was one person in our POC who I was just so worried about, ’cause we’re going through it. And I know, you know, we were gonna end the week giving this presentation to stakeholders about what we did. And I’m like, this guy is so upset. He’s hating everything we’re doing. I mean, how— and I was already kind of thinking like, how do I manage around this in our presentation? And then we got to the thing and he basically said, listen, we need this right now, go buy it. And I was like, wait, I thought you hated everything we did. And it was just, that was his personal way of being. He was very blunt and, and felt actually probably in a really safe environment for us to be able to talk that way. And I was like thinking that this was an adversarial thing and he was our biggest champion in the room. And so I think we basically, yeah, need to understand that people that may— if nothing else, if you’re being adversarial, you’re engaging. And I think that’s kind of what you’re getting at, right? Like, don’t let someone just sit there. They probably really have a lot of feels. And let them engage. Not only let them engage, encourage in that engagement, because there’s something to kind of unlock there and understand.
Pauly: [00:35:40] Absolutely. And, you know, try not to have presuppositions, right? Just like you’re saying. And a lot let that individual have an opportunity to communicate in a way that they’re going to feel comfortable communicating in. I mean, part of being a facilitator in there is, in the end, while I can help with the actual plan, the transformation plan, and the implementation of that, in my particular role, I’m sort of like a consultant internally, but I never leave, which is great, which is probably the most powerful thing of it. That individual is now going to have to live in that ecosystem. I don’t live in the BU. I live outside of the business units. And so, that person really should have a voice and be able to sit there. They should be able to sit there with their arms crossed, even if they hate it, even if they don’t like it, because in the end, that person is either going to jump on board and really help this transformation, Or in another extreme case, maybe they opt out and say, listen, this is the direction this organization is turning now, and it’s just not one I’m comfortable in, and so I’m going to opt out and go find some other organization that I can be more comfortable in. By the way, I think both of those are perfectly okay and reasonable outcomes for that. I think we tend to look at someone leaving an organization as it being very negative, and I just don’t see it that way.
Matty: [00:37:06] No, I absolutely agree, and I think that goes back to what you’re talking about about earlier, and you said like, hey, you kind of have this curve, right? And there’s some people that are going to come along a little bit later and some people maybe never do. And it’s, it’s not necessarily— I think sometimes we might because we get all jacked up and excited about this new direction of our organization. And then the people who are not drinking that Kool-Aid, so to speak, right? We’re like, well, that’s a failure on their part. And it’s like, well, no, they’re just— it’s just different. And the problem is trying to, in either case, right, trying to put someone into a place where they’re not comfortable. And they’re never gonna be comfortable. I think it’s okay for people to go outside their comfort zone, but if you’re never gonna be comfortable there, because then it’s a failure on both sides, right? It’s no good for either side of that. It’s bad for the organization, and it’s really bad for the individual.
Pauly: Absolutely. And I’ve definitely seen people trying to push engineers through this transformation. And the really unfortunate thing is, they tend to do that when the engineer in question is, like, the top-performing developer or top or a Brent, if you want to use the People Project, right? And so, the concept there is that I can’t lose this person, so I can’t let them not come along. And then they just kind of hit them in the head with a hammer and try and drag them, which, of course, doesn’t work out for anyone involved. The organization suffers, the individual suffers, and invariably, it ends up with a separation anyway, where the person says, all right, I just can’t do this anymore. And you can see those things happening at the beginning of these transformations. You sit in a lot of these meetings and you start talking to people. I’m sure you’ve experienced it when you went to customer sites with Chef. It’s really important to kind of be aware of when those things are happening. And oftentimes, that Brent is someone who genuinely cares about the organization and the product and the customers and really wants to do a great job and really wants to work for a high-performing team. It just means that maybe you need to approach this transformation with that individual in a different way.
Matty: [00:39:11] Yeah, it’s something, uh, Adam Jacob said. He’s like, most of the people out here, they want to do good work. And a lot of us have not had the opportunity to do good work in a really long time. And I think that’s the thing is, especially when you can unlock that for someone, that the goal here is to do better. And not that you’re doing bad, but you want to be able to like do even better. And facilitating that. And some people don’t, right? And that’s the other thing too, I think, is really kind of hard. I think for a lot of, a lot of us in this particular kind of part of community, or this kind of thought about it, is that there’s still a fair number of folks out there who are like, I just want to come and I’m gonna do my thing for a couple hours. Or, well, probably more than a couple hours, but that’s— well, if it’s like working in any office, you get about 2 and a half hours of actual work done in the But they really aren’t invested in being the tip of the spear and the bleeding edge and doing all the cool rad new stuff. And that’s totally fine, right? Like, because— and that’s, I think, again, getting back to this understanding of when you’re trying to get a change with anybody. And we, we talked about this when I had Bill Joy on the show. Now I’m looking, it was a long time ago, it was episode 33. So if you go to restodevops.com/33, you can hear me talk with Bill about this. And we talked about kind of like, when you’re looking to influence change, you have to understand drivers, right? And so everybody, you know, says go read the book Drive, and really you just need to watch the TED Talk. But right, if for me, I can be totally wound up about this stuff because I think the technology is super cool and I, you know, want to like do things in the most awesome way and be super rad and new. And if I go try to sell it that way to someone who’s like, my thing I get enjoyment out of in my life is not awesome technology. It is, you know, being able to have good stability for my family. I’m not saying the two things are mutually exclusive, but whatever. Then all that’s happening there is they’re going like, oh, this sucks. You’re making me change to do a thing I don’t even care about. But the reality— so it’s a lot of— I thought it was a really good thing. Like you said, you’re an internal consultant, and anybody who’s trying to affect change inside an organization is not only a consultant, you’re also a salesperson, right? Absolutely. You have to think like a salesperson. And, you know, your best salespeople know what’s important to someone and how to not convince— that those are loaded words, that like, like you’re pulling the wool over their eyes— but just know how to speak their language. Like, hey, I, I gave a talk about this. I just remembered my silly 5 Love Languages of DevOps talk, which I’ll probably put a link somewhere in the show notes. But it’s like understanding we all have different approaches to it.
Pauly: [00:42:01] Absolutely.
Matty: I was going to say, speaking of talks, something I wanted to ask, get your take on. Our listener Michael Lombardi had asked, you know, kind of thinking about conferences and culture. So his question was, does it behoove organizations to pay their employees to attend conferences? And also he said, do you think organizations should pay their people to speak? You know, kind of thinking about organizations that make people attend conferences on their own time, on their own PTO maybe. So I want to talk about that. And then also, I might have read the second question a little differently when you said organizations paying their people to speak. First of all, like saying if you’re going to go speak at an event, are you doing it on your own time or is that part of your normal job? And then likewise, or are you also maybe being even or even further of a pendulum swing and say, are you being extra incented in an exemplary way saying I’m going to offer additional compensation if you’re going and speaking at an event? So kind of what’s, what’s been what you’ve seen? I mean, I kind of feel like I already know what you’re going to think about this.
Pauly: [00:43:04] Well, you know me pretty well. Yeah. I think that people should be able to go to conferences and not have to take PTO for it. I think the company should pay T&E. That being said, I also think that there’s a certain amount of common sense that goes with that. I would love to go to the big car show in Vegas, but it makes no sense for me to do that for my career or what I bring to Hurst. In my role. That being said, I think if you look at the people in your organization and you identify where there are gaps and where a conference can help fill those, you absolutely should pay for that. A great example for us was we had all these business units. I’m coming into these business units talking about DevOps. In some cases, they’re very unfamiliar with DevOps. They don’t really know what it is. They probably have been told it’s a tool like Chef or Puppet or Jenkins, This is especially true for leadership. And so, the DevOps Enterprise Summit was wonderful. I got them all to go to that. And because it’s sort of a birds-of-a-feather type of conference for large enterprise organizations, it was great. It was sort of like an aha moment for a lot of them. They’re like, oh, I get it now, a cultural movement where we’re really focusing on collaboration. And so, that was great. That being said, there have been plenty of technical conferences that I just don’t go to anymore because I don’t feel like I’m actually gaining anything. So, you know, for me, and I’m still highly technical, I’m still very hands-on, and hopefully that never really changes too much, but I don’t think that you should just go to a conference for the sake of going to a conference. Should organizations pay their people to speak? I worry a little bit about that, right? I went to DevOps Days in New York, or a DevOps conference in New York last year, and it was essentially an entire day of sales pitch. There was really nothing that was DevOps-related. Everything was how my product can make you better at DevOps or give you DevOps. And I worry if we start paying people to go speak, that part of that will be sort of like when a company says, okay, well, you can go to college and we’ll pay for your tuition. Oh, and you also have to sign on saying you’ll work here for 4 more years after you graduate. I worry that they may try and push an agenda more than allowing an individual to get up there and actually say what they’re thinking and what they feel and what they believe. And that’s one of the nice things about this, about these conferences, is that you can get up there and you can speak the truth and share your experiences. And it’s an opportunity for all of us learn together and not just sit there and listen why product Y will change the way you do DevOps in your organization.
Matty: [00:46:04] It’s interesting because, like, DevOps Days has very strong opinions about that kind of thing, right? As talks, no vendor pitches, stuff like that. So we tend to, as organizers, look really hard at that kind of thing. But I can say kind of from my own experience, The person that I’m talking about, he’ll know when he listens to this, and he knows that I’m cool with him, and I’m giving him a hard time. But I remember at one point, there was something that came up about me speaking at a DevOps Days, and he’s like, well, but you need to be talking about Chef. It was like, well, no, but that’s not— in fact, actually, that’s the exact opposite of how that’s going to work. And then I have whole theories on why it’s actually more beneficial to Chef for me to not talk about Chef at all. But just have everybody know that I work at Chef when I talk about a thing. But then the other thing was in the same team, there was an idea of saying, well, because it was valuable, like, and as a vendor, it’s super valuable for our customer-facing people to go speak at conferences because it adds to our credibility. And this is where things I think get hard within certain organizations. Same thing with certifications, for what it’s worth, right? Why does, why does it matter to, you know, bank a that their sysadmins are MCSEs. They don’t care. But it super matters to a consulting company, you know. And then the same thing with being a good brand externally. Me having a good brand around being an expert in DevOps, if you will— well, I can’t believe I just said that— is super beneficial to Chef, right? Because I go and I like talk to customers, they’re like, oh, I totally heard you speak at this event and you don’t sound like a complete idiot, so I will probably listen to you right now. The thing that happened— and so given that, given that we say if you’re customer-facing, it probably is beneficial. They wanted to get more people to do that in, in this team I was on, and the manager said, well, we’re going to start— we’ll provide— we’ll pay a bounty, right? It’s like, hey, every event that you speak at, you get cash in your pocket, right? And what that basically meant is it was awesome for Matt for a while because I was already doing it, and I’m like, cool. And the thing was, again, for the people who didn’t want to do it in the first place, that wasn’t the right incentive, right? And so unfortunately for me, that went away pretty quick and I was like, damn, that was a good way, you know? So what it was doing is it was the carrot was just simply incenting people who were already going to do it anyway. And then I think you don’t want to do it the other way. You don’t want to come at it with a stick and say, if you don’t speak at a certain number of conferences, then you’re fired because you don’t really have control over that.
Pauly: [00:48:39] Right. And I think it affects quality too, right? So you’re not pushing someone who let’s say it’s a technical individual. We’ll use a hypothetical. Let’s say hypothetically, there’s someone that you know is an amazing technical person, and there’s a conference coming up. This person has done amazing things over the last year with technology around your SaaS-based application. And so, you’re really trying to encourage this individual to get up there and share that story, and the person is just terrified of it. And so, do you— how hard do you push? And so, in this hypothetical, the manager backed off and was like, listen, if I make this person go up there, it’s probably going to be a bad experience for everyone. And the unfortunate thing is, if you’re familiar with, you know, paraverbal communication, the problem is that the content is going to get lost in the translation. It’s not just what the person was saying, but how they were saying it. That sharing is gone. So maybe you find another medium that they would be willing to— like a blog post is an example.
Matty: [00:49:45] Yeah, or come be on a podcast.
Pauly: Yeah, a podcast, right.
Matty: I think too, it’s— and I remember Paul Reed and I were talking over drinks one time about this thing about going to the— making your main job becomes your secondary job because your main job is now speaking at conferences. So I think when we talk about an organization incenting— and incenting I mean simply by not making you pay for yourself, right? If we say, I’m going to pay for you to go to a conference, or I’m going to pay if you speak, as in I’ll pay your T&E and not make you take PTO, I think, like, and you had said, there needs to be some common sense around it. And I think if I’ve got someone in my team that I’m like, okay, well, you have no time to actually talk to customers because you go to every single DevOps Days in North America, and you’re speaking all the time, and you actually don’t have time to do anything, Now, that’s not like a dig at Jason Hand who did that, because Jason Hand, that’s his job. He’s an evangelist, right? So again, if you’re an evangelist, that’s fine. If you’re an engineer and now you’re spending all your time going and speaking at events, there’s, there’s some bad things that happen, right? Because number one, you’re not doing what the company’s paying you to do anymore most of the time, and you’re actually probably becoming less and less of an awesome engineer because now you’re spending all your time speaking. You’re becoming a way better speaker. A way less awesome engineer. And I think it’s, it’s hard because we want to hear from these really successful people. And I think organizations are starting to see that it’s good for their brand to show off as being super awesome at this stuff. That’s the other thing too, right? Before we’re like, hey, why does a consulting company— they want to, you know, have it so that their folks are giving talks and everybody knows that that consulting company are experts. But why does the bank care? Well, the bank probably cares because now they’re starting to You know, like you look at like, again, Target, right? Or, you know, it’s like, oh, now I’m hearing cool things are happening there, so maybe I want to go work there, or I want to kind of build to that. It’s, it’s tough, right? Because then people become in high demand, and then you get into a vicious cycle where you’re like, cool, well, I want to go parade out, you know, Paulie in front of everyone, but he’s got to come and transform our organization. He—
Pauly: [00:51:56] yeah, I’m still writing code every day too, And I love speaking at conferences. Probably the thing I love most about it is after the talk, when I get to go and talk to people and find out their journeys, right? And learn from them. It’s an incredible opportunity as a speaker to learn from everyone else.
Matty: And so, I think one thing that organizations can do, like, it could be dangerous, like you said, to go into the one level of, like, well, if you go do this thing, then you’re, you know, in indentured servitude to us for the next 2 years, right? But I think it’s, you know, if I would have folks in my, my team, if I was, you know, managing people again, I would say, okay, that’s cool, you want to go to Velocity or DevOps Days, you know, Madison or whatever, um, you got to come back and you gotta like write an internal blog post about it, or, or just even do a brown bag and tell us what, what you did. And not, not because I want to check on that you actually did anything and you weren’t blowing it off, but it. That brings value to the whole team, right, at that point, right? It’s not just you. And, and then we can also divide and conquer a little bit too. We can be like, okay, this year Trevor’s gonna go to Velocity, you know, and Bridget’s gonna go to, you know, re:Invent. And we don’t have to send everybody everywhere, right? And maybe people can kind of mix it up and you still get that chance to do one thing or two things. But it’s, it’s a weird staffing problem if you’re—
Pauly: [00:53:22] that’s how we do it, right? And, and the nice thing about that is you start to move away from any potential of one individual becoming a pariah because that person always gets to go to all the conferences because they talk, and I don’t get to go to any of them because I’m just a shy introvert and I don’t want to speak about anything. And so that kind of allows it to get spread out a little bit, and that’s been a great approach for us.
Matty: Yeah, I have one more. We’re rapidly running out of time, so we’re clearly gonna have to do this again. But I have one thing, and you alluded to it, and it was actually one of first things on my agenda point is I said, despite your lofty title, you’re very hands-on. And I was talking to some people about that today at Chef. I was like, I think it’s super rad that I like go into like this customer Slack and Paulie’s in there like talking about attribute precedence, you know? And I’m like, isn’t he like some big muckety-muck VP? You know? So what’s that like? So like, again, you’re, you’re in that position. You said you’re still writing code, you’re still hands-on. Can you give me a little bit of a day in the life? Like what kind of stuff are you working on?
Pauly: [00:54:28] Yeah, that’s tough. I don’t think I have a normal day is the problem. So, part of it is, well, there are 2 aspects to that. One is I just love being an engineer, and I don’t ever see that changing. It doesn’t matter what role I have, I want to be building stuff. And if I can’t do it in my role, then I’ll create a project and put a GitHub repo out there, and we’ll do something open source just so so that I can get to have fun too. And so, the other aspect of that is, in order for me to continue to work with engineers, individual contributors on a daily basis, and really look at focusing on creating this groundswell, this grassroots cultural change movement, I have to be able to speak their language. I have to still live in their world. And that world is not static for long. Everything changes in the ecosystem, even leadership. And so I love being out there and really understanding the day-to-day grind of sitting there and hammering out code or trying to figure out how we’re fixing this latest Postgres problem that we’re having, or the SAN fabric has just gone crazy because the HBA firmware is off somehow. And so all of those issues are fascinating to me, and it’s just kind of fun. And honestly, you’re more likely to create that collaborative culture culture if you’re there. So one of the things I do when I go to the business units, uh, so I have, yeah, I have VP in the title, right? But anyone who knows me knows, you know, I’m a pretty laid-back person. I get there and they’re like, oh yeah, we’ve got an office for you. I said, no, no, I’ll sit out here in the queue with everyone else. It’s like, oh well, are you sure? I’m like, well yeah, why wouldn’t I, right? I mean, just, you know, I don’t want to sit in an office. It doesn’t do me any good to go sit in an office with the door shut and act like I’m not there, write some PowerPoints, right? Yeah, that sounds absolutely horrible. So, I wanna go sit and I wanna hear literally what is the day-to-day like? How do these teams really communicate? One thing that’s wonderful about engineers is even if someone tells them, listen, Paulie’s coming, so I need you to clean everything up and then I need you to act like everything’s great, they can pull that off maybe a day before that varnish wears off and they’re like, oh, this sucks. Idiots over there gave me the wrong stuff again. And they start talking across the walls and I’m like, this is great. This is the real world. And if we want to change things, we really need to be okay with talking about this and doing it in an unvarnished, honest approach. And so, that’s part of it. The other part of it is just, again, I’m like a consultant. So, I have this really sort of weird role in that I work with CTOs on a daily basis. I work with brand-new engineers and developers and operations. And so, I kind of run the gamut. I meet with the CEOs of the different business units. So the exposure that I’m getting in this role is amazing. Like, I could never have asked for a better opportunity to learn. And, you know, I don’t know where this all goes, but it’s certainly been a lot of fun and certainly an incredible learning experience.
Matty: [00:57:41] Yeah, it’s interesting what you were describing. I feel very similar because I’ve, you know, I kind of joke about that, you know, I am becoming less and less good at Chef the longer I work at chef, because I don’t work for a living anymore, like I said, right? I consult, I talk strategy with people, I help them with their roadmap and everything. And, and it’s a matter of looking for— and I see a lot of other people do this too. So it’s like, at one, at one level, it’s just like you said, engineer’s gonna engineer, right? Like, you can take, you can take Polly out of the engineer, but you can’t take the engineer out of Polly. And we will find a way to do it. And the problem is sometimes we will find a really bad way to do it, right? We will start engineering something internally that requires has absolutely no value to do, and we will do all this crazy stuff because we need to get our hands on some code, you know. And then also it’s like getting your chops. And, and I find there’s, there’s a couple projects I work on outside of my regular job that are just community or doing whatever. And like, this is just a silly example, like, I, I, you know, so I do the DevOps Days website. I— and Bridget wrote kind of a very good minimum viable Bash, as calls it shell script for people who are updating it. And I’m like, you know what, I’m gonna write a Go application that does all this. And it will probably be used ever by like 6 people. It is over-engineered as hell. I’ve got code coverage tests on it, I’ve got pipelines, all this stuff. And the reason is because I’m like, I need to do that. I need to do a software project that does those things so that when I— like you said, so I’ve got some cred when I’m talking to people who are in that mock to be like, hey, okay, this is how you do that. Maybe not with that specific tool because the specific tooling isn’t what matters. It’s the conceptual kind of thing.
Pauly: [00:59:31] Right, right. There’s a specific reason why I didn’t say that it gives me enough street cred to talk to a developer, although that’s part of it, right? That way the conversation starts. But that’s like saying I had a decent resume, so it got my foot in the door. The next step is, this person is going to say, it’s okay. I’ll give you a better analogy. It’s like going up to someone, they clearly speak Spanish, and so you say, hola, and then the person, like, just rattles off a bunch of Spanish, and you’re like, oh, wait, wait, wait, I didn’t— I don’t actually speak Spanish. And so, it’s the same concept here, is if I go in and I say, yeah, hey, I’m cool and I’m hip, you know, and then they start going, oh, yeah, so we have this class, and it’s calling a function, and our inheritance here is pointing, and you’re like, whoa, whoa, I don’t actually understand how to code. I just, I read a magazine on the airplane over here and it seemed like a good idea. So I want to dig in with the code. I want to understand their pain. And in order for me to do that, I have to, no kidding, know how to do it. Yeah, they will, you know, pardon my French, but they will sniff out bullshit quick. That meter is really, really tuned. And so especially when they kind of assume already you don’t know anything because you’ve got VP in your title.
Matty: [01:00:43] Yeah, like I think you put it well. It’s not even about, like you said, it’s not about cred. It’s about partially to, you know, bullshit prevention, but to be able to speak the language, right? Like, I want to be able to speak intelligently to you about this because otherwise I can’t actually help solve your problem because I don’t— we do not speak the same dialect, right? You’re saying things and I don’t know what they mean, so I can’t put them into context. Now, you know them way deeper than I do, and that’s totally right. But I may not know how to conjugate the verb, let’s say, to put it— to push that analogy as far as we can. But I know what the verb means and that.
Pauly: Right.
Matty: That helps.
Pauly: Exactly. I like to use that analogy of, as a great conductor, I don’t know how to play every instrument, but I know how they should sound and how they should sound together, you know. But if you ask me to go out there and play the violin, I’m gonna murder it. But I do know how to read the music and I know how it should sound. So, you know, just to kind of circle back really quickly, I talked at Kansas City DevOps Days a couple of weeks ago, and you were talking about wanting to have a project and wanting to keep your hand in the technology. And I said in the talk, I relayed a story about my son who, when he was very young, had a sound machine, and we wanted to kind of figure out a way to wean him off this thing, right? Because traveling, and we just thought it was a good idea. And I came up with this convoluted plan of building a Lego train set that would go down the hall and attaching an extension cord and, like, tracking its movement meant with an Arduino box. My wife is like, why not just turn it down a little bit more every night? I was like, oh.
Matty: [01:02:24] What’s the fun in that?
Pauly: Yeah. I’m like, but I’m an engineer. That’s not how we do things. I didn’t want to tell her I’d already bought all this stuff, including the domain name. I’m addicted to this stuff, and I love it. I think that really shows. It’s one of the things I love about Adam Jacob, too. He started a company, arguably is been leading the company, maybe not as the CEO, but certainly as the cultural leader. He never stopped loving technology and being able to be part of that transformation, regardless of where it’s going. So I kind of use that as a guiding light and try to do the same because it’s the same passion.
Matty: That’s a really good way to wrap up. Let’s move into checkouts. I think you kind of alluded to one of yours. But what do you got for our listeners to check out, Pauli?
Pauly: So, I’ll be speaking at DevOps Enterprise Summit in only a couple of days. So, it’ll be on the 9th, Wednesday morning at 9:30 AM on the main stage. I’m super excited about that. I’m doing something a little different. I guess I’m letting the cat out of the bag, but instead of just doing PowerPoint slides, I’m actually gonna read a story, a narrative of the work I’ve done over the last 2 years. And it’s really heavily focused focused on middle managers and where they play into DevOps transformations. With only 30 minutes, I’m trying to do a whole story arc in 30 minutes. So it’s gonna be like a 1980s sitcom where all of your problems are solved in 30 minutes.
Matty: [01:04:02] At least you don’t have commercial breaks, so it’ll be the full 30.
Pauly: Maybe I should have a laugh track. So it’s a bit of a fable, but it’s gonna be a lot of fun. And so, you know, if you can be there, that’s fantastic. I’d love to meet you. If not, it’s also going to be on live streaming. So I’m looking forward to that.
Matty: And we’ll put a link to the DevOps Enterprise Summit website in the show notes at restdevops.com/paulie. Also, I think you had one other— you sort of talked about it already.
Pauly: Yeah, I just spoke at DevOps Days Kansas City, and that was amazing, just absolutely amazing. Aaron Blythe really put on an incredible event. It was his first one, and I know it was incredibly stressful for him, as those can be, but it just was probably one of the best ones I’ve ever been to for the conversations and the success of it. I was amazed. That conference recorded the talks as well, and that talk that I did is also available online, so you’ll be able to see that. I think you’re going to post that as well, right?
Matty: [01:05:03] We’ll put that in the show notes as well.
Pauly: Awesome.
Matty: So cool. Yeah, I was bummed I had to miss it. I really, I didn’t, the only DevOps Days this year I made it to was Chicago, and I kind of had to go to that one.
Pauly: I know, and I missed that one.
Matty: But I love going to first ones. Like Madison just wrapped up, and apparently it was awesome. And there’s just such a, it’s again, having done it, there’s such a stressful thing the time you do it, but there’s this energy to the first time around. And what’s kind of cool is from an attendee perspective, it feels like they’re always all first time. Like every DevOps Days I’ve been to, you know, someone will say, how many of you out there, this is your first DevOps Days? And it’ll be like 80% of the room every time, which is great.
Pauly: Yeah, that is— I mean, think about the reach. I mean, that’s amazing in such a powerful vehicle.
Matty: Awesome. I got a couple to add. So one is this website I found today solving one specific problem. It’s Markdown to PDF, and you can find that at markdowntopdf.com. You paste in some Markdown code and it spits out a PDF. That is way more useful than you would ever think it is, and I can’t believe it’s taken me this long to find it.
Pauly: [01:06:09] That’s awesome. I’m going to use that for sure.
Matty: Yeah. The other one is I came across the other day is something called Errors Azure Throws. So it’s errorsazurethrows.tumblr.com, and it’s just a bunch of screenshots of really weird errors from Microsoft Azure. I don’t know, it amused me. And also, again, Chicago Cubs won the World Series, and I’m kind of crazy about it and still not over it. So, Pauli, you kind of told us that you’re going to be at DevOps Internet Summit next week. Where can people find you on the internet?
Pauly: I’m on Twitter @paulycomtois, and I’m on LinkedIn. I’m actually kicking off a new website next year, so I haven’t started it yet, but it’s devopstherapist.com. That’s essentially going to be— I’m going to try and lay off the conference talks for a while and focus on being able to communicate all the stuff that I’ve been working on and learning in a blog format. So we’ll see how that goes.
Matty: That’s awesome. So speaking of conferences, we’ve got a few coming up, a bunch of DevOps Days. So DevOps Days Cape Town is November 7th and 8th. DevOps Days Nashville, the first one they’re doing, November 10th and 11th. DevOps Days Berlin is the 16th and 17th of November. Brazil is right on the heels of that, November 18th. Days Warsaw, November 22nd and 23rd. Paris is November 28th, and Sydney is December 1st and 2nd. So lots of international DevOps Days coming up. A couple open CFPs— we’re at the tail end of CFP time, but we got CFP season right around the corner. DevOps Days Baltimore is still accepting talks until December 9th, and ChefConf 2017’s CFP is open. That’ll be open until January 18th. If you have an upcoming conference you’d like to see us promote on Arrested DevOps, we have this handy little form at arresteddevops.com/conf. I will possibly remember to promote your conference on the show. It is not a legally binding document, however. You can go to arresteddevops.com/paulie to get to all the show notes from this episode. Website also has links to subscribe to our newsletter, buy our shit, get some t-shirts, support us on Patreon, all the Arrested DevOps stuff you want. There’s links on the website there. And, you know, if you do that iTunes thing, pop into arrestedevops.com/itunes. And if you want to help other people find the podcast, give us a review there. So Paulie, thanks for an awesome conversation. This was super fun.
Pauly: [01:08:36] Oh, thank you so much. I’ve been a huge fan for a long time, so I’m glad I finally got an opportunity.
Matty: Loved having you, man.
Pauly: Yeah, absolutely.
Matty: Cool deal. All right, so I’m Matt at Matt Stratton. This is Arrested DevOps, and remember, there’s always DevOps in the banana stand.
