Platform Timing Is a Strategic Decision
There is a pattern I keep encountering in modernization engagements. The starting conditions are usually good ones. The organization has read Team Topologies, taken it seriously, and used it to structure the modernization. The team types are in place. Stream-aligned teams own clear slices of the business domain, a platform team or two has been set up, an enabling team is helping spread practices. The interaction modes are explicit. People talk about collaboration and X-as-a-Service in meetings and mostly mean the right things by them. None of this is cargo culting. The thinking happened.
And yet, eighteen months in, the platform team has shipped its v1, the stream-aligned teams have been asked to adopt it, and very few of them are actually using it. The platform team is frustrated, because they built what was asked for. The stream-aligned teams are frustrated too, because they are being pushed toward something that does not quite fit their problem, and the parts that would fit are not there yet. Leadership asks whether the platform team needs more headcount, or whether stream-aligned teams need stronger incentives to adopt. Both questions miss what has actually happened.
The question of when
What has happened is that the platform was built before the organization had a clear enough picture of which capabilities really needed to be shared. The shape that v1 committed to reflects what the platform team could see from where they were sitting at the time, which was, almost by definition, not where the stream-aligned teams were sitting when their real needs emerged. The team did not fail. The team types and interaction modes were not wrong either. The timing was.
This is not a critique of platform engineering or of Team Topologies. Done well, platform engineering is one of the most leveraged organizational moves available. It is how you give stream-aligned teams flow without dissolving into chaos. The question this post is interested in is narrower and, I think, underdiscussed: how do you know whether the platform you are about to build is being built at the right moment, and what is the cost of getting that wrong?
Why platforms feel safe to start early
Before getting into signals and tradeoffs, it is worth being honest about why premature platforms happen as often as they do, even in organizations that are doing the rest of their modernization work carefully. The reasons are not foolish. They are rational responses to real pressures, and recognizing them is part of the work.
Platforms feel like architecture maturity. A platform team is legible evidence that the organization is doing modern engineering, and senior leadership wants that evidence. Platforms are also easier to fund than diffuse improvements. A "build once, reuse many times" narrative fits how budgets are usually justified, while "give every stream-aligned team some breathing room" does not. Ambitious staff engineers need scope, and a platform initiative offers exactly that kind of scope. The Team Topologies diagram has a labeled box for the platform team, and labeled boxes create a pull toward filling them, especially when the rest of the diagram is already populated. The vocabulary itself signals progress: adopting "platform engineering" as a term feels close to adopting the practice, and that closeness is comfortable.
None of these pulls are wrong. They are the conditions under which platform initiatives get funded and staffed and started. What they are not, however, is evidence that the platform is ready to be built. They are evidence that the organization is ready to want a platform, which is a different thing from having earned one. That is the distinction the rest of this post is about.
Four signals that the timing is wrong
Four patterns come up often enough that I treat them as questions to ask before committing to a platform's shape.
Variance still exceeds repetition. The first signal is that stream-aligned teams are still figuring out what they need. If you ask three of them to describe their top pain points, and the answers do not overlap on at least three concrete items, the platform does not yet have enough shared ground to stand on. You can still build something, but what you build will be a guess about which pain points will eventually become common, and guesses about the future shape of the work tend to age badly. The signal is not that you should wait. The signal is that the discovery work is not finished, and the platform team is in a poor position to do that discovery from where they are sitting.
The underlying capability has not stabilized. The second signal comes from looking at the capability itself, ideally with a Wardley map in hand. If the thing you would platformatize is still moving rapidly, or there are no commodity providers in the market, or the practices around it are changing every six months, then any platform you build is locking in today's understanding of a moving target. AI-assisted development tooling in 2026 is the obvious example. The shape of what good looks like there is still shifting fast enough that a platform built around it now will need to be substantially rebuilt within a year or two. That is not necessarily a reason to avoid investing, but it is a reason to invest in a form that can be retired cheaply.
The bundled capabilities do not share a purpose. The third signal is the one most readers of this blog will recognize, because it connects directly to what makes a Bounded Context work. The capabilities you are bundling into the platform should be held together by a shared job to be done, not by the fact that they all happen to involve, say, "data" or "messaging" or "deployment." When the grouping is technical rather than purposeful, the platform ends up with the same low-cohesion problem we already know how to recognize at the code level, just at a larger scale. Stream-aligned teams will use the parts of it that fit their context and route around the rest. The signal is that the platform's scope was drawn around technical similarity rather than around a coherent purpose.
Nobody is pulling for it. The fourth signal is the simplest and the most often ignored. Real platforms have internal customers asking for things, with specific use cases and named contacts. Premature platforms have an architecture group anticipating things on behalf of customers it has not yet talked to. The test is whether the platform team can name three stream-aligned teams that would adopt v1 today, with concrete use cases. If the honest answer is no, the platform is being pushed rather than pulled. Push platforms tend to become shelfware with a budget, regardless of how well they are built.
When more than one of these questions makes you uncomfortable, the platform's job has not yet been discovered clearly enough to commit to its shape. That does not mean nothing should be done. It means the next move should be smaller and more reversible than building the platform itself, which is what the next section is about.
Habitual practices before the platform
If the signals say the platform's job has not been discovered clearly enough, the useful response is not to wait. It is to engage in a form that is smaller than building a platform team and a roadmap. The point is to keep learning while keeping commitments reversible. There are five habitual practices I find useful here, and they can run in parallel.
Discover before you build. The platform team's first deliverable should not be a platform. It should be a much clearer picture of which capabilities the stream-aligned teams actually share, where their cognitive load really lives, and which of their pain points are stable enough to be worth solving for everyone. There are plenty of techniques to produce that picture, and most readers of this blog will know several of them. Five Whys to dig into where the actual friction sits rather than where it appears. Six Thinking Hats to surface the same problem from operational, strategic, and risk angles. The Analyst agent in something like BMAD to interrogate assumptions before they harden into design. Event Storming or Domain Storytelling sessions that bring stream-aligned teams together to externalize their workflows. Cognitive load assessments adapted from the Team Topologies guidance. The specific technique matters less than the commitment. The platform team's first quarter should produce evidence about the problem, not artifacts that prejudge the solution.
Embed before you abstract. The platform team's worst position is the one where they are guessing at stream-aligned teams' needs from a distance. The fastest way out of that position is to put platform-minded engineers temporarily into stream-aligned teams, working on the actual stream-aligned work. They will see the friction firsthand. They will notice which workarounds are stable enough to generalize and which are still in flux. They will come back with patterns that were discovered in the work rather than imagined on a whiteboard. This is uncomfortable for organizations that have already drawn the boxes on the Team Topologies diagram, because it temporarily blurs them. But the blurring is the point. The boxes are easier to draw correctly after the discovery work than before it.
Use Collaboration mode before X-as-a-Service. Team Topologies describes three interaction modes between teams, and the progression between them matters as much as the modes themselves. Collaboration mode means two teams working closely together on a shared problem, with a clear purpose and a clear time limit. X-as-a-Service mode means one team offering a stable, well-defined capability that the other team consumes with minimal coordination. The premature platform mistake, in these terms, is to skip Collaboration and jump straight to X-as-a-Service. That assumes the capability is already stable enough to offer as a service, when in fact the platform team and the stream-aligned teams have not yet done the close exploratory work needed to find out. Collaboration first, between the platform team and one or two willing stream-aligned teams, on a defined problem with a time limit. X-as-a-Service later, once that close exploratory work has produced something stable enough to offer as a service to the rest of the organization.
Start thinner than feels comfortable. When you do begin building shared things, the principle that holds up best is the one Skelton and Pais describe as the Thinnest Viable Platform. The platform should be exactly thick enough to relieve real cognitive load on stream-aligned teams, and no thicker. The temptation at the start is to scope the first version generously, so that it covers enough ground to feel like a real platform. That temptation is the one to resist. Every feature included without a stream-aligned team pulling for it is a feature that has to be maintained, documented, supported, and eventually deprecated. Starting thin keeps the platform close to its users while there is still room to learn from them. Starting thick commits the shape before that learning has happened.
Duplicate on purpose, then extract. Sandi Metz's line that duplication is far cheaper than the wrong abstraction is usually applied to code, but it works at least as well at the organizational level. If two stream-aligned teams are solving a similar problem in slightly different ways, the temptation is to extract a shared solution immediately. The cost of that move is locking in an abstraction before you understand which differences between the two solutions were accidental and which were essential to each team's context. Letting the duplication run for another quarter, or another two, is not wasted effort. It is the evidence-gathering that lets you eventually extract something that fits both contexts rather than neither. Premature extraction at the platform level is the same mistake as premature abstraction at the code level, just with more meetings.
These five habitual practices share a property. None of them requires committing to a platform team's headcount, charter, or roadmap. They all leave you with information that the alternative, building the platform up front, does not produce. And they all keep you in dialogue with the stream-aligned teams whose work the platform is supposed to support, which is the conversation the premature-platform pattern most often loses.
Platform timing as a portfolio decision
Platform timing is, in the end, a question of capital allocation. You have a finite amount of organizational attention and engineering capacity. The question is not whether platforms are valuable, because they obviously can be. The question is whether building one now is the best use of those resources, against the alternative of leaving them in the stream-aligned teams and waiting for more evidence.
When I work with leadership groups on this, three questions tend to be more useful than any framework.
What is the actual evidence of demand? The wrong version of this question is "would stream-aligned teams use a platform if we built one." The answer to that is almost always yes, because anything that promises to remove friction sounds attractive in the abstract. The right version is more specific. Who is asking, by name. What are they asking for, in their own words rather than translated through an architecture group. What are they doing today instead, and how much pain is that workaround actually causing them. If the answers are thin, the demand signal is thin, regardless of how plausible the platform idea sounds in a slide deck.
What does it cost to be wrong? A premature platform is not free to retire. The artifacts can be deprecated, but the org structure that grew around them cannot be unwound as easily. A platform team with headcount, OKRs, and a leadership chain has political weight. It is harder to disband than to start. And the longer it has been running, the more its existence shapes assumptions about how stream-aligned teams should work, which means winding it down disrupts the teams whose work the platform was supposed to support. The sunk effort is the smaller cost. The larger one is the difficulty of changing direction once the organization has reorganized itself around the wrong answer.
What is the value of waiting? Six more months of stream-aligned teams solving problems independently often produces the clarity that a platform team would have spent those six months guessing at. That clarity is not a delay. It is what lets the eventual platform be the right one. And waiting earns it. The platform team would otherwise spend the same six months guessing.
There are situations where starting early genuinely is the right call, and a strategic argument for timing is incomplete without naming them. Regulatory and security baselines often need to be in place before stream-aligned teams have converged on their patterns, because the cost of inconsistency is borne by the organization rather than by the teams themselves. The same is true for compliance golden paths in heavily regulated industries, where letting each stream-aligned team interpret the rules independently produces audit risk regardless of how well each one does it. Reliability standardization sometimes falls into this category as well, particularly when a single incident affecting one team would damage the whole organization's reputation. The pattern that unifies these cases is that the cost of getting it wrong is paid by the whole organization, not by the team that varied. When that is true, the discovery work shifts, because the relevant question is no longer "what do the stream-aligned teams want" but "what does the organization need to be true of every stream-aligned team." Those are different conversations, and they sometimes justify a platform commitment earlier than pull alone would suggest.
The portfolio logic applies in the other direction too, which is worth saying explicitly because it is where the procurement question lives. A premature internal platform and a premature vendor-built capability are mirror images of the same mistake. Both commit to a shape before the underlying capability is well enough understood to commit. The internal version locks in your architecture group's current understanding. The vendor version locks in a supplier's bet about what your capability should look like, with the added complication that the bet is now in a contract. In both cases, the strategic move is the same. Stay in dialogue with the actual users longer. Keep the commitment as small as possible until the evidence sharpens. The decision is not whether to build or buy. It is when, and how much, to commit.
The work of earning a platform
The pattern this post opened with, the platform team eighteen months in with thin adoption and frustrated stakeholders on both sides, is rarely a failure of skill. It is a failure of timing. The teams in those engagements have usually done the modernization work carefully, used Team Topologies thoughtfully, and built what they were asked to build. What they did not do, and what no framework directly told them to do, was treat the question of when as a strategic decision in its own right. Platforms are powerful when the organization has earned them, by understanding clearly enough what it is building and for whom. The work of earning them is unglamorous, slower than starting, and easy to skip. Doing it anyway is what separates platforms that get adopted from platforms that get routed around.
If your organization is wrestling with platform timing right now, I help leadership teams and platform groups work through exactly this kind of question, often in workshop form and sometimes as a longer engagement. If the pattern in this post is familiar, I would be glad to talk. You can reach me via info@michael-ploed.com or the contact page.
Related Blog Posts:
Michael Plöd Technical Platforms Are Not Enough: The Crucial Role of Business Domain-Centric Platforms - https://www.michael-ploed.com/blog/technical-platforms-are-not-enough-the-crucial-role-of-business-domain-centric-platforms
Michael Plöd Staffing and Procurement for Fast Flow - https://www.michael-ploed.com/blog/staffing-and-procurement-for-fast-flow
References
Skelton, M. and Pais, M.Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution, 2019. Referenced throughout for team types, interaction modes (Collaboration and X-as-a-Service), and the Thinnest Viable Platform concept. https://teamtopologies.com
Metz, S. "The Wrong Abstraction." Blog post, 11 January 2016. The source for the principle that duplication is far cheaper than the wrong abstraction. https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction
Wardley, S.Wardley Maps: Topographical Intelligence in Business. Available online, ongoing publication on Medium. Referenced in the discussion of capability stabilization. https://medium.com/wardleymaps
Ohno, T.Toyota Production System: Beyond Large-Scale Production. Productivity Press, 1988. The source for the Five Whys technique, originally developed by Sakichi Toyoda and adopted as part of the Toyota Production System.
de Bono, E.Six Thinking Hats. Little, Brown and Company, 1985.
BMAD Method. Breakthrough Method for Agile AI-Driven Development. Open-source framework on GitHub. The Analyst agent is referenced in the discovery section. https://github.com/bmad-code-org/BMAD-METHOD
Brandolini, A.Introducing EventStorming: An Act of Deliberate Collective Learning. Leanpub, ongoing. https://leanpub.com/introducing_eventstorming
Hofer, S. and Schwentner, H.Domain Storytelling: A Collaborative Modeling Method. Addison-Wesley, 2021.
