Emily's platform team has a cost problem. They run thousands of workloads for application teams, and too much compute sits idle most of the day. Emily has a fairly obvious proposal. Let’s run the clusters at higher utilization, keep less spare capacity around, and let autoscaling add machines when demand increases. It all makes sense, she tested the change and with this optimization, the platform should become considerably cheaper.

SRE wants to review it because it touches capacity at a fundamental level. One of the larger application teams wants to understand what happens during its daily processing peak. The cloud support team wants to be in the loop because they manage the layer between Emily's platform and the cloud provider underneath it. All of a sudden, a proposal that looked like an internal platform optimization now needs four teams to be on the same page.

Why does a team that supposedly owns the platform need everyone else before it can decide how efficiently to run its own clusters? The answer is some combination of history, risk, and everyone’s comfort. In all honesty, this is not a particularly satisfying answer. Hence, the meeting becomes another candidate for simplification. Let Emily's team own the decision, automate whatever checks matter, and stop coordinating something that should sit inside the platform team’s remit.

A lot of the time, that is exactly what should happen. Companies accumulate processes after failures and forget to remove them when the original conditions change. Nevertheless, some meetings are surprisingly hard to kill. You remove the call and Emily finds the same people in Slack. You tell her team they own the capacity model and she still checks with SRE. A large application rollout appears and suddenly the cloud support team is involved again because somebody wants to know how quickly another hundred machines can actually appear.

I used to read that mostly as an ownership problem. Now I think some of these meetings are doing an interesting job that we haven’t named properly. There is an invariant condition the system has to preserve, but the knowledge required to preserve it has been split across several teams. Emily owns the platform, but she does not own everything that determines whether the platform still works when she makes it more efficient.

The meeting is where she puts those pieces back together.

From Meeting to Slack ThreadFrom Meeting to Slack Thread

The Team Owns the Platform

Emily's team owns the clusters, scheduling, autoscaling, capacity management, monitoring, and the tooling application teams use to run their workloads. If you ask who owns the platform, there is a direct and unambiguous answer. This is usually what we mean when we say a team is autonomous.

Emily’s optimization gets support from product and management. Her team changes the capacity model. Instead of keeping a large pool of machines ready, the platform will run at higher utilization and ask the underlying cloud provider for more capacity as demand grows. While testing, they see new capacity arrives quickly enough. From the platform team’s point of view, they are shaving off the fat.

While talking to SRE, Emily realizes they don’t have a good answer for when a node group fails while the platform is already running close to capacity. SRE has a recovery model that assumes workloads can move somewhere else. If twenty machines disappear, the scheduler needs enough space to place those workloads while replacement nodes come online. At lower utilization, that space is already there. Under Emily's new model, recovery may first require the platform to acquire more infrastructure.

The cloud support team makes the problem a bit worse. The platform can ask for another twenty machines, but that does not mean AWS or GCP can always provide the exact instance type immediately. There may be capacity pressure in the availability zone, quota limits, or simply several minutes between the request and a usable node joining the cluster. Unless capacity has been reserved, the layer below Emily's platform offers a capability, not a promise that the machines will be waiting exactly when she needs them.

Emily's optimization still makes sense. Keeping thirty percent of the infrastructure idle forever is expensive. SRE is also right that some of that apparent waste was buying recovery room, and the cloud support team is right that autoscaling cannot manufacture guaranteed cloud capacity out of an API call.

Nobody necessarily made a bad decision inside the thing they own. The problem appears when those assumptions meet.

In distributed systems, an invariant is simply a condition that must remain true for consistency. Independent operations are safe when they can happen separately and still preserve that condition once their results come together. Organizations end up with the same problem because we assign ownership to components, while the guarantees we care about do not always stay inside those boundaries.

What nobody clearly owns is the invariant condition that enough usable capacity must exist, or be guaranteed to arrive quickly enough, when application demand and recovery demand happen at the same time.

The Merge Is Where It Fails

After the meeting, Emily changes the design. The platform can still run at higher utilization, but it will keep enough headroom to survive the loss of a normal node group without waiting for the cloud provider to supply replacement machines. The savings are smaller, but still meaningful, and everyone is happier with the recovery story.

A few weeks later, one of the application teams prepares a large backfill. They have been allocated the capacity, they are within their quota, and the platform explicitly allows them to scale their workload to that size. From their side, there is nothing unusual about the request.

Emily's new capacity model is also behaving exactly as designed. Idle compute is lower, scaling works, and the platform has retained the recovery headroom she agreed with SRE. The application workload starts consuming that headroom because, as far as the scheduler is concerned, it is available capacity that the application team is entitled to use.

This is a failure of invariant confluence in a form that is easier to recognize at work. The rough test is whether two valid states, reached independently, can be combined into another valid state. If they can, the work can proceed without coordination. If they cannot, something has to coordinate before both decisions become real.

Two decisions can each be valid on their own and still break the invariant when they become true together. That is where coordination begins.Two decisions can each be valid on their own and still break the invariant when they become true together. That is where coordination begins.

Nothing about the application team's backfill was invalid. Nothing about Emily's utilization target was invalid. The failure is in the combination. Emily thought she had reserved recovery headroom, while the application team reasonably thought unused capacity inside its quota was available for work.

Emily only sees the conflict because the backfill comes up during the capacity review. You can document everything for individual teams perfectly and still have the same problem. The application team can have a correct quota document. Emily can have a correct capacity model. SRE can have a correct recovery procedure. Cloud support can have accurate provisioning expectations. Documentation gives you the necessary information; however, somebody still has to notice when the pieces cannot all be true at the same time. What makes that context portable is not merely a record, but the reasoning behind the record.

Not Every Change Needs Coordination

The wrong lesson would be to require Emily to discuss every capacity decision with SRE, cloud support, and every application team. The platform exists partly so application teams do not have to understand the infrastructure underneath it, and forcing everybody into every decision would defeat very reason for having a platform team in the first place.

Coordination appears where two teams are making decisions about the same underlying constraint without realizing it. The useful test is whether another valid decision can make Emily’s decision invalid. If an application team can consume capacity Emily considers reserved for recovery, it can. If a cloud provisioning change can turn a two-minute scaling assumption into fifteen minutes, it can. If another team’s decision cannot alter the condition Emily depends on, there is probably nothing to coordinate. This is a stricter version of the cross-team dependency problem: the teams are not really waiting on one another; they are each changing a condition the other needs to remain true.

Emily does not need every application team involved in how the platform controls cost. She needs the platform to distinguish between capacity applications may consume and capacity that exists for recovery. That protected room is not waste; it is part of the capacity allocation the system needs to remain reliable. She needs SRE when the recovery assumptions themselves are changing. She needs a clear promise from cloud support about what the infrastructure layer underneath her can and cannot guarantee.

Once the invariant condition is defined then you can start arguing about where it should actually live.

The Meeting Is Part of the Architecture

By the time Emily looks at the next capacity change, the recurring meeting makes more sense. Everybody owns something tangible, but Emily needs a decision formed from several of those things. So they meet. It is exactly the kind of meeting that earns its place where incomplete information and competing assumptions can change the outcome.

This is where the work runs on different maps. The ownership map says Emily owns the platform. The expertise map sends her to SRE when she wants to know what recovery actually needs. Another part of the expertise map points toward cloud support when her design depends on obtaining infrastructure quickly. Application ownership sits somewhere else again, because only those teams know which workloads can be throttled or delayed when the platform is under pressure.

The meeting is effectively combining those maps for half an hour. If the meeting is the only place where everyone discovers that the same twenty machines have been commited to normal workloads, recovery, and a large backfill, removing it mostly makes the contradiction harder to see. Once the invariant condition is implemented at the platform level, coordination is no longer required. Yet even after encoding it, the meeting often lingers.

Then SRE raises something Emily has not encoded. The cluster has been behaving badly during scale-up for several days. Nodes eventually arrive, but some are taking much longer to become usable than normal. The cloud support team cannot see an obvious capacity issue and all the normal metrics are technically inside their limits. Emily's cost change passes every rule they have written down, but SRE does not like reducing headroom further this week.

Emily waits, and I think that is fine.

The goal is not to remove the human because a human is involved. The interesting question is what information SRE is bringing into Emily's decision. If the same concern appears every week, then perhaps the platform is missing a signal or the contract with the underlying infrastructure is too vague. If this happens twice a year because several odd conditions happened to line up, judgment may be exactly what belongs there.

This matters even more when the change is made by an agent. An agent acting for Emily can enforce the recovery floor, check application demand, and query the AWS capacity information it has been given. It cannot know that the last three scale-ups behaved strangely and that SRE no longer trusts the usual assumptions unless that change in confidence exists somewhere the agent can see. The hard part is still deciding where the automation has to stop.

The approval process has never been the interesting part for any org. What matters is what Emily learns before making the decision.

Meeting Creeps Back

Eventually, Emily's team removes the recurring capacity review. Most of the obvious conditions are now represented by the platform itself, and application teams can no longer accidentally consume capacity reserved for recovery. For a while, nobody misses the meeting.

Another application team plans an unusually large backfill. Emily notices that it will keep the cluster close to the recovery floor just as node replacements have begun taking longer than usual. SRE asks whether additional capacity can be brought online, but cloud support cannot promise the usual scaling time because the preferred instance type is constrained in one availability zone. By lunchtime, four teams are discussing whether to move the backfill, reserve more capacity, or temporarily use a different instance type. The recurring meeting is gone, but the same people have found one another because the constraint has appeared in a slightly different shape.

The old process may have been clumsy, but it did not create the dependency; it gave Emily somewhere to see it all at once. Cloud capacity, application demand, and recovery behaviour keep changing, and representing every possible condition as a static rule would create another kind of mess. The fact that coordination keeps returning is evidence that the dependency still exists. Like a roadmap, the process is only the visible artifact; the underlying system is what keeps producing the same constraint.

There is another risk too. If Emily repeatedly has to reconstruct this picture herself, she eventually becomes the person who remembers which application has the unusual peak, which node pools recover slowly, what SRE considers enough headroom, and which AWS capacity assumptions are real versus merely probable. Before long, several of these maps start overlapping on Emily.

That may look like Emily becoming very experienced, and she is. But the platform has not become more independent because Emily learned all the places where it is not.

Look at the Last Five Calls

Emily goes back through the last five capacity discussions and looks only at what changed her decision. Four introduced information the platform could not yet represent. The fifth merely confirmed conditions the platform already enforced.

That last meeting probably did not need to happen. The others told Emily something much more useful. If the same invariant condition keeps appearing, there is probably something concrete to move into the architecture, the interface, or the ownership model. If nobody ever introduces information that changes anything, the meeting is probably a habit.

Whenever Emily has to gather application teams, SRE, and cloud support before making her platform cheaper, she is manually enforcing an unwritten system guarantee: capacity must exist, or arrive quickly enough, when spike and failure happen together. Until that invariant lives in the platform's architecture, the meeting is the only thing stopping two perfectly valid decisions from colliding into a broken system. The meeting goes away when the system handles the merge without Emily having to connect the dots.

Good Reads