A team owns subscription changes in the customer portal. A modest improvement requires knowledge of billing, deployments, certificates and monitoring. Management has delegated authority, but delivery still depends on a few people who each remember one part of the system. Calling the team autonomous does not make the next change any easier.
Team Topologies offers a way to design responsibilities and interactions together. It is not a ready-made organisation chart. Its useful question is which complexity the team should understand itself, which capability it should consume, and where temporary help would make a lasting difference.
Authority does not create unlimited attention
Cognitive load is the knowledge and relationships a team must keep in mind to work safely. It is not a judgement of anyone's intelligence. If an ordinary release requires recalling the quirks of several unrelated platforms, there is less attention available for what a plan change means to the customer.
The authors' modeling guidance treats this load as an input to team design. For our example, separate product rules, incidental technical difficulty and missing knowledge. Moving an expert between urgent projects may finish today's task without removing tomorrow's dependency.
Ask what stopped the last release. Was the pricing rule unclear, was the team unable to investigate a request, or did it lack permission to deploy? Training does not grant decision rights. A new reporting line does not simplify a calculation. These are different problems, even when they appear in the same delivery queue.
Four purposes, not four departments to create
The Team Topologies model distinguishes stream-aligned teams delivering a flow of work, enabling teams developing others' capabilities, complicated-subsystem teams handling specialised complexity, and platform teams providing internal capabilities. These are purposes rather than levels in a hierarchy.
For subscription changes, the journey team needs to understand product restrictions. A platform can supply a supported deployment and diagnostic path. An observability specialist can help the team learn it. A genuinely demanding calculation might justify specialist ownership, but the existence of a billing service does not automatically make it a complicated subsystem.
Every separation also creates an interface. If adding a straightforward field now requires another team's approval, the split may have made work harder. First consider a better interface or knowledge transfer. A small organisation need not create all four team types; several focused working sessions may solve its immediate problem.
Be particularly careful with a subsystem only one specialist can maintain. A new boundary does not create backup expertise. Consumers still need response expectations and a way to continue when that person is away. Training colleagues or simplifying the component may be the better first move; otherwise one team's relief becomes everybody else's queue.
Agree on how the teams will interact
The model names collaboration, X-as-a-Service and facilitation as interaction modes. Collaboration is time-bounded joint discovery; a service provides an established capability; facilitation develops another team's ability. The interaction-modeling guide explains how these arrangements can evolve.
Suppose portal and billing teams work together on mid-period subscription changes. Close cooperation makes sense while important questions remain unanswered. Define the intended result: agreed examples, an interface and a way to verify a correction. After that discovery, an ordinary portal adjustment should not reopen a joint project every time.
Consuming a service means more than calling an API. The consumer needs supported limits, diagnostics and a route for problems. If every operation still requires a supplier's engineer to perform it manually, the dependency has merely acquired a ticketing interface.
Facilitation has a different completion test. A diagnostic specialist should help the team investigate a delay itself. If the specialist performs every investigation indefinitely, that is continuing operational support. It may be necessary, but it needs capacity and an explicit commitment rather than the label of temporary coaching.
The customer outcome still crosses the boundary
After changing plans, the customer sees a new price while billing still applies the old terms. “Our team finished its part” cannot resolve that discrepancy. Someone must follow the journey to completion, define acceptable intermediate states and coordinate recovery.
A shared service has competing priorities and finite capacity. Consumers need a predictable way to request changes and resolve conflicts. When every request is urgent, the decision belongs to an agreed priority owner, not the engineer receiving the loudest message. A team-type label does not create that mechanism.
Continuity matters as well. Regularly moving people between assignments forces knowledge and agreements to be reconstructed. Stable responsibility should not prohibit useful conversations, though: a direct discussion of a disputed calculation can avoid several rounds of incomplete specifications.
Try one transition before reorganising the company
Choose a recurring dependency and describe its present state honestly. Perhaps the portal team cannot investigate billing errors. Agree on assistance, reserve time on both sides and specify what the receiving team must eventually do without its helper. Do not present the desired arrangement as already achieved.
Then follow the next plan change and a safe failure exercise. Track waiting, rework and mandatory involvement from other teams. DORA's loosely coupled teams guidance uses independent testing and deployment as practical signals. Renaming departments provides no comparable evidence.
Include the helpers' workload in the review. If the portal moves faster only because platform engineers quietly work evenings, the company has transferred the cost. Use the remaining friction to choose the next action: improve the service, reduce the team's scope or continue coaching. An organisation-wide reshuffle is not a prerequisite.