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:

1. Deciding the rebuild is worth doing.

2. 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.

1. 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.
   

2. 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.
   

3. 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.

Context is stripped away at each stage as the metrics flow upward. An engineer knows what the metric measures and how the system behaves when it moves. A manager knows it’s trending in the right direction and has a story for why. Leadership knows the number. By the time a metric reaches the top, it’s been separated from the system knowledge that grounds it.

This pipeline of abstraction reflects how organizational systems are designed, and how incentives are structured. The engineer is paid to ship features and keep the pager quiet; drawing a through line from their system to leadership three levels up isn’t in the job. The manager owes leadership a clear story, not an accounting of what the metric might fail to capture. Leadership needs metrics to govern by, and interrogating each one against its underlying mechanisms isn’t scalable at that altitude. P&L owners make headcount and product strategy decisions based on information that has been compressed and separated from its original context. The work of connecting numbers to understanding falls between roles rather than inside any of them.

The result is often an environment where metrics are abundant but understanding is scarce because the connective tissue is absent. Without an understanding of how a business outcome metric relates to the service-level metrics that support it, and to the related raw system signals underneath, companies end up making decisions from numbers they can’t validate.

The gap becomes visible when a top-line metric turns red and someone asks, “Why?” The efficiency that made it easy to communicate product health upward becomes a liability. The director doesn’t have the intermediate metrics on hand, the manager’s story doesn’t reach far enough down, and eventually a tech lead is explaining how the system works to an audience that just needs an answer. No one in that chain has done anything wrong; the chain simply doesn’t convey context in the same way that it carries numbers.

Mapping what drives what

The best way to avoid this common deficit is to capture the causal relationships between metrics up, down, and across the product stack. When a top-line business metric moves, it’s because other metrics beneath it are moving, and usually more than one of them could be behind it. If an organization can’t see those relationships, it can’t explain why the top-line metric is moving, and that’s a problem for the business.

For example, imagine that revenue starts to decline. Often revenue drops because quality degraded, and quality degraded because of an underlying systems issue like CPU utilization spiking (see Figure 2). If leadership only sees the revenue decline and assumes it’s a pricing issue, the organization risks spending time solving for the wrong problem. Engineering cycles get burned, the metric stays red, leadership loses confidence, and the actual root cause continues to compound underneath.

Two tests for every metric

The work starts with cutting, not adding. Most product and engineering teams approach metrics as an additive exercise:

• What else should we measure?

• What dashboard should we build?

• What new instrumentation should we add?

New initiatives bring new metrics, and old ones rarely get retired, resulting in accumulation. Product and engineering leadership should review the metrics they currently track together and eliminate everything that doesn’t pass the two tests (see Figure 3):

1. What decision could this metric change, and for whom?

2. If it turns red, can the team explain why?

When in doubt, discard the metric. If you’re not adding some back in later, you didn’t cut enough in the first place.

This is a joint exercise. An engineering manager runs the tests against the metrics their team tracks. If a metric helps the engineer on-call debug an incident, it’s an operational metric: keep it on the team dashboard. If it tells the C-Suite how much revenue the product is generating, it’s a business metric: present it to leadership. If nobody can answer the question, throw it away! P&L owners should be running the same test from the other direction: For every metric I’m being shown, what decision am I supposed to make with it? If the answer isn’t clear, push back.

For each metric that survives, someone needs to own the question: If it turns red tomorrow, can the team explain why? Not speculate, or bring in a tech lead to do an architecture deep dive, but actually explain what moved and the cause? If the answer is no, then causal relationships haven’t been established. Product and engineering leadership must assign this work as part of how the team ships, with dedicated resources and accountability for finishing it.

What this costs leadership, and who can fix it

When the effort of understanding metrics is positioned as a separate initiative, it is often starved. Feature work is tied to revenue and will always win the resource fight, and it should. The way to fund an effective metrics effort is not to give it its own line item, but to build it into how teams ship, so that it draws from the same budget and the same engineering cycles.

P&L owners should look for excellence in metrics embedded in their teams’ shipping process, not sitting on a separate roadmap competing for resources it will never win. If the metrics reaching the quarterly review can’t be traced back to the system behavior that drives them, then the organization hasn’t done the work yet, and the P&L owner is the person with the authority and the budget to make it happen.

What world class organizations do

In order to know what’s actually driving the business, product and engineering should map the relationships between metrics top to bottom as part of planning and shipping. Product defines which outcomes matter, and engineering maps how the system metrics drive those outcomes.

Together the product team, and the engineering organization supporting it, must be able to trace the metric’s movement. If it turns red, can a manager point to the intermediate metrics that explain why, and follow the breadcrumbs from business outcome, through service behavior, to root cause? If not, as soon as the top-line business metric moves out of range, it’s time for a code red.

If this feels familiar, know that it’s nearly universal. The work ahead is figuring out which metrics should stay or go, and developing the capability to understand the ones you keep. Pick a place to start, keep it simple, and focus on an area where you’re most likely to earn early wins: for example, the service your team knows best, or the one you most recently had to do a deep dive on due to an incident. In practice this means running those two tests for each metric you are examining. The goal is to understand what the metric tells you, and whether it matters.

Working from the metrics that have passed the tests, narrow the scope to what the organization is actually trying to answer. Don’t attempt to map causal relationships across the entire product ecosystem. Focus on the three to five services that matter most to the business. If it’s not obvious which ones those are, then product and engineering leadership must ask together: Which services have triggered a code red in the past, which ones directly generate revenue, and which ones would have leadership asking questions within an hour of going down? Once there’s a short list, you can bring it to the P&L owner for alignment.

Mechanics for engineering teams

The following practices have proven valuable to engineering teams. P&L owners may find it useful to understand what they’re funding, but the suggestions here are for the people doing the work.

What are some good mechanics to use for embarking on this process? It depends on where your engineering team is at, in terms of maturity.

If the engineering team doesn’t have production on-call handoffs, now is a great time to set them up:

• Schedule a weekly team sync where the outgoing engineer hands off context about what happened in production to the incoming engineer.

• Use this forum to identify and discuss emerging trends and, importantly, make decisions about what to do and who will do it. For example, what do you do with an inactionable alert?

• Discuss, investigate, and assign an owner to address issues before fatigue sets in and people on rotation start ignoring signals (like ignoring alerts in the example above).

If the engineering team is already doing handoffs:

• Establish a cadence of internal metrics reviews.

• Devote the first 10 minutes of the handoff meeting to reviewing the metrics that the team currently tracks: Are they behaving as expected, are any missing, and does each one still belong in the review?

• Once you’ve got a good internal metrics review cadence going, start a forum with peer teams where each one presents the metrics they track for their services and how they interpret them. This is where you pressure test whether what you’re projecting outside the team holds up, practice explaining your metrics to people who don’t share your context, and discover causal relationships that cross team boundaries.

These practices will surface gaps, and that’s what makes them so valuable. Metrics that can’t be explained, alerts that aren’t actionable, and causal relationships that haven’t been mapped, are all important information. Often the gaps accumulate into an operational backlog which sits alongside the feature roadmap, and in most organizations the feature roadmap draws the resources first. The way forward is to treat the gaps as part of the feature work itself. If a feature moves a metric, explaining why is part of shipping that feature, not a separate item for a separate backlog.

A final word

Developing metrics as an effective tool for decision making is a process that begins with collecting the right data, and grows in importance and impact as that data reaches more people. It’s important that this develops alongside a capacity to reason about what the numbers really mean. An organization where understanding flows upward alongside the numbers will always be in a stronger position to make strong, data-driven decisions.