Subscribe
Share
Share
Embed
Jeffery Smith is the director of production operations at Centro. Over the course of his 20-year career, Jeffery has held a number of technology roles. Prior to joining Centro, he worked at Grubhub as a site reliability engineer manager, a senior systems engineer, and a system admin. Before that, Jeffery also worked for Wolters Kluwer as a website support analyst and for Instant Technology as a Windows/Solaris administrator, among other positions.
Join Corey and Jeffery as the discuss the inspiration behind Jeff’s book, Operational Anti-Patterns with DevOps Solutions, why Jeff believes that change management is one of the biggest anti-patterns that can be found across a lot of organizations, how automation can help optimize change management initiatives, why Corey thinks consultants are incapable of changing company cultures despite what many of them might say, why it’s impossible to learn from the fabled “perfect story,” why no one in an audience should ever leave a conference talk feeling crappy, what Jeff’s book-writing experience was like, and more.
Screaming in the Cloud with Corey Quinn features conversations with domain experts in the world of Cloud Computing. Topics discussed include AWS, GCP, Azure, Oracle Cloud, and the "why" behind how businesses are coming to think about the Cloud.
Transcript
Announcer: 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.
Corey: This episode is brought to you by DigitalOcean, the cloud provider that makes it easy for startups to deploy and scale modern web applications with, and this is important to me, no billing surprises. With simple, predictable pricing that’s flat across 12 global data center regions and 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/screaming. That’s D-O-Dot-C-O-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 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 a hundred dollars in AWS credits for setting up their free trial, and I encourage you to give it a shot. To learn more, visit snark.cloud/n2ws. That's snark.cloud/n2ws.
Corey: 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.
Jeff: Hey, Corey, thanks for having me.
Corey: 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.
Jeff: Sure, yeah, so the book is titled [00:03:02 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 were a lot of conversations about organizational restructuring, and 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 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 talked about that a bit in the book, but the paternalist syndrome. Everyone knows about the grumpy operations group that says no to everything. Well, why is that? Why are they like that? And how do we go about helping teams and organizations correct those things? So, as I started to collect these patterns, I realized this is an approach to DevOps that I can take piecemeal, that I can do myself as an individual contributor and later as middle management, and I could affect change without having to necessarily reorganize how people sit and 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.
Corey: 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.
Jeff: 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 it 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. 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 his connection and you're like, “Yes, I'm bought in. He understands that 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 build credibility with the reader. So, I don't think you're alone at all.
Corey: 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. It 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 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 an example of an anti-pattern that you're highlighting in the book, sort of a sneak peek, as it were?
Jeff: Sure, I guess one of the huge anti-patterns that still exists in a lot of organizations is change management. Like, change management can sometimes be 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 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. Sometimes it's ensuring that a process has an appropriate rollback process. We can do that through automation. There are mechanisms within the ITSM framework for change management to 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, 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 have to jump through. So, in the book, we talk about 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 tend to freak out like, “Oh, there's no way you could automate this.” Believe it or not, nine times out of ten, when you're taking a particular action, especially with a simple or 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 large organizations.
Corey: 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?
Jeff: Oh, yeah. Absolutely.
Corey: 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. 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 fast, move fast and break things, and into the idea of let's not break the thing that makes the money. So, it seems that, 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 the process and approval into automated systems. The challenges 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?
Jeff: So, a lot of times, in my experience, I've overcome a lot of that with data in some respects. So, one of the things that I've done in 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, right? 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, 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 and 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.
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, whereas I move through the process with various steps, I'm confirming that information with a human. Is it a bit slower than the whiz-bang-y 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 verify at these critical juncture points. The other option is what I always say is fail fast and fail often, where if you have this sort of happy path, if anything looks even remotely suspicious you bail out and you alert a human. So, I think the way to approach it—and without 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, that's a lot more palatable to some people. And maybe you do that just to build confidence in the automation. Like, “Hey, we've been doing this for three months, and Bob's index finger is getting tired from hitting yes all the time, and we haven't had an issue. What can we do about rolling that safeguard back? Or, like I said, sticking with data and saying, “Hey, we've done this change 95 times now. 95 times it's worked, maybe it's time to take the guard rails 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.”
Corey: 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 says, “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, every change I make, I'm going to call the VP at two in the morning to approve this change,” and with the 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.
Jeff: Yeah, I mean, I absolutely agree. I think the scorched earth approach is, is probably not great, but I hope you didn't think that's what I was advocating for—
Corey: Oh, no, not at all. That's what I'm advocating.
Jeff: Oh, you're advocating for that. Oh—
Corey: Oh, I am the source of most of these terrible anti-patterns. I want to be very clear on that right now.
Jeff: Yeah. So, 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. That's the approach that we're basically taking with alert fatigue and on-call, right? 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 in the next morning and solve it. So, who knows, maybe—
Corey: Pain is instructive. 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.
Jeff: Absolutely. I mean, there's this whole concept of skin in the game, where we transfer a lot of risk to other areas, and as long as that risk doesn't reside on me, 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, 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.
Corey: 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?
Jeff: So, the target audience for me is these 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; compliance issues, regulatory issues, 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 the 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. Every company that I've been with seems to go through this growth phase where they're small, and they're scrappy, then they get a little bit bigger, and they start hiring a different type of person, 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. So, I've come into a couple of organizations in my lifetime that have been in that state where it's like, “Hey, we are doing this because 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.
Corey: 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 in a place that did that.” And their response is, “Yeah, me too.” And they work at the company that is presenting. So, you're always getting glimpses and sanitized stories, 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.
Jeff: Oh, I so agree with you.
Corey: So, it sounds like what your book is aiming at is talking about the messy parts.
Jeff: 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, is I throw the dirt out there, because exactly what you said, no one wants to hear the rosy red picture of how perfect everything was now that you're running Docker and Kubernetes, and there was no pain. It's like—you're right. It's messy. It's dirty. And the thing is, it's not always a complete win. So, I did a talk, “DevOps, the Good, the Bad, and the Ugly,” where I sort of detailed, “Hey, we went through a bunch of different organizational models. And as great as it sounds to have ops embedded in dev teams, there are some things that suck about that.” Mainly, you're scaling your dev team much faster than you're scaling your ops team, or this ops guy is sitting around in 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. Like, “Oh, we don't want you out there airing our dirty laundry.” But that's where the learning happens. 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 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.”
Corey: 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 as a sales pitch, or are they falling for their own mythology?
Jeff: Yeah, and it's great when you hear a speaker—when I was at re:Invent 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. 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, I was like, “Alright, I'm bought in.” I want to hear where these guys are going because they were being authentic, versus, “We don't really make any mistakes and architecture is perfect, and everything's beautiful, in Pokemon World.”
Corey: Exactly. You can't go ahead and just assume, in the absence of anything else, 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'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, yadda, yadda. The person next to me is super excited about that, and I glanced at their badge and they work for a bank.
Jeff: Right.
Corey: There's a 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.
Jeff: Right, Corey, if I could wave a magic wand, I think I would ban Google and Netflix and Apple from writing any blog posts.
Corey: And the internet. Or is that a bridge too far.
Jeff: Right, so, it's like just stop writing blog posts, because people read this stuff, and they think that everyone is doing that. And it’s a large source of where all this imposter syndrome comes from. 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.” So, you read this stuff, and you internalize it, and you feel like, “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 polish them up and keep them buried where the smell doesn't waft up too high.
Corey: 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.”
Jeff: Right, right. Exactly, exactly.
Corey: The idea is, people should never leave a talk feeling crappy.
Jeff: 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 I'm sort of hoping that's what the book does for folks. When they read it, they say, “Wow, this is my organization sort of reflected in this. 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. Like, “Okay these guys have the same problems. They have the same set of skills. It's not a bunch of rocket scientists that they recruited from NASA to somehow run a Kubernetes infrastructure. They're just regular tech people that are doing a job that are making mistakes and they're sharing their learnings.”
Corey: 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 with anything other than it was expressly approved, get off the stage.
Jeff: Right? Exactly.
Corey: Or just don't set it up that—it stinks of, 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.
Jeff: 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 all types of credit that I don't deserve, and then someone says well, how do you go about handling your infrastructure testing? How do go about automating that? And my response was simple. I was like, “Poorly, we do it poorly. We're not good at that. And we're working to get better. Here's what we do. It's not the greatest. You're probably in a very similar situation.” But to see people's heads nod and say, “Okay, alright. Sweet. So, I'm not alone.” You know, that's just, I don't know, it's a good feeling. And 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. As long as you're not sitting around and saying, “Well, this is just the way life is. And I guess we're stuck here.” That's a place of defeatism. But when you're saying, “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, “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. We got to make it better,” but if we're like, “This isn't that dumb, and we're okay with this,” that's when I'm like, “Alright, 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.
Corey: Right. And it's disturbing how often people tend to fail that basic test. This sounds like the type of book that I want to shove down people's throats before they're allowed to give conference talks about transformation.
Jeff: Well, I will gladly do that, especially if you're going to buy a copy before you shove it down their throat.
Corey: Oh, in fact, we’ll do more than that. We'll give people a discount on the early copy of the book. You can check it out at manning.com in their Manning early access program with the discount code of PODSCREAM20 and get a few bucks off.
Jeff: Because if you're going to shove a book down someone's throat, you should at least get 40% off.
Corey: 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.
Jeff: Oh gosh.
Corey: 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'd half-written and then you pitched it to someone? Did they come 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're getting into? How did it happen?
Jeff: 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, 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’d 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. I really didn't think this through. This is kind of tough. You're working 8-, 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 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 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 four chapters of the book, and you send it to some internal reviewers. Oh, man, you want to talk about just biting your nails, talking about 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.
Corey: Yeah, the line I've heard is, “No one wants to write a book. Everyone wants to have written a book.”
Jeff: Yes, exactly, exactly. One of the funny stories, we—titling a book as 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 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, and her very first chapter is titled “Demystifying DevOps.” So, I'm like, “Well, I'm going to put this on the shelf. Not going to read this until I finish my book.” And then we went through the process of retitling again.
Corey: You don't want to accidentally rip people off. That never goes well.
Jeff: Right, right. So, I was like, “All right, so I'll have to read that when I'm finished with mine.”
Corey: One last question before we go here. You are one of the organizers behind BITCon.
Jeff: 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. We did an event here in Chicago with the CIO of Illinois, and he pulled me aside, he was like, “Jeff, I was at BITCon last year. What do I got to do to get this in Chicago?” And I was like, “I think you just did it.” So—
Corey: Oops.
Jeff:—the powers-that-be started talking about it, and 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 finalize the actual location, but if you go to blacksintechnology.net, feel free to keep an eye out there. We'll be posting updates as they come along.
Corey: 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?
Jeff: 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.
Corey: Excellent. It’s just 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.
Jeff: 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, here it is—I mean, we started talking about this in December of last year, what it was going to take getting the ground crew together to be able to hit the ground running as things heat up, and it feels like 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 were 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 looking forward to a kind of sort of, you know…
Corey: Again, similar to the book thing, it feels like it's going to be better to have done it than to be doing it.
Jeff: 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 going to be exciting. So, I'm just looking forward to being able to have something that my kids can look at and say, “Oh, my dad did that,” because being able to show something to your kids and be like, “Hey, listen, you can do this. 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 out there. It wasn't in Schenectady, everything happened out there. So, I've always thought it is so great to be able to show my kids 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 biggest drivers that's been going for me is the kids.
Corey: Kids are one of those things that just changes every, I guess, priority calculation you have. Everything that I wound up doing is somehow influenced by having a kid even though it doesn't look like that. It completely reshapes your entire worldview, I think it's the best way to frame that.
Jeff: Dude, you have no idea. I didn't understand it until—so, I've got this thing about priorities, and I don't believe in multiple priorities. 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 a kid because when something happens with them, everything else takes a backseat. That's the priority, and you realize like, 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.
Corey: Absolutely.
Jeff: And they make me drink.
Corey: 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’ll go super well. So, if people want to hear more about your thoughts on the world, obviously, there's the [00:35:20 book with the discount code]. But where else can they find you?
Jeff: You can find me on Twitter is probably the best place. I'm @DarkAndNerdy on Twitter. That's usually where, 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.
Corey: Fantastic. Thank you so much for taking the time to speak with me today. I appreciate it.
Jeff: Thanks for having me, man. Had a great time chatting.
Corey: 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.
Announcer: 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 HumblePod production. Stay humble.