How to create direction when demand, ownership, and the right abstraction are still unclear
Platform teams are often asked to solve problems before the organization agrees on what the problem is.
A product team usually starts with a user journey, a market need, or a measurable product outcome. A platform team frequently starts with fragments:
– several teams complain about deployment friction
– security wants stronger controls
– finance wants lower cloud cost
– engineering leaders want standardization
– developers want fewer tickets
– operations wants safer changes
– no one agrees on which problem should be solved first
This is not a temporary discovery phase before “real delivery” begins. It is the normal operating environment of platform work.
The leadership challenge is not to remove all uncertainty. It is to create enough shared direction that teams can make progress without pretending the future is already known.
The core principle of this article is:
A platform leader should centralize complexity without centralizing every decision.
That distinction separates a platform that accelerates teams from a platform organization that becomes another approval layer.
1. WHY PLATFORM AMBIGUITY IS DIFFERENT
Ambiguity in platform work is rarely just missing requirements. It normally appears in three forms at the same time.
Demand ambiguity asks:
– Which teams genuinely experience the problem?
– Is the pain frequent or merely visible?
– Would teams adopt a common solution?
– Which parts of the problem are shared?
Solution ambiguity asks:
– What should be standardized?
– What should remain flexible?
– Is the right interface an API, workflow, template, policy, library, or service?
– How much abstraction is enough?
Mandate ambiguity asks:
– What does the platform own?
– What should it enable?
– What should it govern?
– What should remain with stream-aligned teams?
– Who pays the migration cost?
Figure 1. Platform leaders manage demand ambiguity, solution ambiguity, and mandate ambiguity at the same time.
The important insight is that these ambiguities interact.
A weak mandate can make a technically sound platform impossible to adopt. A broad mandate can produce premature standardization. Strong demand from one large team can be mistaken for a universal need. A reusable abstraction can look attractive while moving complexity into every consumer.
Platform leadership therefore begins by separating the uncertainties rather than treating them as one vague problem.
2. THE LEADER IS NOT THE PERSON WITH THE MOST ANSWERS
In ambiguous environments, teams often look to the leader for certainty.
The leader may respond by producing:
– a detailed roadmap
– a target architecture
– a platform capability catalogue
– a migration deadline
– a list of approved technologies
These artifacts can create the appearance of clarity. They can also lock the organization into an untested theory.
The more useful leadership role is to design a decision system.
A decision system defines:
– what outcome matters
– what evidence is missing
– which decisions are reversible
– which constraints are non-negotiable
– who can decide locally
– when a decision must be revisited
The leader’s value comes from improving the quality and speed of decisions, not from personally making all of them.
A practical question is:
What must be true for this platform investment to be worth scaling?
Possible answers include:
– a common workflow exists across at least five teams
– the platform reduces time to first production deployment
– adoption occurs without executive enforcement
– support demand per onboarded team declines
– a security control becomes easier to use than to bypass
These are evidence thresholds. They are more useful than declaring the platform strategic.
3. DEFINE THE PLATFORM PROMISE BEFORE THE PLATFORM ROADMAP
A roadmap lists intended work. A platform promise explains why internal users should trust and adopt the platform.
A useful platform promise answers four questions.
Who is it for?
For example:
– teams deploying customer-facing services
– data teams publishing governed datasets
– AI teams running production inference
– engineers creating event-driven consumers
Which struggle does it remove?
Examples:
– environment setup takes weeks
– every team implements authentication differently
– production readiness depends on tribal knowledge
– compliance evidence is assembled manually
– operational defaults are unsafe.
What does the platform guarantee?
Examples:
– a service can reach production through a supported path
– security controls are built into the workflow
– standard observability is available by default
– teams retain defined extension points
– common failures have documented recovery paths
What does the platform not own?
This is often the most important part.
The platform may own:
– deployment workflows
– identity integration
– policy enforcement
– service templates
It may explicitly not own:
– product-domain logic
– every runtime technology
– application-level availability decisions
– every migration task
A clear platform promise prevents the platform backlog from becoming a collection of unrelated organizational pain.
4. A PAVED ROAD IS A SUPPORT CONTRACT
A paved road is commonly described as a recommended way to build or operate software.
The deeper interpretation is that it is a support contract.
The platform team is saying:
– this path is actively maintained
– this path has known operational behaviour
– this path has security and compliance support
– this path receives documentation and migration help
– failures on this path can be diagnosed
A paved road should not mean:
– every exception is forbidden
– the platform team approves every change
– one abstraction must fit every workload
– unsupported experimentation is punished
The goal is to make the common case easier, safer, and faster than inventing a custom path.
This is why platform adoption cannot be created only through governance. Teams adopt platforms when the supported path has better economics than the alternative.
5. BUILD AN OPERATING STACK, NOT A TOOL CATALOGUE
Platform teams frequently organize their work by tools:
– Kubernetes
– Terraform
– CI/CD
– secrets
– service catalogue
– observability
– developer portal
Internal users do not experience the platform as a list of tools. They experience an end-to-end journey.
For example:
“I need to create, secure, deploy, observe, and operate a service.”
A stronger platform operating stack connects five layers.
Outcome intent:
Which user or team outcome should improve?
Guardrails:
Which security, reliability, cost, and compliance constraints apply?
Paved roads:
Which common workflows should be made repeatable?
Self-service products:
Which APIs, templates, portals, and automation expose the capability?
Feedback and adoption:
How will the team know whether the capability reduced friction?
Figure 2. The platform operating stack connects strategic intent to guardrails, paved roads, self-service products, and adoption evidence.
This structure exposes a common failure.
Some platform teams build the self-service layer before agreeing on the outcome or guardrails. The result is a polished interface over an unclear product.
Others define guardrails but never convert them into usable workflows. The result is governance without acceleration.
The stack must remain connected end to end.
6. MANAGE A PORTFOLIO OF BETS, NOT A FIXED ROADMAP
Platform roadmaps are unusually vulnerable to false certainty because demand is indirect.
A product feature can be tested with external users. Platform value often depends on changes in the behaviour of other engineering teams. Adoption may require migration work, trust, documentation, support, and organizational permission.
Treat major platform initiatives as bets.
Each bet should include:
– the user segment
– the friction being removed
– the proposed mechanism
– the expected behaviour change
– the evidence threshold
– the review date
– the stop or revise criteria
Example:
Bet:
A self-service service template will reduce time to first production deployment for new backend services.
Expected signals:
– teams complete setup without platform tickets
– median setup time falls
– production-readiness defects decline
– teams keep using the template after the pilot
Stop or revise criteria:
– teams fork the template immediately
– exceptions dominate the workflow
– support demand grows with adoption
– teams continue using custom pipelines despite executive encouragement
This approach preserves option value. The organization can invest more when evidence improves and stop when the theory is wrong.
7. MAKE REVERSIBILITY EXPLICIT
Ambiguity becomes dangerous when reversible and irreversible decisions are treated the same way.
Reversible decisions may include:
– documentation structure
– internal API naming
– one pilot workflow
– portal navigation
– default dashboard layout
Harder-to-reverse decisions may include:
– identity boundaries
– tenancy model
– data ownership
– regional architecture
– event contract ownership
– mandatory runtime standards
For reversible decisions, speed matters more than consensus.
For hard-to-reverse decisions, the team needs stronger evidence, wider review, and explicit assumptions.
A useful decision record includes:
– decision
– assumptions
– alternatives rejected
– evidence available
– reversibility
– trigger for review
The goal is not perfect documentation. It is preventing temporary assumptions from silently becoming permanent architecture.
8. LEAD THROUGH CONSTRAINTS, NOT INSTRUCTIONS
In ambiguity, detailed instructions become stale quickly.
Constraints remain useful longer.
A platform leader can define:
– data must remain within an approved region
– every service must expose defined operational signals
– privileged access must be short-lived and auditable
– business-critical workloads cannot share an unbounded failure domain
– teams must be able to exit the platform through documented interfaces
Within these constraints, teams can discover implementation details.
This is an important leadership pattern:
Use intent to align.
Use guardrails to bound.
Use evidence to adapt.
Do not use a central plan to decide every local choice.
9. PLATFORM DISCOVERY IS CONTINUOUS
Platform discovery is often reduced to asking teams what tooling they want.
That produces a request queue.
Better discovery studies work, not preferences.
Observe:
– where engineers wait
– where they copy old implementations
– where approvals accumulate
– where incidents require specialists
– where teams create local workarounds
– where migrations repeatedly stall
– where support questions reveal missing product affordances.
A request such as “we need a developer portal” is not the problem.
The underlying struggle may be:
– engineers cannot discover ownership
– onboarding requires knowledge spread across several systems;
– production readiness has no visible status
– support routes are unclear.
Different struggles imply different solutions.
Platform leaders should regularly review support tickets, onboarding sessions, incident timelines, migration failures, and product-team workarounds. These sources contain more reliable evidence than a feature-voting exercise.
10. WATCH FOR ADOPTION DEBT
Technical debt is widely understood. Platform teams also accumulate adoption debt.
Adoption debt appears when a capability exists but cannot be used effectively because of:
– poor documentation
– weak discoverability
– missing migration support
– unclear ownership
– inconsistent behaviour
– insufficient trust
– lack of extension points
– no exit path.
A platform can be technically complete while operationally unusable.
This is why adoption is not a launch event. It is a continuing product obligation.
A mature platform backlog includes:
– onboarding improvements
– migration tooling
– diagnostic capabilities
– documentation
– compatibility work
– deprecation support
– usage analytics
These are not secondary activities. They are part of the platform product.
11. MEASURE LEVERAGE, NOT OUTPUT
Platform teams can easily report output:
– templates created
– pipelines migrated
– APIs launched
– documentation pages published
– tools standardized
These measures say little about whether the platform improved engineering work.
More useful measures include:
– time to first successful use
– task completion without assistance
– adoption by the intended segment
– repeated usage
– support demand per active team
– change lead time for platform users
– reliability of the paved road
– cognitive load reported by teams
– percentage of exceptions required
Team Topologies frames platform teams as providers of services that reduce complexity for stream-aligned teams. CNCF’s platform guidance similarly emphasizes value, adoption, and measurable progress rather than the existence of tooling.[1][2]
A useful platform metric should answer:
What changed for the team using the platform?
Not:
What did the platform team ship?
12. CREATE A LEARNING CADENCE
Ambiguity becomes manageable when learning has a rhythm.
A practical cadence may include:
Weekly friction review:
What new evidence appeared in support requests, incidents, onboarding, or adoption?
Biweekly platform discovery:
Which internal users were observed? Which assumptions changed?
Monthly bet review:
Which initiatives should scale, revise, pause, or stop?
Quarterly platform boundary review:
Which responsibilities have moved? Which interfaces are becoming unstable? Which capabilities should be handed to another team?
Figure 3. Platform teams move from friction to a thin bet, adoption evidence, and an explicit scale-or-stop decision.
The key is that the review must be able to change the roadmap.
A learning ceremony that cannot alter investment is only reporting.
13. ALIGN EXECUTIVES WITHOUT SELLING FALSE CERTAINTY
Executives often need commitment dates, investment plans, and target outcomes.
A platform leader should not respond with vagueness. Nor should they manufacture certainty.
A stronger update separates:
Known:
The current friction, affected teams, operational cost, or risk.
Believed:
The proposed intervention and expected mechanism.
Unknown:
Adoption, migration effort, long-term abstraction, or scale behaviour.
Next evidence:
What will be learned, by when, and what decision it will enable.
Example:
Known:
New services require multiple manual security and deployment steps.
Believed:
A paved-road service workflow can remove most of this coordination.
Unknown:
Whether one workflow fits regulated and standard services.
Next evidence:
Pilot with three teams, measure time to production, exception rate, and support demand before committing to a broader migration.
This communicates control without claiming omniscience.
14. COMMON LEADERSHIP FAILURES
Premature standardization
The team chooses one technical path before understanding workload variation. Exceptions then become political conflicts.
Building for the loudest team
One influential consumer shapes the platform, while other teams inherit an inappropriate abstraction.
Confusing mandate with adoption
Executive sponsorship can force initial usage. It cannot create long-term trust or product value.
Becoming a ticket team
The platform team completes tasks for other teams instead of converting repeated work into self-service capability.
Measuring migration instead of benefit
A high migration percentage can coexist with slower teams, greater support burden, and lower autonomy.
Avoiding deprecation
Old and new platform paths remain supported indefinitely, fragmenting attention and increasing operating cost.
Treating ambiguity as failure
The organization pressures leaders to provide certainty, causing assumptions to be hidden rather than tested.
15. A PRACTICAL LEADERSHIP PLAYBOOK
When a platform problem is unclear:
1. Name the user segment.
2. Describe the observed friction.
3. Separate demand, solution, and mandate ambiguity.
4. State the non-negotiable constraints.
5. Identify the smallest end-to-end path worth improving.
6. Define evidence that would justify scaling.
7. Assign a review date.
8. Protect the pilot from becoming a permanent exception.
9. Publish what was learned.
10. Stop or revise work whose assumptions do not hold.
The discipline is not moving slowly. It is avoiding expensive certainty.
FINAL PERSPECTIVE
Leading a platform team through ambiguity is not primarily a planning exercise.
It is the design of an environment in which:
– teams understand the direction
– local decisions remain possible
– uncertainty is visible
– experiments are bounded
– evidence changes investment
– shared capabilities improve through adoption.
The strongest platform leaders do not promise to know the entire road.
They make the next decision understandable, reversible where possible, and connected to a measurable outcome.
The enduring principle is:
Create clarity about intent, constraints, and evidence—even when the final solution is still uncertain.
RESEARCH BASIS
[1] Team Topologies, “Key Concepts.”
https://teamtopologies.com/key-concepts
[2] Cloud Native Computing Foundation, “Announcing a White Paper on Platforms for Cloud Native Computing.”
https://www.cncf.io/blog/2023/04/11/announcing-a-white-paper-on-platforms-for-cloud-native-computing/
[3] DORA, 2023 Accelerate State of DevOps Report.
https://dora.dev/research/2023/dora-report/2023-dora-accelerate-state-of-devops-report.pdf