Screaming in the Cloud - Overcoming Change Management Anti-Patterns through Automation with Jeffery Smith

Episode Date: April 29, 2020

About the Jeff SmithJeff Smith has been in the technology industry for over 15 years, oscillating between management and individual contributor. Jeff currently serves as the Director of Production Operations for Centro, an advertising software company headquartered in Chicago, Illinois. Before that he served as the Manager of Site Reliability Engineering at Grubhub. Jeff is passionate about DevOps transformations in organizations large and small, with a particular interest in the psychological aspects of problems in companies. He lives in Chicago with his wife Stephanie and their two kids Ella and Xander. Jeff is currently writing a book “Operational Anti-Patterns with DevOps Solutions” with Manning publishing due out in Spring of 2020. He’s also the chapter president of Blacks in TechnologyLinks Referenced: @DarkAndNerdy Article: The First DevOps Hurdle BITConBlacks in TechnologyJeff's Book: Operations Anti-Patterns with DevOps Solutions

Hello and welcome to Screaming in the Cloud with your host, cloud economist Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. No billing surprises. With simple, predictable pricing that's flat across 12 global data center regions and a UX developers around the world love, you can control your cloud infrastructure costs and have more time for your team to focus on growing your business.

See what businesses are building on DigitalOcean and get started for free at do.co slash screaming. That's do.co slash screaming. And my thanks to DigitalOcean for their continuing support of this ridiculous podcast. This episode is sponsored in part by N2WS. You know what you care about? Many things, but never backups. At at least until right after you really, really, really needed to care about backups. That's what N2WS does for your AWS account. It allows you to cycle backups through different storage tiers so you can back things up cost effectively and safely. For a limited time, N2WS is offering you $100 in AWS credits for

setting up their free trial, and I encourage you to give it a shot. To learn more, visit snark.cloud slash N2WS. That's snark.cloud slash N2WS. Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Jeff Smith, the Director of Product Operations for Centro in Chicago. Jeff, welcome to the show. Hey, Corey, thanks for having me. So there are a lot of things we can talk about here, but really, I think the most interesting to me personally, and therefore for absolutely everyone else, is that you are writing a book,

the book that I first heard about and did two things. One, scheduled this podcast recording, and two, became angry and annoyed that it hadn't occurred to me to write something like this myself. But fortunately, you are. Tell us about your book. Sure. Yeah. So the book is titled Operational Anti-Patterns with DevOps Solutions. There's a funny story behind that title that I'll get to as well. But when I was originally approached about writing the book to Manning, the first thing I thought of is all of the DevOps books that I read were really sort of targeting the corner office. There was a lot of conversations about organizational restructuring and, you know, seat shuffling and responsibilities. And when I first

started looking at DevOps and what it could do for me in my organization, I knew that I didn't have that sort of backing. So I really started with like a groundworks guerrilla campaign to sort of prove out the value of DevOps without having the entire organization behind me. And when I did that, I quickly realized that there were all these different patterns that were contributing continuously to the problems in the organization. And I talk about that a bit in the book, but like the paternalist syndrome, right? Everyone knows about the grumpy operations group that says no to everything. Well, why is that, right?

Why are they like that? And how do we go about helping teams and organizations correct those things? So as I started to sort of collect these patterns, I realized, you know, this is an approach to DevOps that I can take piecemeal, that I can do myself as an individual contributor and later as, you know, middle management. And I could affect change without having to necessarily reorganize how people sit in reporting structures. So that's really where the genesis of the book came from, was a manual to folks like me who want the DevOps change, but can't necessarily get senior

leadership on board right away. Whenever I hear anti-patterns, I get this joyful feeling in my cold, dead, salt-packed heart because I hear that as business speak for you're doing it wrong. And I always found that to be a method of storytelling that resonates. If I want to get people excited about a technology or aspects of a technology for me, I find that as soon as you start saying this is how you don't do it, people sit up and pay attention for something like that. When you say, this is how you do a thing, oh, it's another tutorial, and people go back to staring at their phones. There's something about the don't do this, what I'm about to show you, that draws people in. Maybe that's just me and my ridiculous excuse for a personality, but I don't think I'm entirely alone. I don't think you're alone at all. And one thing that we've seen during the early access portion of the book is that is exactly what resonates with people. And I think part of it is

as a reader, the author is building some credibility with you because as individual contributors, a lot of times on the front lines, we recognize the problems, right? We know what's going on and we may not be able to articulate to management or make it a priority, but we see this stuff. So to read in the book and see this pattern that you know that your higher ups think is working and you know that it's not, it sort of creates this connection and you're like, yes, I'm bought in. He understands the problem. Now we can get into how you go about solving it. And that was some of the early feedback that we got in the book was that,

the examples that were given, people were like, this resonates with me, this is going on in my company right now, I feel these pains. And it's a way to sort of build credibility with the reader. So I don't think you're alone at all. I think the entire idea of approaching things through a story of this is how it looks like when it goes wrong absolutely builds credibility, builds authenticity.

Whenever someone gets on stage and talks about a transformation or a technology solution and it's all a glowing story about how it solves everything and now we have world peace, I know I'm listening to a sales pitch. The really bad versions of that are where the person who's evangelizing technology doesn't seem to realize they're to a sales pitch. The really bad versions of that are where the person who's evangelizing the technology doesn't seem to realize they're giving a sales pitch, but that doesn't change the fact that it's still challenging to listen to and sit through. So let's start at the beginning, I guess. Do you have a example of an anti-pattern that you're highlighting in the book? Sort of a sneak peek, as it were. Sure.

I guess one of the huge anti-pramids that still exists in a lot of organizations is change management, right? Like change management can sometimes be like the biggest farce on the planet because it quickly devolves into a rubber stamp committee with a group of people that are asking the same people that have actually requested the change to happen if it's okay to do the change. It ends up slowing everything down and it doesn't really manage risk the way that the process was originally intended to do. So when you look at it and you step back, you say, well, what are we really doing here and what value is it adding? So looking at that pattern, we kind of can take it and break it down and say, well,

what is it exactly that we're trying to do? Most times we're talking about notification to the appropriate parties, right? So there are tons of automated ways that we can do that, right? Sometimes it's ensuring that a process has an appropriate rollback process, right? We can do that through automation. There are mechanisms within the ITSM framework for change management to sort of have these changes become what we call standard changes, where you don't necessarily have to go through the full change management process. But, you know, a lot of organizations that I talk to don't really take advantage of that. So what happens? You end up

creating an emergency, right, so that you can push this change through faster. Because again, you're not getting the actual value out of the process. It's really just a rubber stamp that you kind of have to jump through. So in the book, we talk about like, how can we leverage automation to make that portion of change management just go away? How do we take the things that an approver would be looking for? And how do we turn those into qualitative signals that an automated process can read and decide, yes, this is okay to continue or no, it's not. And it sounds scary at first. People, you know, tend to freak out like, oh, there's no way you could automate this. Believe it or not, nine times out of 10, when you're taking a

particular action, especially with like a simpler complex task, there is a playbook that your mind is going through. And while you think you're adding a lot of nuance to it, a lot of times you're not. You're saying if A, then do B, if C, then do D. And those are all things that you can codify and put into an algorithm. So how do we do that? Free ourselves up to make those processes go faster, skip that change management process, and then how do we leave change management for the truly monumental things that need to go through that process? And then how do we do it in a way so that if you're in a larger organization that has very strict change management processes, how do you fit that within the ITSM framework so that you are still meeting all of

those requirements? And it's really not that difficult. It just takes a little planning and a little forethought. So that's one of the big anti-patterns that I see that I think resonates with a lot of people when they read the book, especially in larger organizations. Oh, it absolutely does. And even hearing you say that, I immediately come up with a bunch of objections and potential challenges to that. Can we go into them for a little bit? Oh, yeah, absolutely. Excellent. Let's fight. One of the joys of dealing with a lot of different companies as a consultant is that I get to see an awful lot of different cultures and culture comes from the top. I don't think you can ever change the culture as an

outsider, even though there are a bunch of consultants who swear they can do it. Good luck, have fun, send me a postcard if you ever get there. There's very often as companies go from being small scrappy startups to being larger entities that have actual assets and things that they could be risking. The idea goes away from build, move fast and break things and into the idea of let's not break the thing that makes the money. So it seems that if left unattended, these companies often every time that there's something that breaks, it causes an outage, they build a check or a system or a process to prevent that specific thing from ever happening again, which makes sense on its face. But in time, suddenly you have so many different things that have to happen for anything to get done that it ossifies the entire organization and they're incapable of moving rapidly. Now, I love the idea of what you're talking about, of being able to move a lot of that process and approval into automated systems. The challenge is, is as you're rolling out an automated system like that, I can imagine a world

in which something gets through that doesn't get caught. Not that it would have gotten caught by human review either for that matter. But at that point, it seems like it turns into a blame festival of, well, why didn't this system catch this? We're canceling the project and moving back to the human approval method. How do you overcome that? So a lot of times, in my experience, I've overcome a the past is like, well, let's point out this particular issue wouldn't have been caught by our other process either. That's not necessarily to give it a pass. You're not going to walk in the office like, well, the old process wouldn't have worked either.

But you have to continue to make the point that the old way wasn't delivering the value either. But the new way is at least giving us the advantage of speed in a lot of scenarios, right, of flexibility. There's always going to be incidents that slip by, whether it's going to be an automated process or a manual process. What you can do in those respects with regards to automation is you can tier the level of automation that you're doing for a given process. And what I mean by that is we always think of automation as being this single automated process, right? I click a button and we go from beginning to end and no one has to do anything. Well, maybe there's a process that's a little riskier. Maybe the automation around that requires certain levels of confirmation, right? Where as

I move through the process with various steps, I'm confirming that information with a human. Is it a bit slower than the whiz-bangy way? Yes, absolutely. But you still might take a 60-minute process and boil it down to 10 or 15 minutes. And you're allowing that opportunity for a human to sort of verify at these critical juncture points. The other option is, you know, what I always say is like, you know, fail fast and fail often, right? Where if you have this sort of happy path, if anything looks even remotely suspicious, you know, you bail out and you alert a human. So I think the way to approach it, and without like a very specific example, it's hard to get into the details, but I think you can slice a problem up based on its risk and determine the level of

automation that you're going to give a thing. If there's a human involved where they're sort of prompting along the way, you know, that's a lot more palatable to some people. And maybe you do that just to build confidence in the automation, right? Like, hey, we've been doing this for three months and Bob's, you know, index finger is getting tired from hitting yes all the time and we haven't had an issue. What can we do about sort of rolling that safeguard back? Or, you know, like I said, sticking with data and saying like, hey, we've done this change 95 times now, 95 times it's worked, maybe it's time to take the guardrails off. But I think building confidence through that is really the only way to convince people like, hey, I know that we were gung-ho about the old human method, but it wasn't great. This process is getting stronger and stronger every time we do it.

I find that very often you wind up without having a transformation like you're discussing, you wind up with a very oppositional approach and the cycle repeats and reinforces itself where you'll have a company that say, okay, any deployments to production now need sign off by a VP. And the way to overturn that is you have engineers who then decide, all right, I'm going to, every change I make,

I'm going to call the VP at two in the morning to approve this change and with a malicious compliance approach of, all right, I'm going to effectively make sure that person never has a minute's peace until this policy gets rolled back. And it's effective, but I don't know that it necessarily sparks the kind of transformation that most companies tend to find themselves aspiring to. Yeah. I mean, I, I absolutely agree. I think, I think the scorch earth approach earth approach is probably not great, but I hope you didn't think that's what I was advocating for.

Oh, no, not at all. That's what I'm advocating. Oh, you're advocating for that. Oh, I am the source of most of these terrible anti-patterns. I want to be very clear on that right now. Yeah. So, you know, I don't know that – I mean, I've never tried it. I don't know that that method is particularly

effective, especially at the VP level, but who knows, you know, that's the approach that we're basically taking with alert fatigue and on-call, right? Like you give it to the dev because the dev is the person that's capable of making that correction. And the theory being, if they're getting woken up in the middle of the night, they're going to jump on it in the next morning and solve it. So pain is instructive. If you, if you have people who are experiencing pain, sharing that pain with the people empowered to fix it is not a half bad strategy, snark and cynicism aside. Absolutely. I mean, there, there's this whole concept of skin in the game, right? Where we transfer a lot of risk to other areas. And as long as that risk doesn't, you know, reside on me, my, the way that I'm going to interact with

the process is very different than if I've got skin in the game. So you're right, you know, reside on me, my, the way that I'm going to interact with the process is very different than if I've got skin in the game. So you're right, you know, sort of spreading that pain around does bring a certain level of forbearance to the problem. I just don't know how effective it gets when you go up the chain. Right. And that's where it starts to break down to that end, what you're describing, at least in my mind, I envision a certain type of company or organization where these types of problems start to resonate. But I'd rather ask, in your case, are you envisioning this being aimed at a particular type of organization? Is this something that you think applies universally? I mean, who is the target audience for something like this? So the target audience for me is like these, you know, small to medium sized businesses.

I think there are some lessons to be learned from larger organizations. But, you know, to be perfectly honest, these extremely large organizations have all types of other issues that they need to deal with. You know, compliance issues, regulatory issues like legacy cruft in terms of policy. So I think some of the ideas will resonate. I don't know how effective some of the methods of implementation might be. So where I'm going is really these small to medium-sized companies, particularly medium-sized companies that have a bit of organizational cruft. They might have some old-school processes in terms of how they're dealing with things

like change management, like deployments, like access to production, right? Every company that I've been with seems to go through this growth phase, you know, where they're small and they're scrappy, then they get a little bit bigger and they start hiring a different type of person, right? Different types of engineers and leaders. And then suddenly they're overburdened with process, but they really don't need it for the stage of the game that they're at, but they find themselves trapped there. Right. So I've come into a couple of organizations in my lifetime that have been in that state where it's like, you know, Hey, we are doing this because, you know, Frank, who was hired last year as the VP of something came from a finance background with a company

with 250,000 employees. And this is what he's used to. But we can really roll some of these back. This episode has been sponsored by Chaos Search. If you have a log analytics problem, consider Chaos Search. They do sensible things like separating out the compute from the storage in your log analysis environment. You store the data in S3 in your account, you know where it lives, you know what it costs, and then they compress it heavily while indexing it, and then they query that data using a separately scalable fleet of containers. Therefore, the amount of data you're storing no longer is bounded to how much compute you throw at it as well. It's broken that relationship, leading to over 80% cost savings in most environments

and being a sensible scaling strategy while still being able to access it through the APIs you've come to know and tolerate. To learn more, visit chaossearch.io. That's incredibly helpful to hear. One of the biggest complaints that i have and i suspect i may not be entirely alone on this one is you'll go to a conference and you'll have someone getting on stage and talking about their incredible journey their wonderful transformation or even their technology it doesn't really matter what the subject is but you see them get on stage and you

know before they even open their mouths that they're about to tell you a story that has questionable relation to what actually happened. And this has happened to me repeatedly, where I'll be in an audience sitting there watching a talk and I'll say, turn to the person next to me and say, wow, I'd love to work at a place that did that. And their response is, yeah, me too. And they work at the company that is presenting. So it's, it's, you're always getting glimpses and sanitized stories and, and condensed summaries that skip over the painful real world, messy stuff. The world is messy and things like architecture diagrams or conference wear don't tend to embrace or reflect that messiness very often. Oh, I so agree with you. So it sounds like what your book is aiming at is talking about the messy parts.

Absolutely. That's one of the things that I think is a common theme in a lot of my talks when I go to conferences. It's like, I throw the dirt out there, right? Because exactly what you said, no one wants to hear the rosy red picture of like how perfect everything was now that you're running, you know, Docker and Kubernetes and there was no pain. Right. It's like, you're right. It's messy. It's dirty. And the thing is, it's not always a complete win.

Right. So I did a talk, DevOps, the good, the bad and the ugly, where I sort of detailed like, hey, we went through a bunch of different organizational models. And as great as it sounds to have, you know, ops embedded in dev teams, there are some things that suck about that, right? Mainly, you're scaling your dev team much faster than you're scaling your ops team. Or this ops guy is sitting around and sprint planning, twiddling his thumbs, because half the stuff you guys are talking about, he doesn't really care about, doesn't have a direct interest or need to work on. So I think it's important that when we're giving these talks, we try to be as truthful and honest as possible. And I know that some companies might take umbrage with that, right?

Like, oh, we don't want you out there airing our dirty laundry. But that's where the learning happens, right? Like, no one learns from a perfect story. Where I learn from is when you get up and tell me how your Kubernetes cluster fell over because you only had one DNS pod and it got overran and it took the entire cluster down. Those are the stories that I'm interested in. If you're going to sit there and tell me like, oh yeah, we migrated to Kubernetes and everything was great. It was a little hard, but now we're saving all this money. That's kind of hogwash, useless.

And you're right. I sort of turn my nose up the minute I hear it, like, oh boy, here we go. Yep. Oh, here we go again. It's one of those very narrow talks. It sets off my sense of this is a sales pitch. And the only question left in my mind is,

do they know it's a sales pitch or are they falling for their own mythology? Yeah, and it's great sales pitch or are they falling for their own mythology? Yeah. And it's great when you hear a speaker. When I was at reInvent 2019, I was listening to the Pokemon team talk about their migration. And they were talking about these very common bad architecture choices that they had in their organization, right? And while everyone groans, everyone is also like, yeah, I got three of those in my organization as well. And to have that sort of realness, you know, I was like, all right, I'm bought in. Like, I want to hear where these guys are going because they were being authentic versus, you know, we don't really make any mistakes and, you know, architecture is is perfect and you know uh everything's beautiful at pokemon world exactly you can't go ahead and just assume in the absence of anything else that

first that what someone is saying on stage is true but secondly taking it a step further from the person who's on stage i feel like a lot of times these talks and i know i'm picking on conferences but that's okay they deserve it they. They're on stage. That's the point. It feels like they don't set ground rules and context for who the talk is for. These, the canonical example that built a talk that I wound up giving was I watched someone on stage talk about how Netflix does things and how everyone has access to root and production, yada, yada. The person next to me is super excited about that. And I glanced at their badge and they work for a bank. There's a bit of difference between production for the infrastructure streaming thing

and production is in the thing that runs the ATM network. You kind of need to have those things treated differently, but the lack of context setting in the talks that the audience can internalize is often missing. So I'm a stickler for who is this for? And sometimes when you look at some of the more poorly executed marketing events, you realize it's not really for anyone. Right. Corey, if I could weave a magic wand, I think I would ban Google and Netflix and Apple from writing any blog posts, right? And the internet.

Right. Or is that a bridge too far? Right. So it's like, just stop writing blog posts because people read this stuff and they think that everyone is doing that. And that's a large source of where all this imposter syndrome comes from, right? You read these blog posts about how super perfect their architecture is and you're like, well, man, I'm trying to just stop having to restart my web servers every eight hours because they're running out of memory, right? So you read this stuff and you internalize it and you feel like, you know, I'm just not

adequate. When you get into those shops, though, when you talk to those people, you realize it's the same dumpster fire. It's the same set of bodies. They just, you know, polish them up and keep them buried where the smell doesn't waft up too high. I hate when people leave a talk feeling crappy. It's, oh, you built a globe-spanning CDN that talks to everything in the world simultaneously. Cool, cool. Yesterday, I spent three hours hunting down a misplaced underscore. Right, right. Exactly, exactly. It's one of those, the idea is people should never leave a talk feeling crappy. Yes, absolutely. People should feel energized, they should feel charged, they should feel like, wow, I'm not alone and I'm capable of doing this.

And, you know, I'm sort of hoping that's what the book does for folks, right? When they read it, they say, wow, this is my organization sort of reflected in this, right? And this guy found a way out. And it's not perfect by any means, but it's a lot better than where I'm at. Maybe I can get there too. And that's how you should feel leaving a talk, right? Like, okay, you know, these guys have the same problems. They have the same set of skills. It's not a bunch of, you know, rocket scientists that they recruited from NASA to somehow run a Kubernetes infrastructure, right? They're just, you know, regular tech people that are doing a job that are making mistakes and they're sharing

their learnings. Yeah. And if you're up there telling the story, then during the Q&A section, it's a, well, how do you handle this problem? And the response is, I can't talk about that. Then why are you even having Q&A? If you're not allowed to talk about anything other than it was expressly approved, get off the stage. Right. Exactly. Or just don't set it up that. It stinks of the, that's only for special people to know. When I hear that, I just assume, oh, you've done something Byzantine that wouldn't work anywhere else and frankly is probably more than a little terrifying. I've talked to people at all of these big tech companies, most of them on this podcast. And something I've learned having done this long enough is that there is no mythical magic company where everything is done correctly. Everything is a dumpster fire under the hood, but most people don't talk about it.

Absolutely. You know, one of the best moments I had at a conference was I gave this talk and people were pretty impressed. They were giving me, you know, all types of credit that I don't deserve. And then someone says, you know, well, how do you go about handling your infrastructure testing? How do you go about automating that? And my response was simple. I was like, poorly. We do it poorly, right?

Like we're not good at that. And we're working to get better. Here's what we do. It's not the greatest, right? You're probably in a very similar situation. But to see people's heads nod and say like, okay, all right, sweet. So I'm not alone. You know, that's just, I don't know, it's a good feeling.

And, you know, the thing I always try to iterate to people is like, just keep getting better. That's all you can do. Just keep getting better. And if you're getting better, you're in a good spot, right? As long as you're not sitting around and saying like, well, this is just the way life is and I guess we're stuck here. You know, that's a place of defeatism. But when you're saying like, hey, this is wrong, we're trying to make it better and we're making progress, that's the place I want to be. I told my boss, my boss said, he said, Jeff, what would make you leave?

And I said, well, if we were ever in a situation where we were doing something really stupid and we were just completely okay with it, I'm okay if we're doing stupid and we're saying, well, we know this is stupid and we got to make it better. But if we're like, you know, this isn't that dumb and we're okay with this, that's when I'm like, all right, it's time to look for another job. So I just feel like you just got to keep making progress and just recognize when you're doing something dumb and try to make it better right and it's disturbing how often people tend to fail that basic test this sounds like the

The type of book that I want to shove down people's throats before they're allowed to give conference talks about transformation Well, I will gladly do that especially if you're gonna buy a copy before you shove it down their throat Oh, if I will do more than that and we'll're going to buy a copy before you shove it down their throat. Oh, in fact, we'll do more than that. And we'll give people a discount code on the early copy of the book. You can check it out at Manning.com in their Manning Early Access program with a discount code of PODSCREAM20 and get a few bucks off. Because if you're going to shove a book down someone's throat, you should at least get 40% off. Exactly. That's the entire point. The reason there are retail prices is so people can feel good about getting discounts on things. poke down someone's throat, you should at least get 40% off. Exactly. That's the entire point.

The reason there are retail prices is so people can feel good about getting discounts on things. So let's talk a little bit about that writing a book process. I've never written a book. If you know what my personality type is, that makes sense. I don't have the attention span most days to finish writing a tweet. So that's the exact opposite of what I tend to do. What inspired you to do this? Was it something you had floating around for a while? Was it something you had half written and then you pitch it to someone? Did they talk to you out of nowhere and, hey, you should write a book? And then you wound up stumbling into that because you didn't know what you were getting into.

How did it happen? So Manning had reached out to me to write a book on Puppet a number of years ago. And at the time, I just had a kid. And I was like, look, I'm just not in a place where I can write a book right now. So, you know, we sort of kept in touch. And then I wrote a blog post for CIO Magazine called The First DevOps Hurdle, and just sort of talking about some of the early phases of a DevOps transformation. And one of the publishers reached out and said, hey, would you be interested in writing a DevOps book? And I'd been thinking about this. I've been sort of noodling on this for a while and the timing was right. So I was like, yeah, sure. I'll gladly do

this. Let's do it. And then it started and I'm like, Oh man, like I really didn't think this through. This is, this is kind of, kind of tough, right? You're, you're working eight, 10 hour days, you're coming home, you're playing with your kids, and then you got to put two to three hours into writing a book. Like it's been a slog. It's not easy. And then you've got all of this, like I said, imposter syndrome sort of floating around. You're, you know, reading all these tweets and other people are producing books and you're like, oh man, did I include this? Should I include that? There's a pretty heavy cadence that Manning sort of puts you on to make sure that you're delivering content pretty regularly. And then when you go through what they call the first review process where you take the first like four chapters of the book and you send it to some internal reviewers.

Oh, man, you want to talk about like just biting your nails, talking about like, you know, Kermit nervous. You're just like, oh, goodness, oh, goodness, oh, goodness. What's the feedback going to be? Because you're always going to focus on the negative feedback. Doesn't matter what it is. Doesn't matter how much positive feedback you get. The negative feedback is always the stuff that jumps out at you. So it's been a bit of a process, but it's been fun in some cases, not so fun in others, but it's definitely an undertaking. Yeah. The line I've heard is that no one wants to write a book. Everyone wants to have written a book. Yes, exactly, exactly.

One of the funny stories, you know, we – titling a book is an extremely painful process I've learned. So when we first started, we were doing this – the title was Demystifying DevOps. And the publisher was a little lukewarm on it, but I really liked it. And, you know, a mutual friend of ours, Emily Freeman, she wrote a DevOps book. And as soon as it came out, I was like, I got to get this. I'm just so excited to read this. So I get it in her very first chapter. It's titled Demystifying DevOps.

So I'm like, whoa, I'm going to put this on the shelf. I'm not going to read this until I finish my book. And then we went through the process of retitling again. You don't want to accidentally rip people off. That never goes well. Right, right. So I was like, all right. So I'll have to read that when I'm finished with mine.

One last question before we go here. You are one of the organizers behind BitCon. Yeah, so I'm the Chicago chapter president of a group called Blacks in Technology. And we've got chapters all over the US. But the national body runs a conference every year. And for the last two or three years, it's been in Minnesota. But we did an event here in Chicago with the CIO of Illinois. And he pulled me aside. He was like, Jeff, you know, I was at BitCom last year. What do I got to do to get this in Chicago?

And I was like, I think you just did it. So, you know, the powers that be started talking about it. And, you know, Illinois has been great in offering us a lot of support. So BitCon will be coming to Chicago. We're still working out the exact details as we, you know, finalize the actual location. But if you go to blacksandtechnology.net, feel free to keep an eye out there. We'll be posting updates as they come along. So I have to ask one more question, though, then, I guess. So you're organizing a conference and you're writing a book. Do you ever make good decisions? No, actually, I don't. I think when was the last time? 2015? I think it was a Tuesday. I was going to get Taco Bell and instead I got Subway. And I think that's the closest I've gotten to a good decision probably in the last three or four years.

Excellent. Both of those things are such strong demands on the time, and it's invisible, at least until the event happens. But so many people think that a conference just magically springs up the day before. It's talking to people at big conference events. They have a ground team in place weeks or months beforehand for some things. It is such a tremendous amount of effort to pull something off that looks effortless. Yeah, this will be my first time organizing. Luckily, I've got some friends that have done this a few times, so I'll be leaning on them.

But you're right. You know, here it is. I mean, we started talking about this in December of last year, you know, what it was going to take getting the ground crew together to be able to, you know, sort of hit the ground running as things heat up. And it feels like, you know, the work just comes in waves. So, yeah, anytime you go to a conference, you just have no idea how much work went behind that, even for the crummy ones, right? Even ones where you're like, wow, this is an organizational disaster. Let me tell you, there was a lot of sweat and tears behind that organizational disaster. So yeah, you know, looking forward to it, kind of, sort of,

you know. Again, similar to the book thing, it feels like it's going to be better to have done it than to be doing it. Yes, absolutely. And that's what everyone says. They're like, but when it's over, man, you're going to feel so good. And, you know, just sitting around waiting for those royalty checks that are never going to show up. It's, uh, it's going to be exciting. So I'm just looking forward to being able to have something that my kids can look at and say like, Oh, my dad did that because being able to show something to your kids and be like, Hey, listen, you know, like you can do this, right? You can be a part of this world where I grew up. Like I grew up in upstate New York in a town called Schenectady. And it felt like the world was sort of like out there. It wasn't in Schenectady.

Everything happened out there. So, you know, I've always thought like it is so great to be able to show my kids, right, like you can participate in this larger world. It's not beyond you. You can do it. So I think that's probably one of the, uh, the biggest drivers that's been going for me is, is the kids. Kids are one of those things that just changes every, I guess, uh, priority calculation you have. Every, everything that I wound up doing is somehow influenced by having a kid, even though it doesn't look like that. It's, it completely reshapes your entire worldview, I think is the best way to frame that. Dude, you have no idea. Like I didn't understand it until, so, you know, I've got this thing about priorities and, you know, I don't believe in multiple priorities. You know, I believe you have one priority.

You have a bunch of other important stuff, but there's one priority at any one given moment. And I don't think I really thought or learned about that until I had kids, right? Because when something happens with them, everything else takes a backseat, right? That's the priority. And you realize, I'm not juggling multiple priorities. This thing is a priority. Another thing is on the back burner.

Now, once I handle that, I'll elevate something else. But kids really did help me look at the world in a completely different light. And they make me drink. Yeah. Oh, God, yes. I'm looking forward to the point where she's old enough to drive me to drink like in a car. That would be handy. Then you have your built in DD things that go super well. So if people want to hear more about your thoughts on the world, obviously there's the book with the

discount code, but where else can they find you? You can find me on Twitter is probably the best place. I'm a dark and nerdy on Twitter. That's usually where I, if I happen to get around to making a Medium post, that's where I'll do it. I've been slowing down a lot with that because every time I sit down to write a blog post, I say, you know what? You should be writing a chapter in your book instead. But following along there is probably the best place to catch me. Fantastic.

Thank you so much for taking the time to speak with me today. I appreciate it. Thanks for having me, man. Had a great time chatting. Excellent. Jeff Smith, Director of Product Operations at Centro. I'm Corey Quinn. This is Screaming in the Cloud.

If you've enjoyed this podcast, please leave a five-star review in Apple Podcasts. If you've hated this podcast, please leave a five-star review in Apple Podcasts. This has been this week's episode of Screaming in the Cloud. You can also find more Corey at screaminginthecloud.com or wherever Fine Snark is sold. This has been a humble pod production stay humble