When organizations outgrow the way they’re run
…and what to do about it as an operator
Every team has an operating model, whether or not anyone built it on purpose or wrote it down. It gives the answer to who owns which systems, who gets the call when something breaks, and how decisions get made. When you run a whole organization, you’re responsible for several operating models at once, one per function. They’re rarely at the same stage of maturity.
When a company is small, every function is small enough that its model can remain unwritten. That’s part of the fun. A handful of people who talk every day don’t need named owners or decision rights; putting them in place too early just gets in the way. It works because everyone can stay in close contact, and it often works well for longer than people expect. But functions grow at different rates. One by one, they outgrow their operating model, and they do it on their own schedule (see Figure 1).
Knowing when a function has outgrown its operating model is one of the things that is critical for an operator. Functions mature at different rates, and part of the job is noticing where one has outgrown its stage, and being discerning about risks: which to act on, and when. The first step is recognizing which stage each function is in.
Recognizing the stages
Most functions move through three stages as they grow: self-organizing, structured, and specialized. The signs of a functional area’s stage show up in how decisions are made and work is handled. To keep this concrete I’ll describe each stage from the perspective of an engineering function; however, the same arc shows up in operations, sales, or any function that grows.
Self-organizing. A function in this stage runs on close contact.
Early in my career I worked at a small company where the whole team sat at the same long tables, and most decisions got made in whatever conversation was happening nearby. If someone wanted a status update, they needed only to turn to their neighbor. New tasks were picked up by whoever was interested. It was fast, and it had the feeling of being in on something together. It’s exciting, and also chaotic in a way that’s easy to forgive at the time. Priorities swing with a single conversation. The urgency that makes it feel alive also makes it hard to predict, and now and then something gets dropped before anyone notices.
You can tell that a function is in this stage when people spend most of the day talking to the same few colleagues and can launch a new feature without seeking three levels of approval.
Structured. A function in this stage runs on what’s written down rather than who’s in the room, and it feels steadier for it.
Almost every structured function I’ve worked on has shared a handful of traits. Someone could cover for a system even if they hadn’t built it, because the steps for debugging it were written down. Release processes were documented so anyone could take a turn running them. Developers reviewing each other’s work was expected, and was how new people learned. The effect is that anyone can take a day off and the team keeps moving. It feels calm even under real deadline pressure, more deliberate than frantic.
You can tell that a function is in this stage when responsibilities rotate on a schedule, a bad week ends with a good retrospective, and everyone on the team uses their vacation days.
Specialized. A function in this stage has become multiple. Specialized teams form when one structured team can no longer cover the whole domain.
I once ran a reliability team that grew until it had to split into several, each aligned to a different part of the business it supported. The change that specialization enabled was depth: instead of spreading a few people thin across everything, each team could go deep on the area it owned, taking on more ambitious work and building what its part of the business needed. The people on those specialized teams know exactly what they are responsible for, and they become the experts in their area. In exchange, the function takes on more coordination: keeping teams aligned now takes deliberate effort, shared plans and standing meetings the simpler structure didn’t require.
You can tell that a function is in this stage when it has a charter and operational cadence meetings, and when much of its roadmap requires cross-functional planning and execution.
Paying attention across functions
Operators running an organization monitor several functions moving through these stages at once, each on its own clock. For example, Engineering might still be self-organizing, while Marketing has structured itself, and Sales is starting to specialize. There’s rarely a shared map that says which function is in which stage. The first step is to discern the operating models of your functions, and do the work to identify where any one of them has started to strain (see Figure 2).
What are the signs of strain? One sign is when the same kinds of problems are recurring in one function. For example, in Engineering, perhaps a software change shipped and broke something, and no one had been assigned to review it beforehand. Or, a migration stalled because the person driving it got pulled onto something else, and picking it back up wasn’t anyone’s responsibility yet. What marks a function as being at the limit of its operating model is that these problems keep happening. These signs are easy to miss from the outside, because a function’s own account of itself is partial: its leader is watching whether the team is okay, not whether the business is. For a more reliable signal on how the function is doing, observe the teams that depend on it. When they start routing around it, picking up the slack themselves, or going elsewhere, that’s a sign the function is straining.
Rebuilding how a function runs costs momentum, and sometimes it costs people who liked the old way and don’t want the new one. Letting a function outgrow its model runs up a bill that’s easy to miss, at least for a while, because no single aspect of the strain looks alarming. Work slips through the cracks and gets written off as a bad week. The teams it serves stop counting on it, communication slows, and relationships cool. The strongest people start to leave because they can’t see the work getting better. None of these on its own is acute enough to force a change, so a function can sit at its limit for a long time, the costs staying easy to ignore right up until they aren’t.
When deciding which function to rebuild first, start with where strain is compounding fastest. Sometimes that function is the least ready for a rebuild, and you do it anyway, because the conditions won’t improve on their own and the cost of waiting only grows.
Deciding whether to rebuild
Moving a function to its next stage takes two things:
Deciding the rebuild is worth doing.
Designating someone to lead the rebuild and giving them the mandate to do it.
Before committing, it’s important to assess whether the operating model is really what’s holding the function back, because a few other problems can look the same from outside. The most common is plain overload: a function with too many priorities will see its decisions stall regardless of how clean its ownership structure is. In this case, a shorter priority list will do more than any redesign. Other times, the gap is a missing manager to carry the day-to-day people work (the 1:1s, the hiring, keeping everyone unblocked). If one of those is what’s going on, that’s the place to start.
Priority overload and a missing manager are both about load: too much work, or no one tending to the people. A model problem is a gap in how the function is set up to run, in who owns what, who decides what, or what the guardrails are. The failures trace back to the ownership gap, rather than to load: a change nobody was assigned to review, or a migration nobody was on the hook to pick back up. When one of these recurs, consider who was supposed to handle it. If there’s a designated owner who was buried with other work then the problem is load; but if it was never anyone’s job to begin with, it’s the model.
From there, the rebuild itself is concrete work: naming an owner, working out decision rights, and adding guardrails for failures that the function has already encountered. The mechanics are described below.
Running the rebuild
Living with a real, recurring problem tells you what the fix needs to be. The through-line is: wait until the team can point to the problem before adding the structure that solves it.
Name an owner for how the function runs. Give one person the authority to set direction and own delivery, and make the role’s existence unambiguous. This may be the person who led the rebuild, or someone else (a new hire, or someone already on the team). Part of the job is deciding which decisions to delegate, and which to retain.
Make ownership and decision rights explicit. Write down who owns which systems, and who makes which decisions. The latter is the part teams tend to get stuck on, so it’s worth being concrete about: who can say no to a launch, who breaks a tie, and who sets priorities when people can’t agree.
Add guardrails. Put rules in place to prevent failures the team has already encountered. A rule that addresses a real failure earns its place; one added beforehand is just a guess. The way to tell them apart is to consider whether you can name the failure the rule prevents. Rules that stop a specific, nameable failure are almost always worth adding.
Getting the rebuild approved is its own piece of work. A restructure usually needs someone above to fund it, and the instinct is to build an airtight proposal and bring it to that person. The decision maker leans on the people around them, so you need to win those people over before you ever make the formal ask. In practice that means going to the teams affected by the change, working out what they need, and shaping the proposal around those needs. By the time the proposal reaches the decision maker, the people they’d check with have already decided that they want it. Building the demand up front is most of what makes a restructure cross the finish line.
The lag after the rebuild
Operators sometimes underestimate the lag that follows an operating model rebuild. The new model can be designed and announced in a week, but the team continues following the old ways for a while out of habit. The rebuild is finished only when the new way is fully adopted and becomes how people actually work.
One place where this lag shows up is in whom people treat as being in charge. The new owner has the title, but peers and other teams keep going to whoever held the role before, because that’s who they trust to make things happen. The operator must be the one to close that gap, routing decisions through the new owner in front of everyone and declining the end-run when someone tries the old path. This effort continues until the new owner’s standing in the group catches up with their title.
A continuous process
A function that reaches the specialized stage doesn’t stop there. Specialties themselves grow, and each one starts the whole progression over inside itself. The pattern repeats at every level, one stage down each time. No function’s model is ever finally right, only right for what it needs now: enough to keep moving as it grows, without slowing it down.
Because you’re overseeing several functions at once, something is always due for a rebuild. The job is to keep watching across your functions, and to treat rebuilding the ones that have outgrown their model as part of the ordinary work of running the business. You won’t always get it right, but a “good enough” read is one that you can act on before waiting gets expensive.