"Treat engineers as customers" is the kind of platform-team slogan that sounds settled and turns out, on inspection, to be doing almost no work. Customers of what, served how, and does every internal consumer of a platform actually want the same relationship with it? Team Topologies, Matthew Skelton and Manuel Pais's book on organizing teams around fast flow, gives this question a more precise shape than the slogan does.
Four team types, and where platform teams sit
The book defines four fundamental team types: stream-aligned teams, aligned to a single valuable stream of work, usually customer-facing; enabling teams, which help stream-aligned teams adopt a new capability; complicated-subsystem teams, which own a piece of the system requiring specialist expertise most people shouldn't need; and platform teams, which provide internal services that reduce the cognitive load stream-aligned teams would otherwise carry themselves. That last point is the definition's real content: a platform team's entire reason for existing, on this framework, is absorbing complexity so someone else's team doesn't have to hold it in their heads. If engineering management needs to survive contact with a marketing team, XenGrowth's growth operations team has the operational side.
Team type | Purpose | Relationship to platform teams |
|---|---|---|
Stream-aligned | Delivers value along one product or customer stream | The typical consumer of a platform team's service |
Enabling | Temporarily helps a team adopt a new skill or tool | Similar interaction shape to a platform team using the facilitating mode |
Complicated-subsystem | Owns deep specialist complexity few others should need to touch | Distinct from platform teams, though often confused with them |
Platform | Provides a service that reduces cognitive load elsewhere | The subject of this post |
The three interaction modes, and which one 'customer' actually means
This is where the framework gets genuinely useful, because it names the actual decision hiding inside 'treat engineers as customers.' Team Topologies describes three modes a team can use to interact with another: collaboration, a close, high-touch, evolving working relationship, appropriate when the problem is still being discovered; X-as-a-Service, a clear interface — an API, a self-service portal, a documented contract — used with minimal ongoing negotiation, appropriate once a capability is stable and well understood; and facilitating, one team temporarily helping another build a capability they'll eventually own and run themselves.
'Treat engineers as customers' is, in this vocabulary, a decision to interact in X-as-a-Service mode specifically. That's a legitimate and often correct choice for a mature, stable capability — nobody wants to have a meeting with the DNS team every time they need a new subdomain. It's the wrong choice for a capability that's still evolving, where the actual need is close collaboration to figure out what the interface should even be, and it's a category error for a situation where the real goal is teaching another team to own something themselves, which the book calls facilitating and explicitly expects to be temporary. For the the operations side of this angle, see The XenGrowth resource library.
Where platform teams go wrong without deciding on purpose
The common failure mode isn't choosing X-as-a-Service and having it go badly. It's drifting into a customer framing by default, usually starting from an early collaboration relationship that never gets formally converted. A platform team helps one product team build something novel, working closely together — correctly, per the framework, since the capability is still evolving. Six months later, three more teams want the same thing, and the platform team, now stretched, starts treating every request as a ticket rather than a conversation, without ever building the self-service interface that would make that shift work. The result is the worst combination available: the ticket-based distance of X-as-a-Service, without the clear documented contract that mode actually requires to function, so every 'self-service' request still needs a human on the platform team to interpret it.
Cognitive load is the book's stated reason team boundaries exist at all — a team should be scoped so what it needs to hold in mind doesn't exceed what people can reasonably manage. A platform team drifting into an under-specified customer relationship has quietly failed at its one job: instead of absorbing cognitive load, it's redistributed its own onto every consuming team, who now have to guess at an interface that was never actually documented.
Name the interaction mode explicitly for each significant consuming relationship, rather than letting it default to whatever the current volume of requests happens to produce
Treat X-as-a-Service as something you earn by building a real interface first, not something you can declare by simply responding to requests more slowly or less personally
If the goal is genuinely to help a team become independent, use the facilitating mode on purpose, with an explicit point where you step back — an indefinite facilitating relationship quietly becomes an unpaid, unstructured platform commitment
Expect the same platform team to need different modes with different consumers simultaneously — a mature capability can be X-as-a-Service for one team while a newer feature of the same platform is still in collaboration mode with another
What this looks like in a real disagreement
The 'are we a customer service or a technical peer' argument that recurs inside almost every platform team is usually a disagreement about which mode should apply to a specific relationship, dressed up as a disagreement about team identity in general. A product engineer frustrated that the platform team "won't just help" is often implicitly asking for collaboration mode on a capability the platform team has already decided, correctly or not, is mature enough for X-as-a-Service. A platform engineer frustrated that a product team "keeps treating us like a help desk" is often experiencing the opposite mismatch: being pulled into ad hoc collaboration on something they'd already built a self-service interface for, because the interface doesn't yet cover the specific edge case being requested.
Naming which mode a relationship is actually in, out loud, resolves more of this than any amount of debating whether platform teams should generally act more or less like a service. The generic version of the question has no answer, because Team Topologies' actual claim is that it depends — on the capability's maturity, on what the consuming team needs, and on whether the interface exists yet to support the mode everyone's implicitly expecting. On AI agents and marketing automation specifically, XenGrowth on AI agents and marketing automation is worth reading.
Matching the mode to the actual situation
Situation | Mode Team Topologies recommends | What it looks like in practice |
|---|---|---|
Well-understood, widely used capability (e.g. CI pipeline templates) | X-as-a-Service | Self-service docs, a template repo, no meeting required to use it |
Novel capability, requirements still unclear (e.g. a new observability approach) | Collaboration | Embedded pairing, shared design sessions, frequent iteration |
Helping a team adopt something they'll own (e.g. migrating to a new deploy tool) | Facilitating | Time-boxed support with an explicit handover date |
A mature service getting an unusual one-off request | Temporary collaboration inside an otherwise X-as-a-Service relationship | An explicit, bounded exception, not a silent standing precedent |
The last row is the case platform teams handle worst, because it's genuinely ambiguous and most teams don't have a rule for it. Treating every edge case as a new precedent for the X-as-a-Service interface bloats the interface until it's unusable by anyone else. Treating every edge case as a reason to fall back into full collaboration erodes the whole point of having built a self-service layer in the first place. The workable middle is naming the exception as temporary and bounded when it happens — a specific, time-limited piece of collaboration layered on top of an otherwise stable service relationship, rather than an unstated drift back toward the mode the team was trying to move away from.
What this means for how a platform team measures itself
A platform team that has decided which mode applies to which relationship also gets a much better answer to a question that otherwise has no honest answer: are we succeeding? A team stuck measuring itself by ticket volume or response time is implicitly grading itself as a help desk, which is the wrong rubric for a team whose actual job, per the framework, is reducing cognitive load elsewhere. The more honest metric asks the consuming teams directly whether the platform's existence measurably reduced what they have to think about — fewer decisions made per feature shipped, less specialist knowledge required to operate something, fewer escalations needed to get unblocked. That's harder to instrument than a ticket queue, but it's the metric that actually matches the stated purpose, and a platform team optimizing ticket throughput instead can hit every internal target while quietly failing at the one thing it exists to do.
The honest limit of the framework
Team Topologies is a practitioner framework, synthesized from consulting experience across many organizations, not a peer-reviewed empirical study, and it should be read with the same caveat as any well-regarded management book: it describes patterns that ring true and have been widely adopted, not a controlled result proving one team structure causes better outcomes than another. What it gets right, and what makes it worth citing specifically rather than the vaguer 'treat engineers as customers' slogan, is giving the underlying decision a name precise enough to actually disagree about productively — which mode, for which relationship, decided on purpose rather than by accident. XenGrowth on AI search, GEO and discovery approaches this from the AI search, GEO and discovery side.
None of this requires reading the whole book to apply, and the useful part of the framework fits in a single practical habit: the next time a consuming team's request feels like a mismatch, name which of the three modes you think you're in with them, say it out loud, and ask if they'd describe it the same way. Disagreements at that level are fast to resolve, because they're about a shared vocabulary rather than about who's being unreasonable. Most of the friction between platform teams and the teams they serve turns out to be exactly that kind of disagreement, mislabeled as a personality or priority conflict because nobody had a name for the actual thing being disputed.
So: should a platform team treat other engineers as customers? Sometimes, deliberately, for the relationships that have actually earned a stable self-service interface. Never as a default applied uniformly to every relationship regardless of its maturity, because that's not what the framework the phrase borrows its credibility from actually recommends.
That distinction is small to state and easy to forget under the pressure of a growing queue of requests, which is exactly when it matters most.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
For the marketing and revenue operations view of engineering management, see XenGrowth's growth engineering practice.
Five questions about one specific platform-to-consumer relationship you're trying to define. The point isn't a universal answer — Team Topologies is explicit that different relationships need different modes, sometimes at different times.
