#SYDWAC - Think Big, Think At Scale

Shawn Buttner argues that most system failures come from ignoring how software behaves at scale. Ask three questions upfront: what if load increases tenfold, who maintains this forever, and what hidden assumptions are we making. Real examples include metric mismatches and invoicing systems that broke when repurposed.
Chapters
Certified high performance coach. And today we're talking about thinking big, thinking at scale. Because I've. In my career, I've heard the phrases, this process doesn't work in the UK or we never thought people would try to use this system in this way, and that's why it broke. And these are two phrases of the same issue. It's a too narrow focus on the problem and not enough consideration of what. What happens if this grows? What happens if this persists over time? What happens as this gets bigger? And it's also thinking outside of the problem. So what happens if this system that we use for invoices is now gonna be used to sell stuff? Cause people will try really crazy things, especially as processes and technology get out there in the marketplace. There's a little bit of a creative merge point where people are like, well, maybe I could do it, or I could use this to do it this way. And that's when the weird things happen. So if you've ever been frustrated that something broke, something wasn't working the way that you wanted to either in your business, a business process like the hiring, onboarding process is broke, or, you know, getting your invoices out to everyone, or, you know, you're working on a new project as a former software engineer and, you know, you're. You're trying to focus on this one specific problem, but the need of the business was not well defined. And so you keep solving these little problems, never solving the actual big picture issue. Then this video is for you. I'm really excited to be talking about this. So it also applies to personal life. If you've ever thought, hey, I need to remodel my kitchen, right? People do that, I guess, and this not me, but. So you're going to remodel your kitchen. It's going to take six months, and you get started and you realize, oh, the kitchen's where I cook stuff, you know, and so it's six months of, you know, cooking on a camping stove outside like you're camping instead of inside, like a civilized adult. So, you know, something like that. That's where this idea of thinking more than the problem, considering all the things that could happen, especially over time, especially when we have assumptions that are not challenged, right? So if you've ever again felt frustrated or angry or anxious because something didn't turn out the way it did because you're so narrowly focused, then I have a couple of questions for you to keep in mind that helped me in my tech career because, you know, I remember the first time I Wrote a piece of software and turned it on in my early on in my career. And it was in not just the place where I was in Arkansas, it was the uk, it was Japan, it was, you know, all over the world, like the States, all over the world. And to realize that, wow, there's a lot of things I didn't consider thinking. I was just in a building in the middle of the US and that's where the code would operate. And there's a lot of growing pains, a lot of you fix something somewhere, it breaks somewhere else. Very, very frustrating. And the software engineers that are on understand what I'm talking about. So how do we future proof our processes, our businesses, our systems? Right. I think that's a really big question and I can't cover that completely comprehensively. But I, I think some things to start of if as soon as you can in the process, if you're going to start a new project, a new business process, a new like business itself, it's, you know, what happens If I put 10 times the amount of load on this function? Right. So what happens if I increase my invoices by 10x right now? Is that going to change how our prop. The process that you have of managing it or is it going to change the process of how the technology you use, can it handle that? You know, that kind of question, you know, if there's 10 times as many employees being onboarded, how are you going to manage that process? How are you going to get everyone up to speed and ready to rock in the same way when you're managing a bunch of different communications? Because the communication gets a lot more complicated the bigger you go. And over the long term, the second question is what happens if the this process, if this piece of software runs forever, you know, who is going to maintain it? Who's going to operate the process on an ongoing basis and how might that change what happens? And I know that sounds like a weird thing, but imagine if you will that again. You're going to, you know, you're a company of two, you're going to hire someone and so you have a quick onboarding like here's the systems, here's the passwords, here's what we got to do. Can be really scrappy and really quick when you have to do that for 100 employees that have different functions in different areas and might have different accesses and different everything. Right. It gets a lot more complicated. And if you're the only person that knows all the systems for each of the functions that's going to be miserable, right? You're going to spend all your time doing admin stuff instead of working on your business, talking to people, getting sales, that kind of stuff. So it's really important to think again. Like, as this runs forever, am I going to be the only one that can administer it or do I have to start getting people to be more self sufficient or get other people trained on? So if you're on vacation, you can take vacation. You're not constantly having to phone home to the business. So, okay, what happens if this has 10 times the amount of load on it? What happens if this thing runs forever? Third question I think is overlooked and I think as I got skilled as a software engineer, it's what assumptions are we operating under and are they communicated clearly, especially over time? So if you say, okay, I'm going to write a logistics system, right, where we're going to measure things by pallets in the the U.S. i'm not saying this really happened in my career. And then you're like, okay, we'll take this same system because logistics is logistics, warehouses are warehouses and we'll move it to the uk. But they have specific things that they need to count by weight, right? And it's not in pounds, it's in grams. Because the US decides, you know, to use the imperial system. So right now, if you initially designed a system in, you know, metric or not metric, in the imperial system to only measure pallets, those people can't do their jobs and they're angry and they're yelling at you. And the assumption was there was this isn't going to scale outside of the US which was a very false assumption. And the people that were on the project that knew that had already left, right, the gathered requirements, they were gone. They didn't catch that assumption. And so the whole thing turned into a huge like cluster, if you can imagine, on that particular project. I won't share more than that, but it's more of an illustrator. I don't think it was exactly how it went down for full disclosure, but you know, how the assumptions that we make when we design a business, when we design a process, when we design code, is super important. So. But when we have these three questions in mind, and the sooner we can ask ourselves these questions and keep them on the top of our mind, the better off we're going to be not having extra work things that need to get added or modified as we're doing, because sometimes that's when a lot of problems come up where you overlook a certain thing or you don't take account a certain path of how things go like on an invoice if somebody sends it back to you or something. Right. So that's why the model is think bigger than the problem and think at scale. So that's it for today. Hey Dave, I see you. Hope you're doing good buddy. And next I'll see you guys tomorrow. If you need help with these questions with a process or business process or code that you're working on, make sure you go to shabbat.com coaching to sign up for a free one hour strategy session because a lot of the discussion of high performance coaching is challenging your assumptions, challenging how things work, how you're thinking through it. So take me up on that. It's a free one hour strategy session as long as I have them open. So hit the well, you're probably watching this on Facebook. Go to shotwater.com coaching fill out the application. You'll get figured out. So that said guys, I'll see you tomorrow.










