How to Upgrade Your Scaling SMBs Operating System Without Losing Agility

Help me think through how this episode applies to my situation. Start by asking what I am trying to change. Separate the episode's claims from your suggestions, and say when the notes do not support a claim. Use the transcript to find passages, then check the audio before quoting. Transcript: https://yuvalyeret.com/podcast/episodes/how-to-upgrade-your-scaling-smbs-operating-system-without-losing-agility/transcript.md ## Published episode notes At some point on the growth journey, most leaders reach a point at which they upgrade their organization’s operating system. (even if they don’t explicitly call it that) Way too often, this upgrade doesn’t result in immediate acceleration and traction. In many cases, it feels like the organization is working FOR the new structures and ways of working, rather than the other way around. The processes often seem too rigid and theatrical, rather than outcome-oriented. In this crossover episode with the Scrum.org Community Podcast, Yuval Yeret joins Scrum.org CEO Dave West to unpack why adding these operating systems often slows down most companies instead of making them faster: * The Founder’s Trap: Why the skills that get you to 30 people (and product-market fit) are the wrong skills to get you to 100. * Functional Fiefdoms: How organizing by “departments” (Sales, Marketing, Product) optimizes for silos and guarantees systemic slowdowns. * The “Responsible Adult” Problem: When new leaders, hired to bring order, inadvertently introduce bureaucracy that stifles the system. * Scaling Framework “Theater”: Why so many implementations of EOS, Scaling Up, and OKRs become activity checklists, and how you’re likely serving the framework instead of it serving you. * The Pragmatic Fix: How to break the bottleneck by organizing cross-functional teams around outcomes (like “pipeline health”) instead of org charts. 00:00 Introduction: The Paradox of Growth00:37 Scaling Challenges in Startups02:44 The Role of Responsible Adults in Scaling03:21 Why Scaling Slows Down Organizations12:18 Cross-Functional Teams and Market Segments20:29 Operating Systems for Scaling36:19 Final Thoughts and Reflections Interested in a deeper dive? Explore the role of operating systems and frameworks in regaining organizational traction - https://yuvalyeret.com/resources/mastering-organizational-traction-trail-map/ This podcast episode was recorded and published originally on the Scrum.org Community podcast: https://www.scrum.org/resources/scaling-smbs-without-losing-agility To hear more, visit yuvalyeret.substack.com Upgrade Your SMB's Operating System, Keep Agility – https://yuvalyeret.com/blog/how-to-upgrade-your-scaling-smbs-operating-system-without-losing-agility ## Transcript This transcript was edited from automatic speech recognition for readability. Speaker turns may be wrong or absent, and it may contain recognition errors. Check the audio before quoting or attributing a passage. Episode: https://yuvalyeret.com/scaling-ai-podcast/how-to-upgrade-your-scaling-smbs-operating-system-without-losing-agility/ ## The friction around operating system Shouldn't growth feel like acceleration? For most companies I meet, it actually feels like waiting for a month. You added people, more layers and responsible adults, but instead of getting faster, you get slower and you lose traction. I was discussing this exact problem with Dave West on this Gramdator podcast. It's part of our series, Hello and welcome to the Scrum.org community podcast. I'm your host Dave West CEO here at Scrum.org. Honestly, I have quite interesting experience around scaling in a previous life. So prior to Scrum.org, I was the chief product officer at a company called Tasktop that has been subsequently bought by Clownview, some of you may know, Mick Kirsten, famous for his project to product. He was the CEO and founder of Tostop and I came on when we were, I don't know, less than 10 or maybe around 10 people. It was a heady startup days, really interesting days. Now, we were fortunate enough to secure BC funding from actually Austin Ventures in Yaletown, which we grew, right? We grew to, ultimately, over 100 people doing some really interesting stuff. And I remember quite vividly the challenges as we scaled. We had challenges because of how the whole new set of stakeholders, the VCs in particular, we had challenges because suddenly we had sales marketing operations. Previously, my engineering team had done all support. Now, suddenly we're like, well, they can't do that and build product and support marketing. we need product marketing, which was actually everything I was doing that for a hash. You know, we had a really interesting set of problems, not just about product development. I mean, it was a part, but across the whole business. And, you know, it was because of new stakeholders, it was because of just the sheer volume of stuff that was starting to happen. The more people you brought on, particularly in sales and marketing, the more stuff those people want to do. And that's why they've been brought on, so that's obvious. And also the people we brought on all had their own experiences and their own ideas of what an operating model, what a process, what a system, what an organization should do and how it should work and the like. And some of these people had worked for very large organizations and that was awesome because they had great experiences, but really challenging. So very lucky to have our PST, your value at PST, safe fellow and camban leader, but actually I'm really interested in all of those things obviously, you've been doing a lot of research and spending a lot of time thinking about this problem and talking to organizations that are trying to scale up. That's your area of interest as it were. So welcome to the podcast first, Yaval. Nick, it's good to be here again. So Yaval, why? It's simplest question out of the book. Why are you slower and everything's more complicated when you scale. What happens? We were perfect and then we got money and we got a great coffee machine and it became harder. What is your experience from this? What have you seen? A couple of things that are repeating patterns. One is that simply the fact that you're an entrepreneur, you're an expert in your field, you can organize a team around you and successfully get to product market fit or service market fit. Doesn't necessarily mean that you have what it takes to organize the larger team when it's actually, even if you go back to to image or other books in this space, you need a different set of skills for organizing 30 people that work towards something than 10 people or yourself. So there's this pattern that a successful entrepreneur, a successful founder, gets a company to product market gets it towards success, breaks through something, and then hits the limits of their management and leadership capabilities. And then it's different things happening. One is they bring the responsible adults. That's one common pattern that we see. The responsible adults typically come from much larger organization, and they bring processes that might not be the right fit for this stage, a lot of bureaucracy, a lot of process, maybe different process than the processes of their peers that had other functions. And even if none of that happens, the one thing you start to have is fiftans. You start to build teams around functions, around departments, you divide and conquer, Which on the surface, especially if you use the industrial lines that make sense, if you couldn't break the company down into its separate pieces and you know, say this is the group that will deal with sales. They're responsible for selling. This is the group that is responsible for marketing. This is the group that is responsible for building the product. This is the group that is responsible for customer success, customer support. This is the group that is responsible for HR, and each one of them runs their own things. Things will work. But the problem is that an organization is a system. And because it's a system, those different parts need each other. And if your management system ignores that, things start to slow down. And because the parts need each other, Either you ignore that and make progress in silos and that progress doesn't really achieve the outcomes that you need, doesn't really maintain traction. Or you are cognizant of the fact that you are aware of the fact that you need to cut across the functions, but your operating system requires those leaders to talk across the functions and this creates a lot of coordination over it. That's the pattern that we see in the business. Now, how did I get to see this pattern? It's typically when I'm brought in to work with the product side of an organization, with the art and art and engineering products, you know, even in the broader perspective, what do we mean by product, maybe the commercial aspects of the product? And we think some of these problems, but we don't see outcomes, or we don't see enough outcomes. Because the product on its own cannot really go to market, cannot really create a few customers, you need to change how you market the product, how you sell the product. And that's typically when you start to encounter the interface between how a product organization works and how the rest of the organization works, whether it's any sort of management system or that's where I started to encounter things like the OAS in the Forex and all the R's that are different ways that companies try to tackle the scaling charge. Before we talk about those systems, because we tried, we had Mick Kärsten, who's probably the smartest guy I've ever met in my life, actually or one of them. And he also massive work ethic was always working. And he was very into system thinking and trying different approaches. We used the blank startup owners manual we used. We explored EOS didn't find it was found it was a little not product to know actually for us. I asked D4X, obviously, you know, we tried many things, but before we lean into this, I guess the fundamental problem that you highlighted is that as you grow, I grew, I was responsible for engineering, architecture, product marketing, really, because nobody else wanted it, which which was great. We grew marketing, you know, invested in better website, all that stuff. We grew sales. And so you write, we grew these different fiefdoms and we brought them together in an executive leadership sense. And we had clear goals that the ELT worked on. But the fiefdoms did grow and we had to keep them focused. We didn't want marketing. We wanted them to generate leads, right? That was everything else that got in the way that was sort of irrelevant. We wanted engineering to deliver on their roadmap and deal with any bugs that have been discovered rich the world for you. And we wanted sales to close business, right? So we kept them very focused on those things and that caused a lot of friction because to close business you need You need a better leads, you need better product marketing to get better product marketing. You need a better product. It was all this complicated flow of information as we grew. We found it hard. How does, as organizations are sitting there, maybe they've got to the 50 person size? Is stovepipes wrong? you kind of have to focus and, you know, we weren't, we hadn't got ultra-mat agility. When we were 10 people, we did. We could do anything. An engineer could be helping me write a marketing presentation, a salesperson would test the product, because me, I don't know, I also test it. ## What is really happening in the system Can you just spend an hour just making sure that nothing looks silly? We were incredibly flexible, but as we grew, that flexibility reduced and disappeared. I was always curious, could you keep that flexibility and organization? Was it just chaos then? Do you need these departmental structures? I don't know about departmental structures. But I think we need to acknowledge that at some point, the team becomes too big to be one team. Yeah, that's a fact, right? For human beings. It becomes more interesting when we start to talk about these new models of one person, unicorn and all the 10 person company that can be the 50 person company, maybe we'll get there. I think even when you scale through AI agents, there's still more moving parts, there's still complexity, there are still things that start to break down. But even if we could get the side, there's a limit to the side of an effective team or the conductive overload that they can take on what they can be accountable for. It's just a matter of trade-offs. Do you decide to aggregate all of your sales experts, all of your marketing experts according to their expertise or according to the mission, the outcome that they're focused on or the business process that they're focused on. So let me give you an example. A computer associates, we worked on how do we make marketing more agile? How do we deliver more competitive campaigns, more effective, more competitive, contains much faster. A key design decision that we made is we decided to choose a different trade-off in the structure of the work teams, not the departments in the organization, but the work piece. And we took product marketing, digital marketing, inside sales, the leader of inside sales, field marketing people that go to conferences and you think the booths and design, you know, the appearance in those conferences. In all of these people were together on the team, even though they were part of the different departments, and they were able to own a healthy pipeline much better than, you know, they were in different functions. And they didn't need to go up all the way to their senior VPs. which of them reported to a different senior VP in the corporate marketing organization, which was like 300 people at the time. This is one of the places where I've seen that what we've been reaching, sorry, we were preachers. It certainly feels like that. Some days we've been preaching in the product development work or other complex problems as well works for a business problem of how do you get key and more effective marketing and sales campaign motion that builds the pipeline and enables you to close the pipeline and deliver marketing and sales contribution much more smoothly for or a certain product. So the idea that as you scale, instead of really doubling down on this industrial structure around specializations of labor, instead think a little bit about market segments, outcomes, customers, jobs to be done, whatever tool you're using to think about your customers and the problems. And then ultimately build cross-functional teams that can align to that, that have almost all the skills. So actually, we say has all the skills to deliver value, but the reality is you always have to beg, borrow and steal something. But the has almost all the skills that started to deliver value. And then, you know, give them clear goals, you know, in the case of your experience in marketing at TA, it was, you know, very clear was to build an active and viable pipeline, the high quality pipeline defining what high quality is, you know, you can do that and then continuously build a motion that inspects and adapts that based on actual experience in the field. So actually we never really did that. So at a tough start, that not because we didn't think about it, set, but because it was always the choices, you have to make choices. And we were scared to make those choices. Instead, the customer and the segments that we were so we were very much focused on. And predominantly, we had two models of business, maybe a third that never really happened. One was the reseller through partnerships with HP, IBM, etc. And then we had the big enterprise sales, traditional enterprise sales. There was a third motion that we never really delivered on, which was the developer centric purchase model, which we never managed. But what we could have done is we could have built teams around those two ones that were in present, the OEM model and the thing. And actually, that would have been kind of interesting, actually. I've done that. Not a company you would call in SMB, you might have their dishwasher in your kitchen. Actually, mine's broken at the moment, so they'd be really handy if they're kids already for that or their generator might be powering, you know, low-fart neighborhoods. So big, big, big industrial company. There's sales and professional services was organized around channels along the lines you're talking about. And what we've done is we've organized their work on sales enablement in services, enablement, and marketing around channels, direct e-commerce, e-commerce, obviously it applies to some of their hub products, not all of them. And it was uncomfortable to them that their people are caught into, are organized into different groups. It's a trade off, it's impossible, and it goes against the fiefdom approach, which is why it's so hard for people to do that, and to teach us to go in that direction. And which is why, by the way, we see that when people, even when people take operating systems, they implement these operating systems in a very shallow manner, which we've seen in Scrum as well, right? They say, you know, now we have rocks, now we have level 10 meetings and processes, you know, accountability charts, right people in the right seats. But when you look at what is actually happening, if they took the easy path out, they still maintain teams or departments that are functional, it's still very hard to get things done across the groups. There's maybe a better framework for how to deal with issues that arise out of those different, but a lot of issues arise out between the different groups. And leadership becomes a bottleneck. And when leadership becomes a bottleneck, that's when you know that you don't really have a scalable operating system. Yeah, we wait to absolutely have is you go into founder B. If you recall, yeah, uh, the program and, um, you know, Airbnb for how to deal with the fact that, you know, things don't scale. That's one option. I don't think that's the right option. Many founders as I talked to don't want to go into founder based mode. The other option is to continue looking for an operating system that makes sense. And I think based on what we've seen work in the product world, there are some interesting ideas and I've seen them deliver some value to these sort of fun. So let's talk about those. It's funny you should say that the founder based mode, That is definitely what we did. Luckily, we had a founder, Mick Kessden, who had the ability to... I've never seen somebody be able to take more bandwidth. You could put him on one of those fiber optics under the Atlantic, and he'd be fine with that. He was incredible there. But at a certain point, it did start to break. there was a lot of tension in the ELT happened at the wrong level at times and our ability to execute was with blow down because of that. It was part of the journey, fresh fresh fresh fresh that starts up there is that friction and that pain and those very emotional moments which was fun. All right, so yeah, we didn't do this but tell me a little bit about the operating systems like EOS, scaling up, D4X, et cetera. How do they look at this problem? These operating systems make sure you have a vision, a longer term vision, strategy goal, if you want to use the EBM language makes total sense. They all make sure there's clear accountability, who's responsible for what to try to break down the slow-dove, the all responsible, all accountable founder. EOS even has this dynamic of introducing the operator role essentially. The integrator talks about breaking out the founder role into visionary. dynamics between the product owner and Strahmaster and the visionary and integrator that we can maybe get into. Then there's a whole process of goals. Quarterly goals, whether you want to call them rocks, goals, vehicles, and you know, you need to start with what you want to focus on and don't let the day Today, they made them take over your wall. US uses that approach as well. They all have scorecards to make sure that you're focused on the right thing. So it's all good stuff. They have meetings, a rhythm of meetings to make sure you track towards these goals. US called those L10 meetings, level 10 meetings. Because it's supposed to be a meeting where everybody feels it was great meaning that it will help you get traction. And it has a good approach for how to run such a meeting, focusing on immediate issues and how we're doing towards our goals and looking at our scorecards. It's all good stuff. Some of these approaches are more prescriptive than others. US is the winner of the perscripting award. ## The practical shift D4X and OKRs are less prescriptive, but I really like some of the thoughts in D4X on input metrics, on leading indicators. It connects to some of the problems I see in the US and how people nears it, which is a lot of the goals are activity goals, maybe output goals, which creates some issues, which creates a problem when you're developing your organization, and there's complexity and you want to channel it in flexibility if you're fixed the activity that lets go back to CA. If your goal is a healthy pipeline, you want to have flexibility, what do you try to do to the again, the healthy pipeline? You don't want to say a lot of advantage at the beginning of the quarter, These are all the activities we will do. These are all the conferences we will go to. These are the campaign we will launch. You don't know what will work. There are some things that will work great and you will want to double-dop. There are some things that will fall flat. So outcome of a healthy cut plan is much more effective than the goal of what campaign we will run. So I really like the frameworks that emphasize that. scaling up is a more open approach. GOS is actually a sub-up of an implementation, a simplified implementation of scaling up. One of the things that didn't make it over is that processing ought to be in charge, which is interesting because the process is not a department. And there is interesting potential to think about products, value streams, value streams, people that own the value stream a healthy pipeline rather than whole sales activity. So there's something powerful there. I don't see many people really implement it that way. Because again, it's tough. So it's very tempting to say the process is to market, the process is to sell, the process is to serve a customer rather than the real end to end, then to end key business process. Yeah, product would fit nicely in that model and having product owners is sort of ultimate position with respect to that kind of value stream because hopefully the product owner owns the solution in the context of a problem, right? And that has clear stakeholders, has a bound value et cetera, which would work. But let's be honest, I've also seen organizations that we really like Scrum. We've seen it work in product development. Let's use Scrum throughout the organization. But then the way to implement Scrum throughout the organization is very similar to the theater that you see in these other networks. You see, marketing is a product, or sales is a product, or HR is a product. And sometimes that makes sense. But a lot of time it doesn't. A lot of time it creates product owners that own activities and not really move the needle for the business. Well, I mean, it depends on what the problem you're trying to solve. If you're trying to build very efficient subsystems inside an organization and the level of change is very slow, then maybe it does work. However, what you're describing and when scaling up is usually the opportunity is fluid. You don't know how to build the right pipeline. You don't know what features are going to be delivered. You don't know what support load is going to look like. You don't know as you scale, we had no idea at a tasktop. Let's be honest. We had a pretty chart that we put up every board meeting, but it was ultimately a lot of unknowns, primarily because we didn't know what would attract customers really, and what types of customers. We had to reformulate who the organization was in multiple times. Who do we talk to in an in a customer profile. What is the products that they're interested in? What is the story we need to sell them? And we had to continuously change that over and over again because what we found was early adopting customers were very different, you know, cross-classic crossing the chasm, right? And we identified bowling pins, we did Jeff Moore's model as well, and we worked on that. What we should have done is aligned across functional teams to the bowling pins more clearly. We didn't do that. And that's what quotes the tension. I think there's an interesting pattern here. I'm almost willing to bet, based on what I've seen, repeatedly, that a crossing the cousin party is a typical pattern of a team that you might want to create that crosses the different sections. You know, across the museum is not one business process. No, no, no, really. It's one big business challenge that requires this collaboration. It's not just the product challenge, not just the sale of the marketing challenge. It's an integrative challenge. Well, Rossing because facing the bowling alley, These are challenges that are very complex to tackle. And I would argue even in the age of the eye, there is so much uncertainty that you really need to be agile in evidence-based and outcome-oriented, and how you tackle them. And that's a very different operating system than running the day-to-day in a stable fashion. Companies now have revenue options. That's marketing operations and sales operations, revenue operations, which is one step towards this vision of looking across the different functions. The fact that more and more companies have achieved revenue officer rather than different marketing and sales organizations. It's an attempt at this. But then their question is, okay, how do you get it to cover the customer experience organization and the product organization? I'm wondering whether the future of ops, let's say, is not that we have engineering ops and product ops and rev ops, customer experience ops, which is pretty rare as far as I know. looking at operations operating model and data and enablement across the organization. And it's pretty rare to see that in larger organizations, in small organizations, it's pretty rare to see any of that. It's pretty rare to see the organization having any sort of time to enable the organization. The main problem we see in small organizations, is they're just busy running the business. They barely have the time to step away from it, and think about how do we work on the business. And that's why the way it got something good that these operating systems provide. They provide the mental model that enables you and the structure that this is, that enables you to dedicate some time to developing your business. I really appreciate all of the work that people like Geno Week to help entrepreneurs take one level forward. I think that if you meet these founders, these operators that are trying to scale up their organizations, not necessarily by a number of people, but how much are these going on? How much revenue are we bringing? How many customers can we support? And they're already dedicating time to developing their organization. The models that we provide where that work to develop the organization is organized around outcomes. And it's managed day to day by looking at bleeding indicators and making some assumptions and doing something and sensing and responding, inspecting and adopting towards that direction by bringing together the right mix of people that can be empowered to own that change to the company. I think that combination, I've seen it work as a winning formula. So I believe that's the next step of what you do once you decide to bring in a scaled up operating system. Yeah, that makes a lot. Yeah, it would have made our lives so much easier for it. Don't get me wrong, we did spend a lot of time retrospecting. We were, you know, Gen Shwaiba was the, the coach for the engineering organization. So he insisted on that on a level. But interestingly, he wasn't particularly interested outside of product delivery. like he wasn't, you know, he's like, well, that's that's cool. But you know, but yeah, which was, but having that space and a broader sense would have perhaps been very, very sensible and been able to apply a more outcome centric goal oriented approach, you know, we, we, yeah, but it did require, it would have required a significant amount more discipline than perhaps and choices than perhaps we were willing to make. Because you, as soon as you have a goal, well, one, you have to actually define it. And then two, you have to measure progress against it. ## What leaders should pay attention to And that's, that's always a risk for the last period of organization. And it also forces you to say no to some goals. Yeah, we did. The things I really like to do is to talk to people that are using us. Would there go a lollipop on them? Just think all of your works, Rox, let's see them on the common. How many do you have in life? What is your process for deciding the tour committee to another goal? And just that small act of all of the goals that are in the business and how long does it take us to actually get a goal from commitment or even thinking through it to the outcome that we wanted to achieve making sure that when we achieve a goal, it actually achieved an outcome and you learn from it, even that discipline for the leadership team, for the father and their team to look at, is a pretty interesting exercise. Choice is never easy. And I mean, even if you say this is a small, we're only focused for the next month, the next two weeks, the next week. You still have to make a choice and as an SMB, as a small medium-sized business, which I think those choices have a direct impact on payroll. Those choices have a direct impact. Even when you've got the luxury of VC money, which gives you a little bit more freedom, the choices are really scary. you know, should we have doubled down on our OEM business? Because if we'd have done that, we'd have probably been acquired before, actually, but for a smaller valuation, you know, yeah, those choices are dangerous. And at the early stages, it was choices about payroll, about burn rate, basically, about when the next round would be. And yeah, it's hard. Yeah, hard, not easy. Anyway, we could talk for days about this year, and we have probably, if you added up all the time. But we unfortunately, you know, our listeners have planes to catch, have work to do, have babies to put to bed, have shopping to deliver. Maybe they have some product development to do as well, or some business to build. So I guess the what would be the last, you know, we started off, why are you slower when you scale? And we went through, you know, talking about EOS, talking about the challenges of scaling, talking about some of the things that we've seen that work around scaling. But what would you leave already and swift? What would be the, you know, the one thing that if you listen, if you think of anything during this, this 45 minutes, 50 minute podcast, what would be the last thing that they need to take away. I guess an invitation for reflection is probably what I invite people to do to reflect upon. Is our operating system, is the way we're working working for us? Are we working for it? Is it creating, is your phone feel like it's enabling you to live the life that you want while building the business? the business of your dreams. And if you have doubts, if you feel like it's, the way we work is currently a glass ceiling, makes you work too hard right now. If you want to continue to grow the business or even keep it running, then maybe start looking at some of these ideas. I wrote an email course called Mastering's Organizational that goes through some of these stories, some of what typically happens to organizations as they scale what Operating systems like the ones we talked about provide Where do they fall short? What you might want to start adding to them? You know make sure that their outcome we're into to make sure it's focusing slow your goals Maybe that's a little bit interesting to people that stayed with us. It's hey, I will obviously make sure we put that link. We probably should answer that you about. I guess just to lean in onto that what I would recommend is the mindful about the operating system. The last thing we want is for people to hear we need an operating system. install an operating system that ends up like a theater. What the intent of these systems? Why do they work? When do they work? When do they not work? Think about the principles, the principles behind this stuff, rather than just the mechanics about the surface. It's not about the mechanics. I mean, they're obviously important, but it's the intent in the same way is scrum, we always focus on the mechanics often. And that is not important. What's important is empiricism, self-organization, empowered teams, continuous reflection and improvement. But those are the principles that are fundamental. And try to understand when you look at EOS, when you look at the other scaling up, D4X, or any of those OKRs, and the like, look at that from that perspective. All of these systems have a point of view, some of them in certain areas, some of them in others, and you have to build your own. It's gonna be unique to your situation, unfortunately. I wish it wasn't, but the combination of people, customers, stakeholders, AI agents, and all that's very complicated. You're well, thank you. It certainly took me back this, this journey. It made me think of some, some happy times and some not so happy times. I, I'm not going to look out the, the, the, the view that we had of our operating system. I think that's got it somewhere. I'll send it over if I find it, your value. It'll give you a, give you a laugh, which is always good. And thank you, Nissa, that's for bearing with us. I know this is a little bit of long and we've gone over some, had it. Bawnee, interesting topics. But we really appreciate you spending the time today. As we talked over, really, well, how is it slower when you scale? What do you mean by scaling, particularly for businesses, for small and medium sized businesses or parts of bigger businesses? And then we talked briefly about EOS scaling up on Audiex, you've all done some work on those areas. We'll provide some links on the connected to this podcast. And hopefully you, at least you gave you some empathy to the pains and the challenges that you're going through. Just remember that you are actually in charge of your destiny. And it does mean you're gonna have to make some choices, but ultimately you can make those choices. Just remember short bets, not long one. So thank you for spending the time and listening to today's Scrum to Audubnity podcast talking today about operating systems and the challenges of scaling up, particularly for businesses. ## Source boundary These are the published show notes from the podcast feed. They are a starting point for discussion, not a verbatim record of the conversation. The transcript is machine-generated and may contain errors or unlabeled speakers. Check the audio before quoting anyone.