Scaling SMBs Without Losing Agility

Building on last week’s episode on AI and Operating Systems in SMBs, Dave West and PST Yuval Yeret dive into the challenges of scaling small and medium-sized businesses.

Dave shares lessons from growing an organization from a small team to over 100 people—navigating silos, new stakeholders, and keeping teams outcome-focused. Yuval highlights common scaling pitfalls and explores frameworks like EOS, Scaling Up, and D4X, emphasizing vision, strategic goals, and evidence-based management.

Learn how to maintain agility at scale, build cross-functional teams, and create an operating system that drives sustainable growth

Transcript

Speaker 1  0:00  
Welcome to the scrum.org community Podcast, the podcast from the home of Scrum. In this podcast, agile experts, including professional scrum trainers and other industry thought leaders, share their stories and experiences. We also explore hot topics in our space with thought provoking, challenging, energetic discussions. We hope you enjoy this episode.

Dave West  0:25  
Hello and welcome to the scrum.org community podcast. I'm your host, Dave West, CEO here@scrum.org in today's podcast, we're talking about small and medium sized businesses, and in particular, we're talking about the area of scaling up, scaling, and it's interesting because there's a connection to some of the stuff we see in Scrum and evidence based management. 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 Task top that has been subsequently bought by plan view. Some of you may know Mick Kirsten, famous for his book project to product. He was the CEO and founder of task top and I came on when we were I don't know less than 10, or maybe around 10 people. It was heady. Startup days, really interesting days. Now, we were fortunate enough to secure VC 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. You know, we had challenges because a hot a whole new set of stakeholders, the VCs in particular, we had challenges because suddenly we had sales, marketing, operations. You know, 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, oh, which was actually everything I was doing that prior, you know, we had a really interesting set of problems, not just around product development. I mean, it was a part, but across the whole, 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 a what an organization should do, and how it should work, and and the like. And some of these people had worked for very large organizations, and that was that was awesome, because they had great experiences, but really challenging. So very lucky to have our PST, Yuval, UET, PST safe fellow and Kanban leader. But actually, I'm really interested in all of those things, obviously, Yuval, but really you've been doing a lot of research and a lot of 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. So welcome to the podcast. First, Yuval, thank you. Dave, good to be here again. So, Yuval, why? Simplest question out of the box, 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 what's your experience from this? What have you seen?

Yuval Yeret  3:57  
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 a larger team when it's actually successful the even if you go back to E Myth or other books in this space, you Need a different set of skills for organizing 30 people that work towards something, then 10 people or yourself. So there's this pattern that a successful entrepreneur, a successful founder, gets a company to product, market fit, gets it towards success, breaks through something. Ng and then hits the limits of their management leadership capabilities. And then, you know, different things happen. One is they bring the responsible adults. That's one common pattern that we see. The responsible adults typically come from much larger organizations, 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 fiefdoms. You start to build teams around functions, around departments, you divide and conquer, which, on the surface, especially if you use the industrial mindset, makes sense if you could 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 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, 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 overhead. 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 the organization, with r&d engineering products. You know, even in the broader, broader perspective, of what do we mean by product, maybe the commercial aspects of a product, and we fix 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 happy 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 you encounter, that's where I started to encounter things like EOS and the 4x and OKRs. That are different ways that companies try to tackle this scaling challenge,

Dave West  8:37  
before we talk about those systems. Because, you know, we we tried. We had Mick Kirsten, 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 use Steve Blank's startup owners manual we used, we explored, EOS. Didn't find it was found. It was a little not product enough, actually, for us, D for X, 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, like I grew, I was responsible for engineering, architecture, Product Marketing, really, because, you know, nobody else wanted it, which was great. We grew marketing, you know, you know, invested in better website, all that stuff. We grew sales, and so you're right, 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. Want marketing. We wanted them to generate leads, right? That was, that was everything else that got in the way of that was it sort of irrelevant. We wanted engineering to deliver on their roadmap and deal with any bugs that have been discovered, which there were a few, and we wanted, 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 better leads. To get better leads, you need better product marketing. To get better product marketing, you need a better product you need it was all this complicated flow of information. The as we grew, we found it hard. So

Yuval Yeret  10:41  
how, how does you know, as

Dave West  10:45  
organizations are sitting there, maybe they've got to the sort of like 50 person sort of size is stovepipes wrong? I mean, you kind of have to focus. And I you know, we weren't, we hadn't got ultimate 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 I also test it. 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 in organization, or was it just chaos? Then do you still do you need these departmental structures?

Yuval Yeret  11:35  
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 the one person unicorn, and you know, the 10 person company that can beat a 50 person company, maybe we'll get there. I think even when you scale through AI agents, there's still more moving parts. There are still complexity, there are still things that start to break down. But even if we put that aside, there's a limit to the side of an to the size of an effective team of the connective overlord 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, interesting. So let me give you an example. It a compute computer associates when we worked on, how do we make marketing more agile? How do we deliver more competitive campaigns, more effective, more competitive campaigns, 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 teams. And we took product marketing, digital marketing inside sales, the leader of inside sales, field marketing people that go to conferences and sit in the booths and design, you know, the appearance in those conferences, and all of these people were together on a team, even though they were part of different departments, and they were able to own a healthy pipeline much better than you know, if they were in different functions and they didn't need to go up all the way to their senior VPs, each 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 preaching and sorry, we've were preachers, right? It certainly feels like that. Some days we've been preaching in the product development world works for other complex problems as well. Works for a business problem of, how do you get to a more effective marketing and sales campaign motion that fills the pipeline? Line and enables you to close the pipeline and deliver marketing and sales contribution much more smoothly for a certain product. So the idea that

Dave West  15:16  
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, whatever tool you're using to think about your customers and the problems, and then ultimately, by build cross functional teams that can align to that that have almost all the skills. So because, 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, has almost all the skills necessary 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 a active and viable pipeline, that 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, so actually, we, we, we never really did that at task stop that, not because we didn't think about it, but because it was always the choices you have to make choices, and we were scared to make those choices. Instead, we the customer. And the segments that we were, we were so we were very much focused on and predominantly we had two. Three were two models of business, maybe a third that never really happened. One was the OM, 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 the what we could have done is we could have built teams around those, those two ones that were in present, the OEM model in the and the thing, and, and, and, actually, that would have been kind of interesting.

Yuval Yeret  17:36  
Actually, I've done, yeah, I've done that, not a company you would call an SMB. You might have their dishwasher in your kitchen, okay?

Dave West  17:50  
Or, actually, mine's broken at the moment, so they'd be really handy

Speaker 2  17:54  
for that. Or their generator might be powering, you know, low, far neighborhoods. So big, big, big industrial company, their 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 and services enablement and marketing around channels, direct e commerce, e commerce, you know, obviously applies to some of their products, not all of them, and it was uncomfortable, you know to them that their people are cut into, are organized into different groups. It's, 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 choose 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 we have process, you know, accountability charts and right people in the right seats. But when you look at what is actually happening is 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 groups. But a lot of issues arise out, you know, 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 two options you have is you go into founder beast mode, if you recall, yeah, the Paul Graham and, you know, Airbnb, Brian, it's approach 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 I talk 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, you know, deliver some value to these sort of founders.

Dave West  20:54  
So let's talk about those. I It's funny. You should say that the founder beast mode that that is definitely what we did, luckily, we had a founder, Mick Kirsten, who had the the ability to, I've never seen somebody be able to take more bandwidth, you know, like he, you could have, you could put him on one of those fiber optics under the Atlantic, and he'd be fine with that. You know, he was, he was incredible there. But at a certain point, I he it did start to break. There was a lot of tension in the ELT at times, because decision making ultimately happened at the wrong level at times, and and our ability to execute was was slowed down because of that. It was, yeah, it was, it's part of the journey for a startup. There is that, that friction and that pain and those very emotional moments, which was fun, right? So, yeah, we didn't do this, but tell us. Tell me a little bit about the operating systems like Eos, scaling up, deforex, etc. What? How do they how do they look at this problem?

Yuval Yeret  22:05  
These operating systems make sure you have a vision, a longer term vision, strategic 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 this mode of the all responsible, all accountable. Founder EOS even has this dynamic of introducing the operator role, essentially the integrator he talks about the breaking out the founder role into the visionary and introducing the integrator can interesting dynamics between the product owner and Scrum Master 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, B, hags, the discipline for execution, D for X explicitly connects to Covey's metaphor of the rocks pebbles, and you know you need to start with what you want to focus on, and don't let the day to day mayhem take over your world. EOS 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, the rhythm of meetings to, you know, make sure you track towards these goals. EOS calls those l 10 meetings, level 10 meetings. Why? Because it's supposed to be a meeting where everybody feels it was a great meeting that may, you know, help you get traction, and it has a good a good approach for how to run such a meeting, focusing on immediate issues and how are we doing towards our goals and looking at our scorecard. So it's all good stuff. Some of these approaches are more prescriptive than others. EOS is the winner of the prescriptive award, D 4x and OKRs are less prescriptive. But I really like some of the focus in D 4x on input metrics, on leading indicators. It connects to some of the problems I see with EOS and how people use 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 optionality and flexibility. If you're if you fixed the activities that, let's go back to. Ca, if your goal is a healthy pipeline, you want to have flexibility. What do you try to do to maintain a healthy Yeah, you don't 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 campaigns we will launch. You don't know what will work. There are some things that will work great, and you will want to double down. There are some things that will fall flat. So the outcome of a healthy puck climb is much more effective than the goal of what campaigns we will run. So I really like the frameworks that emphasize that scaling up is a more open approach. EOS is actually sub an implementation, a simplified implementation of scaling up. One of the things that didn't make it over is a process accountability chart, which is interesting, because the process is not a department, and there's interesting potential to think about products, value streams, value streams, people that own a value stream, a healthy pipeline, rather than own 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, the end to end, key business process.

Dave West  26:43  
Yeah, product would fit nicely in that model. And having product owners is is a 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 with that has clear stakeholders, has a bound value, etc, which would work.

Yuval Yeret  27:09  
But let's be let's be honest. I've also seen organizations that say we really like Scrum. We've seen it work in product development. Let's use Scrum throughout the organization, but then the way they implement scrum throughout the organization is very similar to the theater that you see in these other frameworks. You see marketing as a product, or sales as a product, or HR as 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 cannot really move the needle for the business. Well, I mean,

Dave West  27:50  
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. You don't know what, what support load is going to look like. You don't know as you scale. We had no idea at task top, let's be honest, we we had a pretty chart that we put up every, every, every board meeting, but it was ultimately a lot of unknowns, primarily because we didn't know what would what would attract customers, really, and what types of customers. And, you know, we had to reformulate who the organization was multiple times. Who do we talk to in an organ, in a customer profile, what is, 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. We didn't do that, and that's what caught the attention.

Yuval Yeret  29:28  
I think there's an interesting pattern here. I I'm almost willing to bet, based on what I've seen repeatedly, that a Crossing the Chasm party is a is a typical pattern of a team that you might want to create that crosses the different functions. You know, crossing the chasm is not one business process, no, no, no, really one business. Big business challenge that requires this collaboration. It's not just a product challenge, it's not just a sales or marketing challenge, it's an integrative challenge, but Rossi because facing the bowling alley, these are challenges that are very complex to tackle, and I would argue, even in the age of AI, there's so much uncertainty that you really need to be agile and evidence based and outcome oriented in 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 operations, not marketing operations and sales operations. They have revenue operations, which is one step towards this vision of looking across the different functions, the fact that more and more companies have a chief revenue officer, rather than, you know, different marketing and sales organizations, that'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? And I'm wondering whether the future of ops, let's say, is not that we have engineering ops and product ops and rev ops and customer experience ops, which is pretty rare, as far as I know. But looking at operations, operating models and data and enablement across the organization. And it's pretty rare to see that in larger organizations, in smaller organizations, it's pretty rare to see any of that. It's pretty rare to see the organization have 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, by the way, a good, something good that these operating systems provide. They provide the mental model that enables you in the structure, the discipline, that enables you to dedicate some time to developing your business. I really appreciate all of the work that people like Gina wieckman and EOS and Vern Harnish with scaling up they're doing to help entrepreneurs take one level forward. I think that if you, if you meet these founders, these operators that are trying to scale up their organizations, not necessarily by number of people, but how much activity is 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, you know, day to day, by looking at leading indicators and making some assumptions and doing something and sensing and responding, inspecting and adapting 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.

Dave West  34:00  
Yeah, that makes a lot. Yeah, it would have made our lives so much easier if we'd have had the time. And the don't get me wrong, we did spend a lot of time retrospecting We, you know, Ken Schwaber was the coach for the engineering organization, so he insisted on a on a level, but interestingly, he wasn't particularly interested outside of product delivery. He wasn't that, you know, he's like, Well, that's, that's cool, but, you know, and, but yeah, which was, but having that space in 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 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, wouldn't you have to? To actually define it. And then two, you have to measure progress against it. And that's that's always a recipe for disaster in organizations.

Yuval Yeret  35:09  
And it also forces you to say no to some goals, yeah, which is I really like to do, is to talk to people that are using us and put their goals on a condom board. Just take all of your works rocks. Let's see them on a condom board. How many do you have in flight? What is your process for deciding that you're committing 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, and making sure that when we achieve a goal, it actually achieved an outcome, and we learn from it. Even that discipline for the leadership team, for the founder and their team to look at is is a pretty interesting exercise. Choices are never easy.

Dave West  36:09  
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, even you still have to make a choice. And as an as an SMB, as a small, medium sized business, which I have been, 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 more, smaller valuation, 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, that's hard, not easy. Anyway, we could talk for days about this, Yuval and 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 audience with? 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?

Yuval Yeret  38:03  
I guess an invitation for reflection is probably what I did, 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, if you're a founder or an operator for a small medium business, does it 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 that makes you work too hard. Right now, if you want to continue to grow the business or even keep it, keep it running, then maybe start looking at some of these ideas, I wrote an email course called Mastering organizational traction 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 they're outcome oriented. Make sure you focus on flow of your goals. Maybe that's a that might be interesting to people that stayed with us. Thus far,

Dave West  39:38  
I learned, I will obviously make sure we put that link when we publish. Thanks for that. Yuval, I guess just to lean in onto that, what I would recommend is that be mindful about the operating system.

Yuval Yeret  39:51  
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's the intent of these systems? Why do they work? When do they work? When do they not work? Think about the principles research, the principles behind this stuff, rather than just the mechanics above the surface.

Dave West  40:20  
It's not about the mechanics. I mean that they're obviously important, but it's the intent. In the same way as Scrum, we always focus on the mechanics often, and that is not important. What's important is empiricism, self organization, empowered teams. You know, 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, D, 4x 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 going to be unique to your situation. Unfortunately, I wish it wasn't, but the combination of people, customers, stakeholders, AI, agency, all gets very complicated. Thank you. I've said. 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 view that we had of our operating system, and I think I've 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, listeners for bearing with us. I know this is a little bit of long and we've gone over some kind of thorny, interesting topics, um, but we really appreciate you. You spending the time today as we talked over really, why 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 and then we talked briefly about EOS scaling up for dx. Uval has done some work on those areas. We'll provide some links on the connected to this, to this podcast and and hopefully you, at least we 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 you know you it does mean you're going to have to make some choices, but, but ultimately, you can make those choices. Just remember short bets, not, not, not long ones. So thank you for spending the time and and listening to today's scrum.org community podcast, talking today about operating systems and the challenges of scaling up, particularly for businesses. If you liked what you heard, please subscribe, share with friends, and, of course, come back and listen to some more. I'm lucky enough to have a variety of guests talking about everything in the area, professional Scrum, product thinking and of course, agile and today, operating systems, business operating systems, which was great. Thank you, everybody. Scrum on foreign you.

Transcribed by https://otter.ai