As the operator, you need one person answerable for the number itself. Without intervention, nothing changes. Each team is doing its job, and the shortfall exists in the space between the teams, which no one owns. So you appoint a strong leader to work cross-functionally and close the gap. The leader begins their investigation, convenes a working group, and starts sending thorough summaries. For a month everyone engages and it feels like progress is finally happening, but the number is still slipping. You realize none of the activity week after week has translated into action, and at this point you may begin to wonder if the owner you appointed is up for the task.

Still, the person did their job well, and one thing did improve. The org now understands the number better, what feeds it, and where the loss is coming from. At the same time, no team has changed its priorities, so the problem isn’t getting fixed. Why? Because the leader tasked with ownership has not been given the means to change what those teams are working on.

How do you solve this as an operator? Give the owner a lever to push on. A lever is a mechanism for taking a real failure and making one team answer for it: specific, dated, and pinned to their name.

A lever works by producing a concrete failure that one team owns, put in front of the people that the team answers to. Now it’s a specific item they have to account for, so they weigh fixing it against the work they’d already planned, and it can move ahead in the queue.

The lever is the easy part. Figuring out whether your problem can support one, getting the right owner in place, and holding up your end once they start, are what turn it from a mechanism on paper into the problem actually getting fixed. Each of those is also a way these efforts can fail: an unfit problem, the wrong person, or an owner left to fend for themselves.

Getting the right person

What makes a good owner is specific, and it cuts across the usual temperament categories. The person everyone finds easy to work with, and the person who isn’t afraid to press people, can each succeed or fail here. Success comes down to:

• Tolerance for invisible research work. The finding that gets included in a status report is the tip of the iceberg; the digging beneath it is often invisible to others. That work has to get done without visible progress to point to, sometimes for a long time.
  

• Judgment about where to dig. A sense for which threads are worth pulling, and knowing when the picture is precise enough to act on, rather than boiling the ocean or stopping at the first plausible answer.
  

• A track record that earns trust quickly. The owner usually won’t be walking into a situation where they have the teams’ trust out of the gate. What matters is a track record, known to these teams, of being right and delivering on hard things. That reputation lets trust form quickly, so people take the meeting, answer straight, and treat the findings seriously.

Identifying these qualities in a prospective owner is the easy part. The people who fit this description are the ones in a position to turn the job down. They’re in demand, they have other options, and they can see what they’d be taking on: mostly invisible work, with no authority of their own, and a red number that could end up looking like a failure on their part. You recruit them to the role by being honest that it’s a hard job and an opportunity worth taking. For the right person, it genuinely is.

Solving a cross-team problem no one else can crack is exactly the kind of thing that got this person where they are. The work itself is the draw. They get real latitude to dig into something that matters and own the answer, instead of chairing a working group. For someone who delivers hard things, it’s another feather in their cap.

They’ll want to know you’ll stand behind them if it goes sideways. That part is yours to give, and it’s what makes the difference between a hard job they’ll take and one they’ll pass on.

Two types of levers

What follows are two kinds of levers I’ve built and operated. One stages a failure, triggering it deliberately on a schedule. The other collects failures already happening and puts them on the record. (Collecting is the more common case.)

Choosing whether to use a lever, and which type, is your call because it requires a view across the org that the owner doesn’t have, and it requires your authority to make teams act on what it surfaces. Building it is the owner’s job, because it takes close, ground-level knowledge of the failure. You set the intent and the guardrails; the owner works out the mechanics.

When setting the intent, give the team a stake in the fix wherever you can, not just accountability for the failure. With something to gain, the team owns the outcome instead of just complying with a demand.

Staging: Sometimes the failure only shows up under a rare condition, or a process everyone relies on broke at some point and nothing has exercised it since, or the real failure would be too costly to let happen. Rather than wait for it to surface on its own, the owner triggers a controlled failure on a set date, taking a process that one team owns, that everyone assumes works, and testing it. Some fraction of the time it fails. Now there’s a real failure, dated, with one team’s name on it.

Collecting: On their own, defect complaints get handled one at a time. Each looks like an isolated incident, so no one sees the pattern to force an escalation. So the owner builds a running list, every complaint grouped by the team that owns it, kept where those teams and their managers can see it. Once the list is public, the effect is fast. For example, an engineering team that ships a risky change in the morning will see complaints stacking up within the hour, and pull the change back by lunch. Those same complaints used to take days to reach them.

Will a lever work here?

Not every problem can support a lever. For one to work, a few things have to be true:

• Something is genuinely broken. If the problem is “we need a new capability that was never built,” there’s no failure, it’s a request for something new.
  

• The responsible team takes ownership of the problem. Exposing a failure only stings if the team accepts it was their job to get right. If they think it’s someone else’s problem, the finding lands as a nag, and they may tune it out.
  

• The problem splits into parts that individual teams can own. If some core of it can’t be divided that way and still needs several teams acting together, that core lands on no one, since no single team can resolve it or make the others act.

These three conditions are also a filter. You’re rarely dealing with just one problem like this, and you can’t put an owner on all of them. The problems that meet all three are where an owner with your backing will actually pay off.

Consider, for example, a liaison role positioned between two engineering teams. One team owns a customer-facing product, and the other owns the supporting backend systems. The person in the liaison role has no authority over either team. The biggest ask of the year from the product team is for the backend team to deliver a new capability their systems were never designed to support. The backend team says as much, estimates the work honestly, and asks for a design before committing. No lever helps here, because nothing is genuinely broken. The team is requesting something new. A request for a capability that doesn’t exist yet takes its place in the queue behind the others.

When a lever can’t help, the problem is the operator’s, not the owner’s. Where the capability doesn’t exist, or the team that should own it won’t, that means negotiating it onto a roadmap. And where a core of the problem genuinely can’t be split into single-team parts, it needs an authority no single team has: a dedicated group with a cross-team mandate, a senior person with the standing to direct it, or your own hand on it. However you do it, the authority has to come from you.

What you actually need tackled

When you appoint an owner, you’re handing them one job in three parts: find out what’s actually wrong, get the teams to prioritize the fix, and report where it all landed. None of it is glamorous. It’s months of failure reviews, weeks sitting with the team that fields complaints, chasing people across other orgs and waiting for the picture to come together. Here’s what it takes to do ownership well:

• Research and diagnose the problem. Detective work, separating the real failure from everything that resembles it. Done well, it produces a finding precise enough to act on, not “fulfillment is slipping” but the specific point where it breaks down, under what conditions it happens, and which team owns each piece of it. This is where AI helps most, connecting data that sits in separate systems and surfacing patterns across it faster than a person working by hand, though a person still has to judge which pattern is the real failure. This is most of the job, and everything downstream depends on getting it right.
  

• Negotiate prioritization of the fix. Take the finding to the teams who can do the work, whose roadmaps are set and whose capacity is committed. Make the case, team by team, that their piece of the problem is real, that it’s theirs to own, and ask them to change their existing commitments to accommodate work they didn’t anticipate. A good outcome is each team committing to fix its piece by a specific date, or a clear reason why they won’t.
  

• Report where things stand. Bringing it all together in one place, what each team committed to and by when, what’s still stuck, and who it’s stuck on. Put it in front of the operator and the wider org, not left in scattered conversations. A good report is one where a leader with the authority to act can see exactly what’s been agreed upon, and exactly where to push if progress stalls.

Your part of the deal

Everything in the last section, the diagnosis, the negotiation, the report, only turns into action if your weight is visibly behind it. The owner has no standing of their own with these teams, only what you lend them. There are a few things only you can do to set them up, and their work depends on you doing them. Here’s what they are:

• Set expectations, with the teams and with the owner. Tell the teams and their managers that the owner is there to find what’s wrong, not to collect status or run a working group. And tell the owner you’ll evaluate them on the quality of the diagnosis and the case they make to the teams (the things within their control), not on whether the number improves (which depends on others acting).
  

• Put your weight behind the owner’s findings. Tell the teams’ managers plainly that findings from this owner carry your weight and you expect them to be acted on. Then make sure the backing stays visible without you having to chase anything. Have the owner’s report land somewhere you and they will see it, so managers know unaddressed findings reach you.
  

• Step in when the owner is stuck. Most of the time your backing is enough, and the owner never needs you in the room. Sometimes a manager won’t commit their team to the fix, and the owner has pushed as far as they can. In that case, you go to that manager yourself and settle it. Your backing only means something if you follow through when it comes to this. The owner, and the managers, need to know you will.

Knowing early whether it’s working

Early on, the number can’t tell you whether the effort is working. It’s the last thing to respond, long after the effort that turns it around. There are earlier signs to watch, but no single one is completely reliable, each can look bad when things are fine, and look fine when things are bad. So what you’re watching for is the direction the signs are trending, not how they look on any one week:

• The owner’s updates should change in character over time. Early on they sound like “here’s what I’m looking at.” Later they should sound like “here’s what I now think is true, and here’s the one thing I need from you.” That’s the progression you want, from surveying to a hypothesis to a specific ask. The absence of that progression means the effort has stalled. A stall can mean the owner isn’t getting it done, or that something outside their control is blocking them, and distinguishing the two is your job.

• A healthy diagnosis narrows over time. Early on the owner will have a long list of possible causes and won’t be able to rule any out, and that’s fine. What you’re watching for is the list getting shorter as the owner digs, with potential causes being eliminated, not just added. A list that keeps growing with nothing ever crossed off means the owner is accumulating theories instead of testing them.

• Being agreeable isn’t the same thing as being engaged. Taking the meeting costs nothing. What matters is whether a team digs into what the owner found, argues the specifics, checks their own data, or just receives it and does nothing. Performative engagement and flat refusal are different problems, but both mean the owner has hit something the setup you gave them can’t get past, and that’s where your attention is worth spending.

Telling which way an effort is going takes time. Getting it wrong goes one of two ways. You might give up on one that was only slow, or you might keep backing one that has actually failed. The second is the harder mistake, because a failed effort is easy to mistake for a slow one.

Who volunteers next time

Whether you can get someone to own the next cross-team problem depends on how the last one went. Do it right and you’re no longer talking reluctant people into it; you’re choosing from the ones who want it! The people who can do this work talk to each other, and they watch what happens to the person who takes it on. Put someone through a year of chairing a working group with no authority and nothing to show for it, and word gets around. But give someone a real problem, back them the whole way through, and make sure they get the credit, and the next person will already know it’s worth saying yes to—and the best of them will come to you before you have to ask.

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.