Upgrade Your SMB's Operating System, Keep Agility

Growth is supposed to feel like acceleration. For most companies between 50 and 500 people, it feels like wading through mud. You added people, added layers, and brought in responsible adults, and somehow predictability went down while coordination overhead started eating your best people. That pattern is so consistent that it is worth treating as a design problem rather than a run of bad luck.

I dug into this with Dave West on the Scrum.org community podcast, in a series about how agility helps small and medium businesses handle growth. Dave lived it himself as chief product officer at Tasktop, going from around ten people to over a hundred. We landed on the same conclusion from different directions: scaling does not have to mean slowing down, but it almost always does, because four systemic traps go unaddressed. Each one is a choice the organization made for sensible reasons, and each one has an escape that does not require giving up the agility that got you here.

Updated July 2026: expanded from the original episode summary into a full write-up of the four traps, including the one the earlier version skipped.

The skills that take a company from ten people to thirty are not the skills that take it from thirty to three hundred. Hustle, intuition, and a founder’s direct feel for the product get you to product-market fit. Operating as a system is a different job, and it is genuinely a different skill, not a matter of trying harder. The pattern I see over and over is a successful founder who breaks through to real traction and then runs straight into the limits of their own management and leadership bandwidth.

What happens next usually takes one of two forms. The first is bringing in the responsible adults, typically from much larger organizations, who arrive carrying processes calibrated for a company ten times your size. Each one brings a different playbook from a different past employer, so you inherit bureaucracy without inheriting coherence. The second is founder mode, where the founder leans in harder and tries to hold more of the company in their head. I have watched people with extraordinary bandwidth make that work far longer than it should, and I have watched it break anyway, usually as tension inside the leadership team that surfaces as slow decisions everywhere else. Most founders I talk to do not actually want founder mode. They want an operating system that does not need them in every conversation.

As you add functions, you build fiefdoms. Sales, marketing, product, operations, customer success, each with its own leader, its own scorecard, and its own definition of a good quarter. On the surface this is just division of labor, and if the company could truly be decomposed into independent pieces it would work fine. But an organization is a system, and the parts need each other. Ignore that and each silo makes progress that does not add up to a business outcome. Acknowledge it, and your operating system now requires the function leaders to coordinate across every meaningful decision, which is how leadership becomes the bottleneck.

The escape is to organize the work around outcomes even when the org chart stays functional. At Computer Associates we were trying to make marketing dramatically faster at getting competitive campaigns out. The design decision that mattered was not restructuring departments; it was restructuring the work teams. We put product marketing, digital marketing, inside sales and its leader, field marketing, and design on one team that owned a healthy pipeline end to end. Those people still reported into different senior VPs inside a 300-person corporate marketing organization, but they no longer had to escalate to their VPs to get anything done together. A cross-functional pipeline-health team will outperform separate sales and marketing groups coordinating through meetings, every time. I have since seen the same move work at a large industrial manufacturer that organized sales enablement, services enablement, and marketing around channels rather than functions. It was uncomfortable for people to be split across groups, which is exactly why it is rare and exactly why it works.

This is the trap the original version of this article skipped, and it may be the most consequential one, because it quietly cancels out the benefit of everything else you fix. Most scaling companies adopt quarterly goals, and most of those goals turn out to be activities or outputs wearing goal-shaped clothing. We will run these six campaigns. We will attend these four conferences. We will ship these features. Those are commitments to motion, and once you have written them down, your team is contractually obliged to keep moving even when the evidence says the motion is not working.

Go back to the healthy-pipeline example. If the goal is a healthy pipeline, defined with real numbers about what healthy means, the team has room to find out what actually generates one. Some campaigns will land and deserve doubling down, others will fall flat and deserve killing in week three. If instead you fixed the activity list on day one of the quarter, you have taken away the only lever that matters, because you decided what would work before you had any information about what works. This is why I prefer the frameworks that push input metrics and leading indicators. Scaling companies operate under real uncertainty about which customers to serve and which story sells, and an operating system that demands you predeclare the activities is fighting that uncertainty rather than navigating it.

EOS, Scaling Up, D4X, and OKRs can all genuinely help. Each one gives you a longer-term vision, clear accountability that breaks up the all-responsible founder, a quarterly goal rhythm, scorecards, and a meeting cadence for tracking against them. That is good structure, and small companies rarely have any dedicated mechanism for working on the business rather than in it. The frameworks buy you that mechanism.

The failure mode is implementing them shallowly, which looks exactly like the shallow Scrum adoptions we have all seen. You have rocks. You have level-ten meetings, accountability charts, right people in right seats. Then you look at what actually happens and the teams are still purely functional, cross-group work is still painful, and leadership is still the coordination bottleneck. You have gained a better protocol for surfacing issues without changing the structure that generates them. One detail I find telling: Scaling Up says process owners should be in charge, and process is not a department. EOS simplified that away, and it was the part that mattered most. Almost nobody implements it as genuine end-to-end value stream ownership, because it is hard and it cuts against the fiefdoms. When leadership is still the bottleneck, you do not yet have a scalable operating system, whatever the framework poster says.

The through-line across all four traps is that structure alone does not scale a company. What scales is organizing the work around outcomes, giving those teams goals expressed as results rather than activity lists, and running a real inspect-and-adapt loop on leading indicators instead of a quarterly status ritual. That combination is what I have consistently seen work, and it is the natural next step once you have brought in a scaling operating system and discovered that the framework by itself did not deliver the traction it promised.

If you are somewhere in the 50-to-500 band and any of this feels familiar, the diagnostic question is simple: how many decisions this month required a leadership meeting because no single team could own the outcome? That number is your operating system’s real score.

This article is based on my conversation with Dave West on the Scrum.org community podcast, part of a series on agility for small and medium businesses.

Listen on the episode page or directly on Spotify, or browse the full podcast archive.

Scaling does not have to cost you agility. It costs you agility when you scale the org chart and forget to scale the way work is organized, measured, and steered.