What platform work actually looks like

Platform teams live or die by adoption. And adoption usually means getting code merged into codebases owned by other teams. That makes cross-team collaboration the core competence of any platform organization. But the right way to collaborate depends a lot on what kind of work is being done and who is in the driver's seat.

There are three distinct phases of platform work: migration, consumption, and evolution. Each has its own dynamics when it comes to who owns the code and who benefits from the change.

Before going further, a note on the players. Product delivery teams build features for the company's end users. They are the platform's customers. Platform delivery teams build internal products consumed by those product teams. In Team Topologies terminology, product teams generally map to Stream Aligned teams, while platform work often means operating in an Enabling mode, helping other teams succeed.

This discussion covers internal platforms far beyond the buzzy Internal Developer Platform (IDP) category. A data platform, a shared design system, an experimentation tool — all count. So do internal services exposing shared business capabilities like money movement or product catalog. The common thread: a platform is an internal product whose customers are other teams in the same company.

Migration: driving changes into someone else's code

In a platform migration, the platform team is driving changes to codebases owned by product teams. That creates an inherent tension: the work is a priority for the platform team but often an unwelcome interruption for the team that owns the code.

Migrations take many shapes, from boring upgrades to deeply invasive work: bumping a shared library version, lifting a service to a new runtime, moving observability instrumentation to a shared internal library, swapping a direct third-party integration for an internal wrapper service, or migrating from one internal service to its successor — say, moving off an old User service onto an Account Profile one. Infrastructure re-platforming — containerizing a service, introducing a service mesh, switching a database layer — follows the same pattern.

The catch is motivation. If the new platform capability is genuinely exciting, product teams may be happy to make the switch. But often the migration is driven by an architectural agenda that delivers most of its value elsewhere, and the product team takes on churn without much benefit in return.

Filing tickets doesn't get you far

The most straightforward approach — file a ticket in each product team's backlog and let them do the work — has surface appeal. It is scalable: you can fan the work out to every codebase that needs changing, and a program manager can own the process.

The drawbacks, though, are predictable. Product teams have their own priorities, and a platform migration that brings them little direct value tends to sink to the bottom of their backlogs. Lead times stretch out, and the platform team spends its time in prioritization battles rather than shipping.

Doing it yourself isn't scalable

At the other end of the spectrum, the platform team makes the changes directly. This shows up in three related patterns: an engineer embedding with the product team as a tour of duty; a trusted outsider pattern where a small set of platform engineers are allowed to open pull requests on the product team's code; or a true internal open source model where any platform engineer can contribute.

This approach generally reduces lead time because the team that wants the work is the one doing it. Incentives are aligned by definition.

The trade-offs are equally clear. First, the product team has to be comfortable with the arrangement — comfortable enough either to host an embedded engineer, to trust outsiders with their code, or to invest in the process overhead of an open contribution model. Second, it does not scale. A platform team's engineering capacity is finite, and every migration it executes itself is capacity it cannot use elsewhere.

The realistic middle ground

In practice, what actually happens is a hybrid. A platform team will file tickets broadly, cajole for a while, and get a meaningful portion of the work done by the product teams themselves. Then they identify the stragglers — the teams too busy or too resistant to get around to it — and roll up their sleeves. The ticket drumbeat handles the bulk of the portfolio while the direct-engagement patterns mop up the critical leftovers.

When Product Teams Drive Platform Work

Platform consumption is the steady state of platform integration. A product team with its own feature goals is using platform capabilities as part of its normal development work. A team spinning up a service on a platform-maintained service chassis, adopting an internal analytics service, storing data via a dedicated sensitive data store, or pulling components from a shared UI library are all examples of consumption.

The crucial distinction from migration work is ownership. In a consumption scenario, the product team owns the codebase being changed and drives the effort because it serves a broader product goal. In migration, the platform team is the one pushing changes into another team's code. Since the product team is motivated and in control, you might assume no cross-team collaboration is required. In practice, that is rarely the case.

Moving Away from Self-Service

Many platform teams aspire to build something as self-service as Stripe or Auth0 — a platform so well-documented that product engineers never need to contact the platform team. Most internal platforms are not there yet, especially early on. Poor docs, opaque errors, and confusing bugs drive product engineers to seek direct help from the platform team. This lands you squarely back in cross-team collaboration territory, governed by a different set of patterns.

Platform Team as Professional Services

Product teams often ask the platform team to simply write the consumption code for them. This might stem from confusion about how the platform works, from a desire to conserve product engineering effort, or from a misunderstanding about who is expected to do the work — common during shifts to a DevOps model where teams self-service their own infrastructure.

In this mode, the platform team works like an internal professional services group, integrating its product into customer systems on the customer's behalf. The workflow is familiar: the product team asks the platform team for help, typically by filing a ticket. The platform team then executes the request, often using either the Trusted Outsider or Internal Open Source collaboration patterns.

This frequently shows up in infrastructure work. Teams needing a new service spun up, an external endpoint registered on an API gateway, or configuration values updated will file a ticket with the platform team rather than make the changes themselves. For infrastructure, this habit predates self-service options; filing a ticket was the standard mechanism before such self-service existed.

White-Glove Onboarding

When a platform is young and its documentation is thin, a platform team might choose to onboard early adopters hands-on, working side-by-side with them to get started. This reduces the burden for pioneering product teams and gives the platform team invaluable observation of how early customers actually use the features. This white-glove model is usually the Tour of Duty pattern in action: platform engineers embed within a consuming team for a period to perform the integration work from the inside.

A Community of Practice

As a platform matures, the platform team can pull back from integration work into a consultative role. This surfaces as office hours where consuming teams can ask questions, or as platform representation in a product team's design and planning meetings. For large, feature-rich platforms, this eventually evolves into peer support via a Community of Practice: a slack channel or mailing list, dedicated meetings for help and show-and-tell, and possibly an annual practitioners meeting.

Investing in the Developer Experience

The amount of hands-on support required tracks closely to the maturity of the platform's developer experience. Early days demand significant platform-team energy, given the rough edges, evolving capabilities, and skeptical early adopters. Close work with product teams also gives a platform team a solid understanding of who its customers really are. But hands-on support does not scale. If broad adoption is the goal, a platform team must invest in making the developer experience self-serve or it will drown in implementation requests.

Platform users should never be left to guess at their support model. Product teams that received white-glove treatment during early adoption will reasonably expect the same treatment indefinitely — unless the expected support model is clearly and explicitly communicated.

When Product Teams Need the Platform to Change

The final collaboration phase is platform evolution. Here, a team using a platform discovers a gap in the platform’s capabilities and needs changes made to the platform itself. A team relying on a UI component library might need a new <Button> variant or additional configuration options for an existing one. A team using a service chassis might want richer observability or support for a new serialization format.

In this phase the roles are reversed from Platform Migration. The product team drives the work, but the changes must land in the platform team’s codebase. That reversal shapes which collaboration patterns are viable.

Filing a Ticket: A Slow Bottleneck

The most straightforward option is for the product team to file a ticket with the platform team requesting the change. This often leads to frustration. Product teams typically realize the platform is lacking something at the moment they need it, while platform teams are usually overloaded with inbound requests. The turnaround time for prioritization and delivery can be far too long, turning the platform team into a blocking bottleneck.

Moving Engineers to the Work

With enough warning, teams can close a platform gap by temporarily re-assigning engineers. The product team might send engineers on a Tour of Duty to the platform team, or a platform engineer could join the product team as an Embedded Expert.

Temporary moves carry a short-term productivity cost, but embedding an engineer can pay off over time by reducing cross-team communication overhead. An embedded engineer acts as an ambassador, smoothing communication and cutting down on games of telephone. That equation — fixed upfront cost, ongoing benefit — means this option is best reserved for larger platform improvements. Moving someone for a couple of weeks is more disruptive than helpful.

These assignments also demand a mature management structure so embedded engineers don’t feel isolated. With an Embedded Expert there’s an additional risk the engineer becomes a general “extra hand” doing platform consumption work rather than the platform improvements the product team actually needs.

Working on the Platform From Afar

If the platform team has embraced Internal Open Source, the product team can implement the needed changes directly. The platform team then shifts to a consultative role, offering design recommendations and reviewing PRs. After a few contributions, a product engineer might earn enough trust to be granted the commit bit and become a Trusted Outsider.

Many platform teams aspire to this state — customers implementing their own improvements sounds like a way to offload work. But internal open source mirrors external open source in a key way: supporting contributions takes a surprising amount of investment, and the vast majority of consumers never become meaningful contributors.

Platform teams should avoid opening their codebase to contributions without making thoughtful investments to support them. Proclaiming in an all-hands that the codebase is a shared resource, then repeatedly telling contributors “no, no, not like THAT!” creates deep frustration on all sides.

The Shift Toward Self-Service

Across Platform Migration, Consumption, and Evolution, no single form of collaboration is correct. The right approach depends on the phase of platform adoption and, critically, on the maturity of the interfaces between both teams and their systems. Expecting a new internal platform to integrate in the same hands-off, as-a-service mode as a mature external service invites disaster. Similarly, assuming a product team’s codebase is easy to modify when it has never accepted external contributions is unrealistic.

Team Topologies recommends starting with a focused, highly collaborative mode — patterns like Embedded Expert and Tour of Duty — to discover the right boundaries between teams and systems. Conway’s Law ensures those two are inseparable. But the authors also warn against staying in collaborative mode too long. A platform team should work hard to define its interfaces and move toward an as-a-service interaction model, using patterns like File a Ticket and Internal Open Source.

The collaborative modes simply don’t scale as platform adoption grows, and they impose a greater cognitive load on consuming teams. Moving to hands-off interaction styles lets product delivery teams spend more time on their own outcomes. Team Topologies frames this reduction of cognitive load as the defining purpose of a platform team.

Navigating this shift from highly collaborative to as-a-service is one of the biggest challenges a young platform team faces. Customers become comfortable with high-touch support. Building great documentation is hard. Saying no is hard.

Platform teams operating in collaborative mode should watch for scaling challenges. As the need for a more hands-off approach approaches, the team should start signaling the change to its customers early. An advance warning about how and why the interaction model will evolve gives product teams time to prepare and to adopt a more self-sufficient mental model of the platform.

The transition can be painful, but vacillating makes it worse. Product teams will appreciate clearly communicated rules of engagement. And removing the crutch of hands-on collaboration provides strong motivation to improve self-service interfaces and documentation. Conway’s Law applies here as well: redefining how teams integrate will put pressure on how their systems integrate.

A platform team succeeds on the back of collaboration with other teams, and that collaboration takes many forms. Choosing the right form requires understanding the type of platform work the other team is doing and being realistic about the current state of both teams and their systems. Getting this right drives adoption, but as adoption grows the team must be intentional about moving toward collaboration modes that are less hands-on, more scalable, and less cognitively demanding for its consumers.