The Question Most Teams Skip Before Starting a Platform Engineering Initiative
Platform engineering and internal developer platforms (IDPs) now appear on a lot of strategy slides.
The pattern is familiar:
- delivery is painful,
- leadership hears about platform engineering,
- a new initiative launches to "build a platform" or buy an IDP.
What’s often missing is one crucial question:
For which teams, doing what kind of work, is this platform supposed to reduce cognitive load and lead time?
Without an explicit answer, the initiative drifts. The platform becomes a collection of tools and dashboards rather than a deliberate reshaping of how work flows.
Why This Question Matters More Than the Tech Stack
It is tempting to start with tools:
- Kubernetes, backstage-style portals, CI/CD orchestrators,
- IDPs promising golden paths out of the box.
But until we know who the platform is for and what work we’re trying to make easier, we are optimising in the dark.
That one question forces clarity on:
- the types of teams we have (stream-aligned, enabling, platform, etc.),
- the kinds of changes they make most often,
- and where they feel the most friction today.
The platform’s architecture should reflect those answers.
From Vague Pain to Concrete Use Cases
Most organisations start from a vague problem statement:
- "Deployments are slow."
- "We have too many tools."
- "Infra is too complicated."
Those are symptoms, not design inputs.
The skipped question turns them into more specific targets:
- For which product teams is deployment friction highest?
- What common tasks are eating their time (environments, approvals, observability, secrets)?
- Which of those tasks are shared across many teams and good candidates for a platform capability?
Only then do we have a grounded list of platform use cases to design around.
Shaping Platform Scope Around Real Work
Once you know which teams and which work you are designing for, scope becomes easier to reason about:
- A delivery-focused platform might own build/test/deploy workflows for services that meet clear criteria.
- An environment-focused platform might make it trivial to spin up consistent, policy-compliant environments.
- An observability-focused platform might standardise how metrics, logs, and traces are collected and explored.
Each of these is anchored in:
- specific teams,
- specific types of changes,
- and specific bottlenecks in today’s flow.
The initiative becomes less about "having a platform" and more about changing how work feels for particular teams.
Avoiding the "Platform for Everyone and Everything" Trap
Skipping the core question leads to an all-purpose platform that tries to:
- support every team equally from day one,
- solve every cross-cutting concern at once,
- answer every request that lands in the platform backlog.
The result is familiar:
- a thin layer over many existing tools,
- unclear ownership of platform capabilities,
- and little measurable improvement in delivery for anyone.
By contrast, when we commit to a clear answer about which teams and work we are prioritising, it becomes easier to:
- say no to misaligned requests,
- iterate the platform in focused slices,
- and show concrete before/after improvements.
How This Shows Up in Architecture
Architecturally, this question shapes:
- Interfaces – are we exposing concepts teams already use (services, environments, releases), or inventing a new layer of abstraction?
- Boundaries – which parts of the path to production are owned by the platform vs the teams?
- Dependencies – which core systems (CI, cloud, identity, observability) the platform leans on.
A platform designed around real teams and flows tends to:
- be thinner and more composable,
- align cleanly with existing services and environments,
- and evolve in step with how those teams work.
The Question in Practice
When we work with organisations on platform initiatives, we often start a workshop with a simple exercise:
- List 3–5 teams you believe will benefit most from a platform in the next 12–18 months.
- For each team, describe the most common path to production for one representative service.
- Mark the steps where:
- they wait on other teams,
- they repeat boilerplate work,
- or they are unsure what "the right way" is.
Only after this do we ask, "What capabilities would a platform need to make these flows meaningfully better?"
The initial question – about which teams, doing what work – keeps the conversation anchored.
How We Frame Platform Initiatives at Fentrex
At Fentrex, we treat platform engineering as an architectural response to specific delivery problems, not as a default maturity step.
We keep coming back to variations of the same question:
- Which teams are struggling with delivery in ways that a shared platform could genuinely fix?
- What work are they doing repeatedly that we can encode into paved paths?
- How will we know, in six months, whether the platform actually reduced cognitive load and lead time for them?
Once we have clear answers, technology choices become easier.
Questions to Ask Before You Start Your Own Initiative
If you are about to launch a platform engineering initiative, you can start with:
- Which 2–3 teams are we designing for first?
- What specific work should become easier or safer for them?
- How will we measure whether that has actually happened?
- What are we not taking on in the first iteration of the platform?
Answering these turns "platform engineering" from an abstract trend into a concrete, testable change in how work flows through your organisation.