Modern Operating Models: Product, Platform, Team
By the end of this module you will be able to:
- Explain the project-to-product shift and the funding consequence that makes it hard
- Apply the four team types and three interaction modes to a real organisation chart
- Define platform engineering and hold the portal apart from the platform
- Connect internal platform quality to the value an organisation gets from AI
- Use SFIA and the government capability framework to name the skills a model needs
A company gave away its internal tooling. The interesting part is what it could not give away.
Backstage began inside Spotify as an answer to a scaling problem. Engineers could not find the services that already existed, could not tell who owned them, and could not create a new one without learning a fresh set of conventions each time. The tool that came out of that work describes itself as an open source framework for building developer portals, powered by a centralised software catalogue. The Cloud Native Computing Foundation accepted it as a project on 8 September 2020 and moved it to incubating status on 15 March 2022.
Any organisation can now install the same software. Very few of them get the same result, and the reason is instructive. What Spotify donated was the door. The rooms behind the door, meaning the paved routes to create a service, the automated checks that satisfy security policy without a meeting, the defaults that make a compliant deployment the easiest deployment, were built by teams who were funded to keep building them. A catalogue that lists twelve manual processes is a tidier way to look at twelve manual processes.
The gap between the visible artefact and the operating model underneath it is where most of the disappointment lives. Three decisions do most of the work: what the money is attached to, where the team boundaries fall, and what the platform actually removes from the people using it.
If a portal is free to download, why do most organisations that install one still queue for the same things afterwards?
An operating model is a set of choices about funding, boundaries and capability. The first choice is the unit the money is attached to.
14.1 From project to product
Most public and private sector delivery still runs on project funding. A business case is approved for a defined scope, a team is assembled from permanent staff and suppliers, the scope is delivered, and the team is released. The around that pattern is well understood, and its governance artefacts are familiar: a milestone plan, a change control board, a benefits realisation review scheduled a year after go-live.
The attaches funding to a durable product line instead. The team persists. It runs discovery, builds, operates the result and keeps changing it, and the money is reviewed in the same cycle as everything else in the portfolio rather than being closed out. Transformed: Moving to the Product Operating Model, by Marty Cagan, Lea Hickman, Christian Idiodi, Chris Jones and Jon Moore, is the usual reference for what that way of working involves in practice.
Teams often try to adopt the practices without the funding change, and it fails in a predictable way. You can run continuous discovery, hold outcome-based reviews and write user stories instead of requirements, but if the budget line still expires at a fixed date then the incentive to declare completion arrives on schedule. Scope gets protected because scope is what the money was granted against. Anything learned late in delivery is a threat rather than information, because acting on it puts the closure date at risk.
The funding change also decides where evidence goes. Under project funding the benefits review is usually conducted by people who did not build the service, at a point when the team that could act on the findings no longer exists. Under product funding the same evidence lands in front of the group that can change the thing it describes. That is the difference worth arguing for in a finance conversation: not speed, and not agility as a value, but whether the organisation retains the ability to act on what it learns.
None of this makes projects wrong. A one-off migration with a genuine end state, such as decommissioning a data centre, is a project and should be funded as one. The failure mode is treating a service that will need continuous change for a decade as though it has a completion date, then being surprised that accumulates in the years when nobody is funded to look at it.
Funding a project against funding a product
Only the product column carries a return path: its connector runs from the foot note back up into the funding decision, under the label evidence returns to the team. Project funding has no such path, so it ends before the evidence that would sharpen the next decision arrives.
Moving from project funding to product funding changes who owns the work after go-live. A standing team keeps the product and keeps receiving evidence; a closed project sends its learning home with the contractors. Sources: svpg.com TRANSFORMED; GOV.UK Service Standard point 6.
Persistent funding buys a standing team. Section 14.2 asks what kind of team it should be, and how it is meant to interact with the teams around it.
14.2 Team shapes and interaction modes
, by Matthew Skelton and Manuel Pais and published by IT Revolution Press, gives a small vocabulary for organisational design. The first edition appeared in 2019 and a second edition followed in 2025. Its value is the constraint: four team types and three ways teams are allowed to interact, which is few enough that an exception stands out.
A stream-aligned team is aligned to a flow of work from a segment of the business domain. It is the default, and in a healthy organisation most teams are this type. An enabling team helps a stream-aligned team overcome obstacles and detects missing capabilities; it lends expertise and then leaves, which is what separates it from a permanent centre of excellence that becomes a queue. A complicated subsystem team owns a part where significant mathematics or deep technical expertise is needed, and is used sparingly because every one of them adds a boundary. A team provides a compelling internal product that accelerates delivery by stream-aligned teams.
The three interaction modes are collaboration, X-as-a-Service and facilitation. Collaboration means working together for a defined period to discover new things such as APIs, practices and technologies. It is expensive, and the time box is part of the definition. X-as-a-Service means one team provides and one team consumes something as a service, with a stable interface and little conversation. Facilitation means one team helps and mentors another team.
The practical test is to take a real organisation chart and try to label it. Every team gets one of the four types and every regular working relationship gets one of the three modes. Relationships that resist labelling are the finding. A pairing that has been collaborating for two years is either a single team that has not been merged or a service that has never been productised. A team that describes itself as a platform but appears in every project plan as a dependency is not providing X-as-a-Service; it is a bottleneck with a service catalogue.
This is the same argument as the boundary discussion from the integration module, applied to people. A team boundary is an interface, and interfaces need designing. If two teams must talk constantly to ship one change, the boundary is in the wrong place, and no amount of coordination tooling will fix a boundary drawn through the middle of a workflow.
“Put in place a multidisciplinary team that can create and operate the service in a sustainable way.”
GOV.UK Service Standard, point 6: Have a multidisciplinary team - Government Digital Service, last updated 29 January 2026
Two words in that sentence carry the weight. Create and operate, together, rules out the pattern where a build team hands to a run team; and sustainable rules out a team that exists only for the length of a procurement. The same page requires that where a service uses artificial intelligence, someone on or available to the team fully understands how it works and the impact of using it. That is a capability requirement expressed as a team composition rule, which is exactly how operating model decisions tend to surface in assurance.
Common misconception
“Team Topologies is an organisation chart with better names.”
It is a design constraint on relationships, not on boxes. The four types matter less than the rule that every regular interaction has to be one of three named modes. That rule is what surfaces the unowned dependencies: a relationship nobody can classify is almost always a boundary drawn in the wrong place, a service that was never productised, or a team doing two jobs. Rename the boxes and change nothing about how teams depend on each other, and the model has done no work at all.
Four team types and three interaction modes
Each interaction mode is drawn with the pairing that typically uses it, platform to stream-aligned for X-as-a-Service and enabling to stream-aligned for facilitation, so needing constant collaboration to ship a change means the boundary is wrong rather than the teams unhelpful.
Team Topologies names four team types and three interaction modes, so an organisation chart can be read as flow rather than hierarchy. Every arrow between teams is an interface that has to be designed. Source: teamtopologies.com key concepts.
One of the four team types has a discipline of its own. Section 14.3 looks at what a platform team is supposed to produce, and at the artefact people most often mistake for it.
14.3 Platform engineering and the internal developer platform
DORA describes as a sociotechnical discipline, sitting at the intersection of how teams interact and the technical work of automation, self-service and repeatability. The output is an: shared, high-quality tools and services that let delivery teams build, test and deploy securely and in a compliant way without needing deep expertise in the infrastructure underneath.
The organising idea is that the platform is an internal product and the developers are its customers. That has consequences most organisations skip. A product has a product manager, a roadmap driven by what users actually struggle with, and a measure of whether it is being adopted voluntarily. A platform run without those things becomes a mandated internal supplier, and mandated suppliers stop hearing about their own defects.
The route the platform offers is the : the supported way to do a common thing, with the templates, pipelines, checks and defaults already attached. Its power comes from being optional. A team can leave the path and take a different route, and accept that it now owns the parts the path was handling. Make the path compulsory and it becomes a standard, and standards get worked around rather than adopted.
This is where the portal and the platform separate. Backstage is a framework for building developer portals, and a portal is a catalogue and a front end: it shows what exists, who owns it, and starts a workflow. It is the door. The platform is what lies behind the door, which is the set of capabilities a team can request and receive without a ticket or a conversation. Installing a portal over a set of manual processes changes the appearance of the queue and nothing about its length. The symptom is easy to spot: teams can now find the form they used to email, and the lead time is unchanged.
Adoption of the pattern is now broad. DORA reports that by 2025, 90 per cent of organisations reported using an internal developer platform and 76 per cent had established dedicated platform teams. Breadth of adoption is not the same as quality of platform, and DORA's own finding on what users value most is a useful corrective: the platform capability most correlated with a positive user experience is giving clear feedback on the outcome of a task. Not breadth of features. Knowing whether the thing you asked for worked.
Common misconception
“We have deployed a developer portal, so we have a platform.”
A portal is a front end over whatever exists behind it. If the capabilities behind it are still requests that a human has to approve, the portal has made them easier to find and no faster to obtain. The test is not whether a catalogue exists; it is whether a delivery team can request a capability and receive it autonomously, without a ticket or a conversation. Where the answer is no, you have bought a door and installed it in front of the same corridor.
The platform stack and the portal that opens onto it
Beneath the four-layer stack the portal is drawn as a door, and its single labelled connector climbs to the golden path layer inside that stack rather than standing in for it. A catalogue bought before the supported route exists points at a route that is not there.
The platform is the supported route through infrastructure and shared services; the portal is the door onto it. Buying the door without building the route leaves the same queue behind a better front end. Source: dora.dev platform engineering capability.
Nine in ten organisations report having a platform. Section 14.4 covers the finding that makes platform quality, rather than platform existence, the number worth managing.
14.4 Platform quality and the value of AI
DORA published its 2025 research as the State of AI-assisted Software Development report. Its headline framing is that AI acts as an amplifier, magnifying an organisation's existing strengths and weaknesses. That is a claim about variance rather than about average benefit, and it explains why two organisations adopting the same assistant report opposite results.
The platform finding is the sharp version of the same point. DORA reports that when platform quality is high, the effect of AI adoption on organisational performance becomes strong and positive, and that when platform quality is low, the effect of AI adoption on organisational performance is negligible. The internal platform is not a nice-to-have alongside an AI programme. On this evidence it is the condition under which the AI programme returns anything at all.
The mechanism is not mysterious. An assistant that helps write code faster increases the rate at which changes arrive at whatever comes next. If what comes next is an automated pipeline with tests, policy checks and a one-step deployment, the extra changes flow through and the benefit is visible in such as change lead time. If what comes next is a manual review board that meets on Thursdays, the extra changes queue, and the organisation has bought a faster way to fill a waiting room.
There is a governance version of this argument that matters more for the operating model. Controls implemented in the golden path are implemented once, for every team that uses it. Controls implemented in guidance are implemented as many times as there are teams, inconsistently, and are evidenced by asking people. When an organisation starts using generative tooling at scale, the questions that follow are about provenance, about which model saw which data, and about whether a change can be traced to a human decision. A platform team can answer those questions by building the answer into the path. Left to guidance, each team invents its own answer and the assurance function discovers the variety later.
belongs in the same argument. The organisations that benefit from amplification are the ones that can see what changed and what happened next. Where that instrumentation is a platform capability rather than a per-team project, the evidence arrives in a comparable shape and the portfolio conversation becomes possible.
Funding, boundaries and platform all imply people who can do specific things. Section 14.5 covers the two frameworks used to name those capabilities without inventing a private vocabulary.
14.5 Naming the capabilities the model needs
An operating model on paper becomes a workforce plan the moment somebody has to recruit for it. Two naming systems are in common use in the United Kingdom, and they answer different questions.
, the Skills Framework for the Information Age, describes digital and technology skills against seven levels of responsibility characterised by generic attributes. SFIA 9 was published on 30 October 2024, and its changes include 26 additional skills, 10 renamed skills and 5 restructured or split. Because it is a shared vocabulary rather than an in-house grading scheme, it lets an organisation state what a role requires in terms a supplier, a recruiter and a pay review body all recognise.
The Government Digital and Data Profession Capability Framework covers the same ground for the UK public sector. It was renamed from the Digital, Data and Technology Profession Capability Framework on 1 December 2023, and it is maintained by the Government Digital Service. It describes roles grouped into families that include architecture, data, IT operations, product and delivery, quality assurance testing, software development and user-centred design, and it assigns each skill in a role to one of four levels: awareness, working, practitioner or expert.
The two are complementary in practice. The government framework is the better fit for writing a role profile in a department because it uses the job titles that exist there. SFIA is the better fit for comparison across organisations and for contract schedules, because it is not tied to one employer's titles. Neither is a substitute for deciding the operating model first. A capability framework tells you what to call the gap; it does not tell you whether you need a platform team.
The failure worth naming here is the reorganisation that renames roles and changes nothing else. New titles are drawn from a framework, an organisation chart is redrawn, and the funding unit, the team boundaries and the platform capabilities are left as they were. Six months later the same dependencies are causing the same delays under different labels. Capability naming is the last step of an operating model change, not a substitute for the first four.
The three decisions interlock. Persistent funding is what allows a team to own a boundary for long enough to make it stable. A stable boundary is what allows a platform to be offered as a service rather than negotiated per project. And a platform good enough to be adopted voluntarily is what turns new tooling into throughput instead of queue.
A department reorganises into stream-aligned teams and stands up a platform team. Eighteen months later the platform team appears as a named dependency in every stream-aligned team's delivery plan, and each request to it is scheduled through a joint planning session. Which diagnosis fits, and what does it imply?
An organisation with a low-quality internal platform, where most environment and deployment requests still need human approval, is about to fund a large AI coding assistant rollout on the argument that it will shorten delivery. What does the DORA evidence suggest about that plan?
A service that will need continuous change for the next decade is funded as a fixed-scope project with a closure date. Discovery in month nine produces strong evidence that a core assumption is wrong. Which consequence follows most directly from the funding model, rather than from the team's behaviour?
Core distinctions
- The project-to-product shift is a funding decision before it is a delivery practice. Money attached to a scope with an expiry date makes late learning a threat; money attached to a persistent product line puts the evidence in front of a team that can still act on it.
- Team Topologies constrains relationships, not just boxes: four team types (stream-aligned, enabling, complicated subsystem, platform) and three interaction modes (collaboration, X-as-a-Service, facilitation). A relationship you cannot classify is the finding.
- A platform team interacting through standing collaboration rather than X-as-a-Service has not productised its capability. Adding headcount scales the negotiation instead of removing it.
- The portal is the door; the platform is what lies behind it. The test is whether a team can request a capability and receive it without a ticket or a conversation, not whether a catalogue exists.
- DORA reports that AI adoption has a strong and positive effect on organisational performance where platform quality is high, and a negligible effect where it is low. That makes platform work a precondition for AI value rather than a parallel track.
- SFIA 9, published on 30 October 2024, and the Government Digital and Data Profession Capability Framework name capabilities in shared vocabulary. Naming skills is the last step of an operating model change, not a replacement for the funding and boundary decisions.
Standards and sources cited in this module
teamtopologies.com
Primary source for the four fundamental team types and the three team interaction modes quoted in Section 14.2, including the definitions used in the team-shapes figure.
Team Topologies, Skelton and Pais
IT Revolution Press, first edition 2019, second edition 2025
Publisher page confirming authorship and editions for the book referenced in Section 14.2.
DORA capability: platform engineering
dora.dev
Source for the definition of platform engineering, the internal developer platform and golden paths, the 2025 adoption figures, and the finding on platform quality moderating the effect of AI adoption used in Sections 14.3 and 14.4.
DORA, State of AI-assisted Software Development 2025
dora.dev
Source for the 2025 report title and its amplifier framing, cited at the start of Section 14.4.
backstage.io
Source for Backstage as an open source framework for building developer portals, used in the opening case and in the portal versus platform argument in Section 14.3.
Backstage project page, Cloud Native Computing Foundation
cncf.io
Source for the CNCF acceptance date of 8 September 2020 and the move to incubating on 15 March 2022, both stated in the opening case.
GOV.UK Service Standard, point 6: Have a multidisciplinary team
Government Digital Service
Quoted in Section 14.2 for the requirement that a team be able to create and operate a service sustainably, and for the expectation about AI understanding within the team.
sfia-online.org
Source for the seven levels of responsibility and the SFIA 9 change summary of 26 additional, 10 renamed and 5 restructured skills cited in Section 14.5.
sfia-online.org
Source for the publication date of 30 October 2024 stated in Section 14.5 and in the takeaways.
Government Digital and Data Profession Capability Framework
Government Digital Service
Source for the rename from the DDaT Profession Capability Framework on 1 December 2023, the role families, and the four proficiency levels used in Section 14.5.
TRANSFORMED: Moving to the Product Operating Model
Silicon Valley Product Group
Publisher page for the book named in Section 14.1 as the reference for what the product operating model involves in practice, and for its authorship.
An operating model decides who may act and how quickly. The next module turns to what those actors are permitted to do with data that belongs to somebody else, and to the lawful bases, trust frameworks and standards that govern sharing it.
Module 18 of 28 · Strategy, trust and sector