Screaming in the Cloud - Empathy Driven Management and Engagement with Tim Banks

Episode Date: August 4, 2022

About TimTim’s tech career spans over 20 years through various sectors. Tim’s initial journey into tech started as a US Marine. Later, he left government contracting for the private sector, working both in large corporate environments and in small startups. While working in the private sector, he honed his skills in systems administration and operations for large Unix-based datastores.Today, Tim leverages his years in operations, DevOps, and Site Reliability Engineering to advise and consult with clients in his current role. Tim is also a father of five children, as well as a competitive Brazilian Jiu-Jitsu practitioner. Currently, he is the reigning American National and 3-time Pan American Brazilian Jiu-Jitsu champion in his division.Links Referenced:Twitter: https://twitter.com/elchefe

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. 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 slash screaming in the cloud. Observability, it's more than just hipster monitoring. 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 CodePipeline, EKS, ECR, and more, as well as things you're likely to actually be using. Deploy on AWS, secure with Snyk, learn more at snyk.co slash scream. That's s-n-y-k.co slash scream. 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? 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. Yes, yes. What you can't see while recording this is I'm actually sitting in the same room as Tim

with a weapon pointed at him to make sure that he stays exactly on massive... I kid, 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 reInvent, I think, because reInvent is such a blur for me. I don't remember who the hell I talked to. Someone can walk up and say, oh yeah, we met at reInvent. 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 purely distributed company, purely distributed work. 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, who you are as a person. And then you get to like check yourself. Was I right? Was I wrong? I think, 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, is 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 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 javi that 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 a strange way where 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 the read on what someone is like, I think. 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 the 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, 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, that's not going to last. A person cannot just be an automaton in perpetuity and expect them to grow and thrive. And this is why you're leaving. And I want to give that a little context because without it

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 Dunkville 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 Duckville 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 is a strong

likelihood that they don't know the half of it yet. One of the things that I like about the Duckbill Group and how my time here has been was 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 was 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. This analogy was given to me somewhere else and i love it 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 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 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 expect them to hit them. And that doesn't work. That's not something that's sustainable. And it 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 of the things that the duck book I love succeeding doesn't necessarily mean that I'm going to stay at war or your engineers can stay at one place in perpetuity. If you mentor and train and coach and give an engineer opportunities to grow and thrive, and what they do is they go to another job for a title increase and a pay increase, something like that, you did your job. A lot of companies love to tell that lie, and they almost convince themselves of it. 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 you magically always like 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 slap onto an interview questionnaire. You actually have to mean it. People can see through insincerity. And it's one of those 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 to expect people to stay in a place where they have grown past or grown out of. You 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 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 you 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. 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 listening to this, thinking that we're somehow subtweeting you with our voices, I don't know what that is. Subwoofing, maybe? Is that what a subwoofer is? I'm not an audio person.

Throwing shade. We'll just say call it throwing shade. Yeah, we are not throwing shade at any one person, team, or group in particular. These are recurring things. Tim, what have you seen? 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 that there are engagements that we are moving away from this legacy platform or for this

thing that we have been doing for X amount of time. And everyone has staked out their 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 Helm charts or Terraform or CloudFormation. You fix that by conversations and you fix that by listening and 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 can say,

great, now you're going to learn, you can do this on 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 those communication bridges between management and leadership. And that's almost in every time occurrence. At some point or another, there's some disconnect there. And that's the best part of the job. The reason I do this consulting gig is not because I want to bang away at code. If I have 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, but sometimes they don't know how to. And that is the common thing, I think, through all of our customers. 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. They're people problems. They're the duck boat group. We're basically marriage counseling for engineering and finance. We really are. This is why we're people, not software. Yeah.

And I will say this very firmly, and you can quote me on this. You cannot replace us. You cannot replace the kind of engagements we do with software. You can't. It can't be done, right? Software is not empathetic. 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 and 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 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. Our engagements are 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 going to start pulling at strings and kicking over rocks and seeing what we find. And that's the kind of thing that 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? 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.

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 10 things you're supposed to do all the time. We would be really, really crappy consultants if we just said, 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, 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. That's where I think a lot of things

miss. 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. It's a possible advisor at absolute best. It will give you suggestions that have no context. 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 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's 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. So a lot of times folks come in, they need quick wins, or they don't really need us to deep dive into all their DynamoDB access patterns, right? They just want to 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 you think they're going to save you.

And then folks have really enjoyed that type of engagement. And it's one of my favorite ones to do. 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 wits. 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 Duck Bill 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, 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've run tests and learned 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 realize that was too high. So back in March, you then spent 19 cents. And then $3.06 in February. You spent $0.44, and you realize that was too high. So back in March, you then spent $0.19, and then $3.01 back in April. May wound up $10.02, and now you're $9.84 as of June. July is 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, called economists, we're 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 running EC2 instances forever. Imagine that. And your account is a perfect microcosm of that entire philosophy. Well, I don't know all the answers, right? And I will never profess to know 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 see if it's possible. Right? And so just let me,

let me just see, can you do this? Does this work? No, I guess it doesn't. Or AWS document, especially AWS documentation says this. Let me see if that's actually the case. I don't believe that they intend to lie, but they also certainly don't get it correct all the time. And to be fair, they have what, 728 services by this point? That's a lot of documentation. Three more have launched since the start of this recording. Yeah, actually. Well, by the time this hits, there probably might be 22.

But we'll 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 at a convenience like, well, I don't want to run this on this.

Let me just fire it up because it's not my money. 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. It's not a thing where I'm going to say, I know YAML off the top of my head and 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 are 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 minutiae. And you will have seen just as good as anyone else is, 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. 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 freaking 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 distinctive sense to you. And you're basically just leave people stunned and they're all 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, no, no, you're just doing your thing, Tim. Just keep on doing it. That's fine. Yeah, it's funny because I, like you, one of the things that I've really enjoyed about 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 we 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. We are not really, really good at what we do because we don't rely or talk to or have conversations with other people.

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 expect it to be. are 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 bill. 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, yeah, 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 in 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. 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 especially in smaller orgs where that velocity is very, very important, they don't have six to eight weeks for that. They can't dedicate the resource to those deep dives all the time and all the conversations and when we do a COP, it is exhaustive. We are exploring every avenue to almost an absurd level. And that's not the right engagement for a lot of orgs. So coming in and saying, hey, this is a quick win. These are the things you can do.

This is 90% of the savings you're going to realize. These things, bam, bam, bam, bam, bam. And then we give it to folks and we let them work on it. And then they're like, hey, we need this because we want to negotiate an EDP. Or we need this because 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 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 to 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 just like look i just need to save x amount of money on my aws bill and and can you do that well sure we can go in there and have those conversations and give you a lot of savings and it's's very much, 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 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. One other aspect that I really like 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? It never felt great to talk to them and say, oh, just go screw up your AWS bill some more. 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 a 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 multi-million 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 gateways 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 freaking 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. Oh, absolutely. And I think the impact that you make for the future of a smaller company is much higher, right? You go in there and you have an engagement, and 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. 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.

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? The best way to find me is on Twitter. I am at 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. No, I think it is pretty clear that we are basically going to be both of their plus ones forever. I think so. I'm just waiting for them when they pull 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.

Well, you do have velour tracksuits too, right? Not yet, but please don't tell that to Bethany. Tim, it has been an absolute pleasure. The pleasure has been all mine, Corey. I really appreciate it. 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. 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. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying.

The Duck Bill Group works for you, not AWS. We tailor recommendations to your business, and we get to the point. Visit duckbillgroup.com to get started. This has been a HumblePod production. Stay humble.