Last spring a support manager told me about the moment she realised her team had outgrown its model. A customer’s checkout had been flaky for three weeks, three different shifts had fixed it three different ways, and nobody could say whether things were actually getting better. She did not need more people. She needed a way to decide who owns reliability, how it is measured and how work is shared. That is the question site reliability engineering, or SRE, tries to answer, and it comes in several team shapes. This piece compares them in a human way, drawing on the model list in the SRE entry of the Ops Atlas as the cited reference.

The six shapes at a glance

The Atlas, summarising guidance from a major cloud provider, describes six patterns. A kitchen-sink team does a bit of everything. An infrastructure team looks after shared platforms. A tools team builds the internal software others use. A product team is aligned with one customer-facing service. An embedded engineer sits inside a development group. A consulting team advises from outside. Each has named risks, and the right pick depends on what you are trying to fix.

Kitchen sink: the generalist squad

What it feels like. Everyone does everything. A single group takes alarms, builds automation, reviews releases and answers the odd question from management.

Strength. Fast to start. One team, one queue, minimal handoffs. Small companies and managed support desks often begin here simply because nobody else exists.

Risk. It slides into becoming a ticket queue. Without a firm ceiling on manual work, the group drowns, and the cited guideline of keeping toil under half of working time quietly stops applying.

Infrastructure team: serving everyone

What it feels like. A platform group with many internal customers. Reliability here means the shared layers underneath dozens of applications.

Strength. Economies of scale. One group invests in shared monitoring, deployment tooling and capacity planning, and everyone benefits.

Risk. Distance from the end user. The Atlas urges measuring close to the person actually using the product, which is harder when your direct customers are other engineers. The decision tree in the entry suggests this shape when infrastructure is genuinely shared.

Embedded engineer: one seat at the developers’ table

What it feels like. A reliability specialist who sits with a product group, joins planning and shares its goals.

Strength. Trust and context. The embedded engineer sees risky changes early and can raise the budget conversation at the right moment.

Risk. Isolation. A single person can be pulled into feature work, or can burn out when carrying a pager alone. A rotation of around eight people is the guideline for single-site, round-the-clock cover, so one embedded engineer cannot be the whole answer for a critical service.

Consulting: advice without ownership

What it feels like. A small group reviews designs, helps teams write objectives and teaches the vocabulary.

Strength. Leverage. A few people can nudge many teams in a sensible direction.

Risk. No skin in the game. If nobody owns the outcome, advice can pile up unread. Many managed-service providers face a version of this: recommendations delivered, outcomes unchanged.

Where a managed support provider fits in the comparison

Managed support teams usually look like a kitchen-sink group serving several clients, with a dash of consulting. No judgement is meant by that; it is merely a different shape from an in-house product-aligned team. The key difference is who signs the policy. In an SRE arrangement, the error budget only matters if somebody with authority has agreed what happens when it runs out. A provider can bring the measurement and the discipline, but the client must be willing to accept things like holding back non-urgent releases after the allowance for the last four weeks is gone.

Here is a simple way to compare, using a 99.9 percent objective across 28 days: the budget is roughly forty minutes of failure. An in-house team can spend that on risky releases whenever it likes. A provider operating several clients needs each client’s budget tracked separately and each policy agreed individually. Neither arrangement is superior; they simply ask different things of the people involved.

A small scene from the support floor

Picture a Tuesday evening. Alarms fire for a client’s order service; the engineer on shift sees four alerts and cannot tell which matters. In a kitchen-sink model, she handles all four in order of arrival. In a budget-driven model, one alert tells her the allowance is draining at a rate that will empty it in a few hours, while the other three are minor leaks bound for the morning ticket queue. Same person, same tools, different arrangement, and a calmer evening. This is what people mean when they say the shape of the team matters as much as its size.

A quick comparison grid

• Speed to start: kitchen sink and consulting are quickest; infrastructure and product teams take longer to staff.
• Closeness to users: product-aligned and embedded rank highest; infrastructure ranks lowest.
• Scalability across many services: infrastructure and consulting score highest.
• Risk of toil overload: highest for kitchen sink; lower where tickets can be redirected to developers.
• Accountability for outcomes: clearest in product-aligned and infrastructure teams; weakest in pure consulting.

How to choose without agonising

Start with four questions drawn from the Atlas decision tree. Would users notice an outage? Will an executive sign a budget policy? Once the first chores are automated, will manual work stay under half of everyone’s hours? Is a duty roster of roughly eight people realistic? If the answers are yes, an infrastructure or product-aligned model is within reach. If not, begin with a smaller step, perhaps a consulting or embedded arrangement while the groundwork is laid.

People often ask whether any of this means replacing a support function. It does not. The label matters less than what the team does: a renamed support desk is what the Atlas calls fake SRE, and the label changes nothing without objectives, budgets and real limits on toil. For a perspective on moving from classic operations to engineering-led work, take a look at this article on operations engineers embracing infrastructure as code and SRE, and for the principles behind sensible delivery, an overview of the foundations of effective software delivery.

The ending of the story

The support manager did not rebuild her department. She picked one customer-facing path, agreed a 99.9 percent objective, tracked the budget on a shared chart and held one review whose actions all got closed. Within two months the three-fixes-three-ways problem had stopped. Whatever shape you choose, the human part is the same: agree a promise, count honestly and keep your follow-ups.