Transcript

Announcer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, 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 sponsored in part by Honeycomb. When production is running slow, it’s hard to know where problems originate. Is it your application code, users, or the underlying systems? I’ve got five bucks on DNS, personally. Why scroll through endless dashboards while dealing with alert floods, going from tool to tool to tool that you employ, guessing at which puzzle pieces matter? Context switching and tool sprawl are slowly killing both your team and your business. You should care more about one of those than the other; which one is up to you. Drop the separate pillars and enter a world of getting one unified understanding of the one thing driving your business: production. With Honeycomb, you guess less and know more. Try it for free at honeycomb.io/screaminginthecloud. Observability: it’s more than just hipster monitoring.

Corey: I come bearing ill tidings. Developers are responsible for more than ever these days. Not just the code that they write, but also the containers and the cloud infrastructure that their apps run on. Because serverless means it’s still somebody’s problem. And a big part of that responsibility is app security from code to cloud. And that’s where our friend Snyk comes in. Snyk is a frictionless security platform that meets developers where they are - Finding and fixing vulnerabilities right from the CLI, IDEs, Repos, and Pipelines. Snyk integrates seamlessly with AWS offerings like code pipeline, EKS, ECR, and more! As well as things you’re actually likely to be using. Deploy on AWS, secure with Snyk. Learn more at Snyk.co/scream That’s S-N-Y-K.co/scream

Corey: Welcome to Screaming in the Cloud. I’m Corey Quinn. A bit of a sad episode Today. I am joined by Duckbill Group principal cloud economist, Tim Banks, but by the time this publishes, he will have left the Duckbill nest, as it were. Tim, thank you for joining me, and can I just start by saying, this is sad?

Tim: It is. I have really enjoyed being with Duckbill and I will never forget that message you sent me. It’s like, “Hey, would you like to do this?” And I was like, “Boy would I.” It’s been a fantastic ride and I have enjoyed working with a friend. And I’m glad that we remain friends to this day and always will be, so far as I can tell.

Corey: Yes, yes. What you can’t see while recording this, I’m actually sitting in the same room as Tim with a weapon pointed at him to make sure that he stays exactly on message. Yeah, I kid. There’s been a lot that’s happened over the last year. We only got to spend time together in person once at re:Invent. I think because re:Invent is such a blur for me, I don’t remember who the hell I talk to.

Someone can walk up and say, “Oh yeah, we met at re:Invent,” and I’ll nod and say, “Oh yeah,” and I will have no recollection of that whatsoever. But you don’t argue with people. But I do distinctly remember hanging out with you there. But since then, it’s been a purely distributed company, purely distributed work.

Tim: Yeah, that’s the only time I’ve seen you since I’ve worked here. It’s the only time I met Mike. But it’s weird because it’s like, someone you work with you see every day virtually and talk to, and then you actually get to, like, IRL them and like, “Oh, wow. I had all these, kind of, conceptions of, you know, what you are or who you are as a person, and then you get to, like, check yourself. Was I right? Was I wrong?” I was like, “Oh, you’re taller than I thought; you’re shorter than I thought,” you know, whatever it was.

But I think the fun part about it was we all end up being so close by the nature of how we work that it was just like going back and seeing family after a while; you already know who they are and how they are and about them. So, it felt good, but it felt familiar. That’s a great feeling to have. To me, that’s a sign of a very successful distributed culture.

Corey: Yeah, it’s weird the kinds of friendships we’ve built during the pandemic. When I was in New York for the summit, I got to meet Linda Haviv at AWS for the first time, despite spending the past year or so talking to her repeatedly. As I referred to her the entire time I was in New York, this is Linda, my new old friend because that is exactly how it felt. It’s the idea of meeting someone in person that you’ve had a long-term ongoing friendship with. It’s just a really—it’s a strange way Everything’s new but it’s not, all at the same time.

It reminds me of the early days of the internet culture where I had more friends online than off, which in my case was not hard. And finally meeting them, some people were exactly like they were described and others were nothing at all like they presented. Now that we have Zoom and this constant level of Slack chatter and whatnot, it’s become a lot easier to get a read on what someone is like, I think.

Tim: I think so too, you know, we’ve gotten away—and I think largely because of the pandemic—of just talking about work at work, right? The idea of embracing, you know, almost a cliche of the whole person. But it’s become a very necessary thing as people have dealt with pandemic, social upheaval, political climates, and whatever, while they’re working from home. You can’t compartmentalize that safely in perpetuity, right? So, you do end up getting to know people very well, especially in what their concerns are, what their anxieties are, what makes them happy, what makes them sad, things that go on in their lives.

You bring all that to your distributed culture because it’s not like you leave it at the door, when you walk out. You’re not walking out anymore; you’re walking to another room, and it’s hard to walk away from those things in this day and age. And we shouldn’t have to, right? I feel like for a successful and nurturing culture—whatever it is, whether it’s tech culture, whether it’s whatever kind of work culture—you can’t say, “I only want your productivity and nothing else about you,” and expect people to sustain that. So, you see these companies are, like, you know, “We don’t have political discussions. We don’t have personal discussions. We’re just about the work.” I’m like, “All right, well, that’s not going to last.” A person cannot just be an automaton in perpetuity and expect them to grow and thrive.

Corey: And this is why you’re leaving. And I want to give that a little context because without, sounds absolutely freaking horrifying. You’ve been a strong advocate for an awful lot of bringing the human to work, on your philosophy around leadership, around management. And you’ve often been acting in that capacity throughout, I would say, the majority of your career. But here at The Duckbill Group, we don’t have a scale of team where you being the director of the team or leader of the team is going to happen in anything approaching the near or mid-term.

And so, much of your philosophy is great and all because it’s easy to sit here at a small company and start talking about, “Oh, this is how you should be doing it.” You have the opportunity to wind up making a much deeper impact on a lot more people from a management perspective, but you do in fact, need a team to manage as opposed to sitting around there, “Oh, yeah. Who do you manage?” “This one person and I’m doing all of these things to make their life and job awesome.” It’s like, “Yeah, how many hours a week are you spending in one-on-ones?” “20 to 25.”

Okay, maybe you need a slightly larger team so you can diffuse that out a little bit. And we are definitely sad to be losing you; super excited to see where you wind up going next. This has been a long time coming where there are things that you have absolutely knocked out of the park here at The Duckbill Group, but you also have that growing—from what I picked up on anyway—need to set a good management example. And lord knows this industry needs more of those. So first, sad to lose you. Secondly, very excited for where you wind up next and what they’re in for, even though it has a strong likelihood that they don’t know the half of it yet.

Tim: One of the things that I like about The Duckbill Group and how my time here has been is the first thing that I was asked in the interview was very sincere, like, “Well, what’s your next job?” And I was very clear. It’s like, “After this, I want to be a director or VP of engineering because I would like to be a force multiplier, right?” I would like to make engineering orgs better. I would like to make engineering practices better. I want to make the engineers better, right?

And not by driving KPIs and not by management, right, not administrative functions. I want to do it via leadership. I want to do it by setting examples, making safe places for people, making people feel like they’re important and invested in, nurturing them, right? I’ve said this before I—this analogy was getting me somewhere else and I love, it’s like, if I plant a tree and I want it to grow apples, right, I’m not going to sit there and put a number down of apples it’s expected to produce, and then put it on a performance plan if it doesn’t get that number of apples, right? I need to nurture the tree, I need to fertilize it, I need to protect it, I need to keep it safe, I need to keep it safe from the elements, I need to make sure that it doesn’t have parasites, I need to take care of that tree.

And if that tree grows and it’s healthy and it’s thriving, it will produce, right? But I’m not—I can’t just expect apples if I’m not taking care of the tree. Now, people are not trees, but you still have to take care of the people if you want them to do things. And if you can’t take care of the people, if you can’t manage the environment that they’re in to make it safe, if you can’t give them the things they need to be successful, then you’re just going to be holding numbers over someone and expecting to hit them.

And that doesn’t work. That’s not something that’s sustainable. And it doesn’t really—it’s not even about how much you pay them. You must pay them well, right, but it has to be more than just that if you want people to succeed. And that doesn’t necessarily mean—like, one thing is at the Duckbill Group I love, succeeding doesn’t necessarily mean that I’m going to stay at—or your engineer is going to stay at one place in perpetuity. If you mentor and train and coach and give an engineer opportunity to grow and thrive and what they do is they go to another job for a title increase and a pay increase or something like that, you did your job.

Corey: A lot of companies love to tell that lie and they almost convince themselves of it where I look at your resume, and great you have not generally crossed the two-year mark at companies for the last decade. I never did until I started at this place. But we magically always liked to pretend in job interviews that, “Oh yeah, this is my forever job—” like you’re a rescue dog getting adopted or something, “—and I’m going to work here for 25 years and get a gold watch and a pension at the end of it.” It’s lunacy. I have never seen the value in lying to ourselves like that, which is why we start our interviews with, “What’s the job after this and how do we help you get there?”

It’s important that we ask those questions and acknowledge that reality. And the downside to it—if you can call it a downside—is you’ve got to live by it. It’s not just words, you can slop onto an interview questionnaire; you actually have to mean it. People can see through insincerity.

Tim: And it’s one of the things, like, if you run an org and you grow your people and you don’t have a place for them to grow into, you should expect and encourage them to find those opportunities elsewhere. It is not reasonable, I feel like, as a leader for you expect people to stay in a place where they have grown past or grown out of. You need to either need to give them a new pot to grow into or you need to let them move elsewhere and thrive and grow. And moving elsewhere—like, if you have a retention problem where you can’t retain anybody, that’s a problem, but if you have your junior engineers who become senior engineers at other places, right, and everyone leaves on good terms, and they got the role and you gave them a great recommendation and they give glowing recommendations to you, there’s nothing wrong with that. That’s not a failure; that’s success.

Corey: One bit of I would say pushback that I suspect you might get when talking to people about what’s next is that, “Well, you are just a consultant, on some level, for a year.” You always know that someone is really arguing in good faith when they describe what you did with the word ‘just,’ but we’ll skip past that part. And it’s, “You’re just a consultant. What would you possibly know about team management and team dynamics?” And there is a little bit of truth to that insofar as the worst place in the world to get management advice is very clearly on Twitter.

It turns out that most interpersonal scenarios are, one, far too personal to wind up tweeting about, and two, do not lend themselves to easy solutions that succinctly fit within 280 characters. Imagine that. The counter-argument though, is that you have—correctly from where I sit—identified a number of recurring dynamics on teams that you have encountered and worked with deeply as a large number of engagements. And these are recurring things, I want to be clear. So, I’m not talking about one particular client. If you’re one of our clients and listen to this thinking that we’re somehow subtweeting you with our voices—I don’t know what that is; subwoofing, maybe?

Tim: [crosstalk 00:12:05]—

Corey: Is that what a subwoofer is? I’m not an audio person.

Tim: Throwing shade, we’ll just say—call it throwing shade.

Corey: Yeah, we’re not throwing shade at any one person, team, or group in particular; these are recurring things. Tim, what have you seen?

Tim: And so, I think the biggest thing I see is folks that are on the precipice of a big technological change, right, and there is an extraordinary amount of anxiety, right? I’ve seen a number of customers through our engagements that, “We are moving away from this legacy platform,” or from this thing that we have been doing for X amount of time. And everyone has staked the other domains, staked out their areas of expertise and control and we’re going to change that. And the solution to that is not a technical solution. You don’t fix that by Helm charts, or Terraform, or CloudFormation. You fix that by conversations, and you fix that by listening. You fix that by finding ways to reassure folks and giving them confidence in their ability to adjust and thrive in a new environment.

If you take somebody who’s been, you know, an Oracle admin for 20 years, and you going to say, “Great. Now, you’re going to learn, you’re going to do this an RDS,” that’s a whole new animal, and folks feel like, well, you know, I can’t learn something new like that? Well, yeah you can. If you can learn Oracle, you can learn anything. I firmly believe that.

But that’s one of the conversations we have, it’s never, almost never a technical problem folks have. We need to reassure people, right? And so, folks who reach out to us, it’s typically folks who are trying to get their organizations in that direction. Another thing we see sometimes is that we find that there’s a disconnect between leadership and the engineers. They have either different priorities or different understandings of what’s going on. And we come in to solve a problem, which may be cost but that’s not the problem we actually solve. The problem we actually solve is fixing this communication bridges between management and leadership.

And that’s almost an every time occurred. At some point or another, there’s some disconnect there. And that’s the best part of the job. Like, the reason I do this consulting gig is not because I want to bang away at code. If I’ve had to do that, that’s an anomaly for sure because I want to have these conversations.

And people want to have these conversations; they want to get these problems solved and sometimes they don’t know how to. And that is the common thing, I think, through all of our customers. Like, we need some amount of expertise to help us find solutions to these things that aren’t necessarily technical problems. And I think that’s where we run into problems as an industry, right, where we think a lot of things are technical problems or have technical solutions, and they don’t. There are people problems. They’re—

Corey: Here at The Duckbill Group, we’re basically marriage counseling for engineering and finance in many cases.

Tim: We really are.

Corey: This is why were people not software.

Tim: Yeah. And I will say this very firmly and you can quote me on this: like, you cannot replace us. You cannot replace the kind of engagements we do with software. You can’t. Can’t be done, right? Software is not empathetic.

Corey: There are a whole series of questions we ask our clients at the start of an engagement and the answers to those questions change what we ask them going forward. In fact, even the level-setting in the conversation that we have at the start of that changes the nature of those. We’re not reading from a list; we’re trying to build an understanding. There is a process around what we do, but it’s not process that can ever be scoped down to the point where it’s just a list of questions or a questionnaire that isn’t maddening for people to fill out because it’s so deeply and clearly misses the mark around context of what they’re actually doing.

Tim: Mm-hm. Our engaged with their conversations. That’s all they are. They’re really in-depth conversations where we’re going to start asking questions and we’re going to ask questions about those answers. We’re start pulling out strings and kicking over rocks and seeing what we find.

And that’s the kind of thing that, you know, you would expect anyone to do who’s coming in and saying, “Okay, we have a problem. Now, let’s figure it out.” Right? Well, you can’t just look at something on the surface, and say, “Oh, I know what this is.” Right? You know, for someone to say, “Oh, I know how to fix this,” when they walk in is the surest way to know that someone doesn’t know what they’re talking about, right?

Corey: Oh, easiest thing in the world is to walk in and say, “This is broken and wrong.” That can translate directly to, “Hi, I am very junior. Please feed my own ass to me.” Because no one shows up at work thinking they’re going to do a crap job today on purpose. There’s a reason things are the way that they are.

Tim: Mm-hm. And that’s the biggest piece of context we get from our customers is we can understand what the best practices are. You can go Google them right now and say, “This is the ten things you’re supposed to do all the time,” right? And we would be really, really crappy consultants if we just read off that list, right? We need to have context: does this thing make sense? Is this the best practice? Maybe, but we want to know why you did it this way.

And after you tell us that way, I’m like, “You know what? I would do it the exact same way for this use case.” And that’s great. We can say like, “This is the best way to do that. Good job.” It’s atypical; it’s unusual, but it solves the problems that you need solving.

And that’s where I think a lot of people miss. Like, you know, you can go—and not to throw shade at AWS’s Trusted Advisor, but we’re going to throw shade at AWS’s Trusted Advisor—and the fact that it will give you—

Corey: It is Plausible Advisor at absolute best.

Tim: [laugh]. It will give you suggestions that have no context. And a lot of the automated AI things that will recommend that you do this and this and this and this are pretty much all the same. And they have no context because they don’t understand what you’re trying to do. And that’s what makes the difference between people. There’s these people problems.

And so, one of the things that I think is really interesting is that we have moved into doing a shorter engagement style that is very short. It’s very quick, it’s very kind of almost tactical, but we go in, we look at your bill, we ask you some questions, and we’re going to give you a list of suggestions that are going to save you a significant amount of money right away, right? So, a lot of times, folks when they need quick wins, or they don’t really need us to deep-dive into all their DynamoDB access patterns, right? They just want like, “Hey, what are the five things we can do to save us some money?” And we’re like, “Well, here they are. And here’s what we think they’re going to save you.” And folks who really enjoyed that type of engagement. And it’s one of my favorite ones to do.

Corey: This episode is sponsored in part by LaunchDarkly. Take a look at what it takes to get your code into production. I’m going to just guess that it’s awful because it’s always awful. No one loves their deployment process. What if launching new features didn’t require you to do a full-on code and possibly infrastructure deploy? What if you could test on a small subset of users and then roll it back immediately if results aren’t what you expect? LaunchDarkly does exactly this. To learn more, visit launchdarkly.com and tell them Corey sent you, and watch for the wince.

Corey: I can also predict that people are going to have questions for you—probably inane—of, well, you were a consultant, how are your actual technical chops? And I love answering these questions with data. So, I have here pulled up the last six months of The Duckbill Group’s AWS bills. And for those who are unaware, every cloud economist has their own dedicated test account for testing out strange things that we come across. And again, can the correct answer in many consulting engagements is, “I don’t know, but I’ll find out.”

Well, this is how we find out. We run tests and learn these things ourselves. I suppose we could extend this benefit, if you want to call it that, to people who aren’t cloud economists but I’m not entirely sure what, I don’t know, an audio engineer is going to do with an AWS account that isn’t, you know, kind of horrifying. To the audio engineer that is editing this podcast, my condolences if you take that as a slight, and if there is something you would use an AWS account for, please let me know. We’ll come talk about it here.

But back to topic, looking at the last six months of your bill for your account—that’s right, a ritualistic shaming of the AWS bill—in January you spent $16.06. In February, you spent 44 cents. And you realized that was too high, so back in March, you then spent 19 cents. And then $3.01 back in April. May wound up $10.02, and now you’re $9.84 as of June. July has not yet finalized as of this recording.

And what I want to highlight—and what that tells me when I look at these types of bills—and I assure you as the world’s leading self-described expert in AWS billing, I’m right; listening to me is a best practice on these things—that shows the exact opposite of a steady-state workload. There’s a lot of dynamism to those giant swings because we don’t have cloud economists who are going to just run these things steady-state for the rest of our lives. Those are experiments of building and testing out new and exciting things in a whole bunch of very weird, very strange ways. Whenever I wind up talking to someone in one of the overarching AWS services at AWS and I pull up my account, a common refrain is, “Wow, you use an awful lot of services.” Right. I’m not just sitting here run and EC2 instances forever. Imagine that. And your account is a perfect microcosm of that entire philosophy.

Tim: Well, I don’t know all the answers, right? And I will never profess all the answers. And before I say, “You should do this—” or maybe I will say, “You might be able to do this. Let me go save as possible.” [laugh]. Right? And so, just let me just see, can you do this? Does this work? No, I guess it doesn’t. Or AWS docu—especially, “The AWS documentation says this. Let me see if that’s actually the case.”

Corey: I don’t believe that they intend to lie, but—

Tim: No.

Corey: —they also certainly don’t get it correct all the time.

Tim: And to be fair, they have, what, 728 services by this point, and that’s a lot of documentation you’re not going to get—

Corey: Three more have launched since the start of this recording.

Tim: I—yeah, actually—well, by the time this hits, they’re probably going to have 22. But we’ll [laugh] see. But yeah, no. And that’s fine. And they’re not going to have every use case, and every edge, kind of like, concern handled, and so that’s why we need to kick the tires a little bit.

And what I think more than anything else is, you know, sometimes we just do things out of convenience. Like, “Well, I don’t want to run this on this; let me just fire it up because it’s not my money.” [laugh]. But we also want to be fairly concerned about you know, how we do things. You don’t want to run a fleet of z1ds, obviously.

But there is a certain amount of tire-kicking and infrastructure spinning up that you have to do in order to maintain freshness, right? And it’s not a thing where I’m going to say, “Oh, I know YAML off the top of my head, and I need to do—you know, I’m up to speed on every single possible API call that you can make.” No. My technical prowess has always been in architecture and operations. So, I think when we have these conversations, folks mostly tend to be impressed by not only business acumen and strategy, but also being able to get down to the weeds and talking with the developers and the engineers about the minutia. And you will have seen you know, the feedback that I’ve gotten about my technical prowess has always been good. You know, I can hang with anybody, I feel like.

Corey: I would agree wholeheartedly. It’s been really interesting watching you in conversations, internally and with our clients, where you will just idly bust out something fricking brilliant out of left field. And most of the time, I don’t think you even realize it. It’s just one of those things that makes intuitive and instinctive sense to you. And you basically just leave people stunned and their scribbling notes and trying to wrap their heads around what you just said.

And it’s adorable because sometimes you wind up almost, like, looking embarrassed, like, “Did I say something rude and not realize it? Like, I wasn’t trying to be insulting.” It’s like, “Nope, nope. You’re just doing your thing, Tim. Just keep on doing it. That’s fine.”

Tim: Yeah, it’s funny because, like you, one of the things that I’ve really enjoyed about it is, like, we’ll just start bouncing ideas off of each other and come up with something brilliant. “Yeah, let’s do that.” And then, “Okay, this is now a thing.” And it’s like, you know, there’s something to be said about being around smart people. So, it’s not just me coming up with something brilliant; these are almost always fruits of a conversation and discussion being had, and then you formulate something great in your head.

But again, this is why I love the aspect of talking and having conversations with people, so that way you can come up with something kind of brilliant. None of this is done in a silo. Like we’re not really, really good at what we do because we don’t rely or talk to or have conversations with other people.

Corey: One thing that you did that I think is one of the most transformative things that has happened in company history in some respects has been when you started, and for the first half of your tenure here, we had two engagement types that we would wind up giving our consulting clients. There’s contract negotiation, where we help companies negotiate their long-term commitment contracts with AWS—and we’re effective at it and that’s fun; that’s basically what you would more or less expected to be—and the other is our cost optimization project engagements. And those tend to look six to eight weeks where we wind up going in deep-dives into the intricacies of an organization’s AWS accounts, bills, strategy, growth plan, et cetera, et cetera, et cetera, to an exhaustive level of detail. And in an interest of being probably overly transparent here, I didn’t like working on those engagements myself. I like coming in, finding the big things that will be transformative to reduce the bills—it’s like solving a puzzle—and then the relatively in-depth analysis for things that are a relatively paltry portion of the AWS bill does not really lead me to enjoying the work very much.

And I beat my head against that one for years. And you busted out one day with an idea that became our third type of engagement, which is the first pass, where we charge significantly less for the engagement and it essentially distills down into you get us to talk to your engineering teams for a day. Bring us any questions, give us access in advance to these things, and we will basically go on a whirlwind guided tour and lay waste to your AWS bill and highlight different opportunities that we see to optimize these things. And it has been an absolute smash success. People love the engagements.

Very often, it leads to that second full-bore engagement that I was describing earlier, but it also aligns very well with the way that I like to think about these things. I’m a great consultant, specifically because once I’ve delivered the value, I like to leave. Whereas as an employee, I just sort of linger around, and then I go cause problems and other people’s departments—ideally, not on purpose, but you know, I am me—and this really emphasizes that and keeps me moving quickly. I really, really like that engagement style and I have you to thank for coming up with the idea and finding a way to do it that didn’t either not resonate with the market—in which case, we’re not selling a damn thing—or wound up completely eviscerating the value of the longer-term deep-dive engagements, and you threaded that needle perfectly.

Tim: I thank you; I appreciate that. There was this kind of vacuum that I saw where, both from a cost and from a resource point where six to eight weeks is a long time for an engineering org to dedicate to any one thing, especially if that one thing isn’t directly making money. But engineering orgs are also very interested in saving money. But it’s especially in smaller orgs where that velocity is very important, they don’t have six to eight weeks for that. They can’t dedicate the resources to those deep-dives all the time, and all the conversations we—and when we do a COP, it is exhaustive. We are exploring every avenue to almost an absurd level, right?

And that’s not the right engagement for a lot of orgs, right? So, coming in and saying, “Hey, you know, this is a quick one; these are the things that you can do. This is 90% of the savings you’re going to realize. These things: bam, bam, bam, bam, bam.” Right?

And then we give it to the folks and we let them work on it, and then they’re like, “Hey, we need this because we want to negotiate EDP,” or, “We need this because, you know, we’re just trying to make sure that our costs are in line so we can be more agile, so we can do this project, or whatever.” Right? And then there are a lot of other orgs that do need that exhaustive kind of thing, larger orgs especially, right? Larger, more complex orgs, orgs that are trying to maybe—like, if you’re trying to make a play to get acquired, you want to get this very, very in-depth study so you know all your liabilities and all your assets, so that way you can fix those problems and make it very attractive for someone to buy you, right? Or orgs that just have, like, we are not having an impending EDP; we have a lot of time to be able to focus on these things, and we can build this into the roadmap, right?

Then we can do a very exhaustive study of those things. But for a lot of times, people are just like, “Look, I just need to save X amount of money on my AWS bill and can you do that?” Well, sure. We can go in there and have those conversations and give you a lot of savings. And I’m very much in the camp of, you know, ‘perfect is the enemy of good.’ I don’t have to save down to the nth penny on your DynamoDB bill. But if I can, shave—cut it in half, that’s great. Most people are very happy about those kinds of things. And that’s a very routine finding for us.

Corey: One other aspect that I really liked about it, too, is that it let us move down market a bit, away from companies that are spending millions of dollars a month. Because yeah, the ROI for those customers is a slam dunk on virtually any engagement that we could put together, but what about the smaller companies, the ones that are not spending that much money, yet? They’ve never felt great talk to them and say, “Oh, just go screw up your AWS bill some more. Then, then you will absolutely be able to generate some value. Maybe turn off MFA and post your credentials to GitHub or something. That’ll speed up the process nicely.”

That’s terrible advice and we can’t do it. But this enables us to move down to smaller companies that are earlier in their cloud estate build-out or are growing organically rather than trying to do a giant migration as sort of greenfield growth approach. I really, really like our ability to help companies that are a bit earlier in their cloud journey, as well as in smaller environments, just because I guess, on some level, for me, at least, when you see enormous multimillion-dollar levels of spend, the misconfigurations are generally less fun to find; they’re less exciting. Because, yeah at a small scale, you can screw up and your Managed NAT Gateway bill is a third of your spend. When you’re spending $80 million a year, you’re not wasting that kind of money on Managed NAT Gateways because that misconfiguration becomes visible from frickin’ orbit.

So, someone has already found that stuff. And it’s always then it’s almost certainly EC2, RDS, and storage. Great. Then there’s some weird data transfer stuff and it starts to look a lot more identical. Smaller accounts, at least from my perspective, tend to have a lot more of interesting things to learn hiding in the shadows.

Tim: Oh, absolutely. And I think the impact that you make for the future for small companies much higher, right? You go in there and you have an engagement, you can say, “Okay, I understand the business reason why you did this here, but if you make these changes—bam, bam, bam—12 to 18 months and on, right, this is going to make a huge difference in your business. You’re going to save a tremendous amount of money and you’re going to be much more agile.”

You did this thing because it worked for the POC, it worked for the MVP, right? That’s great, but before it gets too big and becomes load-bearing technical debt, let’s make some changes to put you in a better position, both for cost optimization and an architectural future that you don’t have to then break a bone that’s already set to try and fix it. So, getting in there before there’s a tremendous load on their architecture—or rather on their infrastructure, it’s super, super fun because you know that when you’ve done this, you have given that company more runway, or you’ve given them the things they need to actually be more successful, and so they can focus their time and efforts on growth and not on trying to stop the bleeding with their AWS bill.

Corey: Tim, it’s been an absolute pleasure to work with you. I’m going to miss working with you, but we are definitely going to remain in touch. Where can people find you to follow along with your continuing adventures?

Tim: The best way to find me is on Twitter, I am @elchefe—E-L-C-H-E-F-E. And yeah, I will definitely keep in touch with you, Corey. Again, you have been a tremendous friend and I really appreciate you, your insights, and your honesty. Our partners are friends with each other and I do not think that they will let us ever drift too far apart. So.

Corey: No, I think it is pretty clear that we are basically going to be both of their plus-ones forever.

Tim: [laugh]. I think so.

Corey: I’m just waiting for them when they pulled the prank of dressing us the exact same way because our styles are somewhat different, and I’m pretty sure that there’s not a whole lot of convergence where we both wind up looking great. So, it’s going to be hilarious regardless of what direction it goes in.

Tim: Well, you do have velour tracksuits too, right?

Corey: Not yet, but please don’t tell that to Bethany.

Tim: [laugh].

Corey: Tim, it has been an absolute pleasure.

Tim: The pleasure has been all mine, Corey. I really appreciate it.

Corey: Tim Banks, for one last time, principal cloud economist at The Duckbill Group. I am Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you’ve enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you’ve hated this podcast, please leave a five-star review on your podcast platform of choice and an insulting comment that says that we are completely wrong in our approach to management and the real answer is as follows, making sure to keep that answer less than 280 characters.

Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.

Announcer: This has been a HumblePod production. Stay humble.