Platform engineers
Platform engineers build an internal product and the organisation’s own engineers are its users. The output is a self-service way to create, ship, observe and operate services, with supported routes across it that carry the organisation’s standards without anyone reassembling them each time. The discipline succeeds or fails on adoption, which makes it as much a product problem as an infrastructure one. What follows sets out the scope of the role, when an organisation is large enough to justify one, and how to assess a candidate.
What does a platform engineer do?
A platform engineer builds and runs an internal developer platform: a self-service surface through which an organisation’s engineers create services, deploy them, obtain infrastructure, observe what they run and operate it, without needing to understand or assemble the underlying components themselves. Well-supported routes across that platform carry the organisation’s requirements for security, reliability and cost by default. The role treats infrastructure as something to be abstracted behind a deliberate interface, and it is evaluated the way any product is — by whether the people it was built for choose to use it.
The central idea is the paved road: one well-supported way to do a common thing, made easier than the alternatives and arriving with the organisation’s requirements already satisfied. Teams stay free to leave the road and then own what they have taken on. That is the difference between a platform and a mandate — a platform makes the correct route the convenient one, while a mandate makes the incorrect route forbidden and generates elaborate avoidance, usually documented nowhere.
The economic argument is about attention. Every product team that must independently work out cluster networking, certificate renewal, log retention, alert routing and provider permissions spends attention that could have gone into the product, and arrives at a slightly different answer from every other team. A platform is worth building once the same infrastructure decision is being made repeatedly and inconsistently; before that it is an abstraction over a single case, costing more to maintain than the duplication it prevents.
What most distinguishes the discipline from adjacent ones is that it has users who can decline. An internal platform nobody adopts is not a partial success — it is a maintenance burden sitting alongside the bespoke arrangements teams built instead. That imports product obligations infrastructure work does not normally carry: understanding what users need, documentation, support, versioning, deprecation with migration paths, and measuring whether the thing is used at all.
When teams need this capability
Platform engineering is easy to start too early, when it produces an elaborate abstraction over one use case. These are the conditions under which it usually starts to repay the investment.
Several teams have solved the same problem in different ways
Each service has its own deployment approach, its own logging conventions, its own alerting and its own reading of the security requirements. None is wrong, all are slightly different, and nobody can move between teams without relearning the basics. The real cost is not the duplicated effort but that improving anything means changing it everywhere.
Getting infrastructure depends on a particular person
A new database, queue, environment or set of credentials requires asking someone who is busy. Delivery is now gated on that person’s calendar, and the organisation has an availability problem it experiences as a slowness problem.
Standards exist as documents rather than as defaults
The organisation has written down how services should handle secrets, retention, encryption and alerting, and compliance is a matter of memory and review. Documented standards are followed unevenly; standards built into the route teams already take are followed by construction.
Starting a new service takes weeks of undifferentiated work
Before any product code is written someone assembles a repository, a pipeline, a runtime, secrets, monitoring, alert routing and access. Because it is tedious, teams avoid creating services even where separation is the better design, and architecture is quietly shaped by setup cost.
The infrastructure group has become a queue
Requests arrive faster than they are completed, the backlog is the main artefact, and the group is measured on throughput. Nobody has time to remove the reason the requests exist, so the queue lengthens however efficiently it is worked. This signals that the shape of the work needs to change, not that more hands are needed.
The organisation has enough teams for a shared surface to pay back
A platform has fixed cost and its benefit scales with the number of teams using it. There is a threshold — different everywhere, but real — below which a few well-maintained templates and a shared module library serve better, and above which the absence of a platform shows up as inconsistency in every corner.
Core capabilities
Treating the platform as a product
Knowing who the users are, what they were doing before, and which of their problems the platform actually solves. It carries the ordinary obligations of a product: research, documentation, support, a considered roadmap, and honest measurement of adoption rather than output.
Golden paths and service templates
Providing a supported route from nothing to a running, observable, appropriately secured service — scaffolding, pipeline, runtime configuration, telemetry and alert routing arriving together, and staying maintainable after teams have modified it.
Self-service provisioning
Letting teams obtain databases, queues, environments, DNS entries and permissions through a declared request fulfilled automatically, within limits the platform enforces. Success means nobody has to ask a person, not that asking has become faster.
Abstraction design
Deciding what to hide, what to expose and where the escape hatches sit. Hide too much and a team is stranded the moment its requirement is slightly unusual; hide too little and the result is documentation with extra steps. This boundary is the core intellectual work of the discipline.
Multi-tenancy and isolation
Running many teams’ workloads on shared infrastructure without allowing one to degrade another: resource limits, namespace and network boundaries, quota policy, and a clear position on what the platform guarantees to a tenant that is behaving badly.
Observability by default
Shipping instrumentation with the paved road so that traces, structured logs and useful metrics exist without each team building them. It is the difference between an organisation where monitoring is a project and one where any service can be investigated the moment it misbehaves.
Policy and guardrails as code
Encoding requirements as automated controls — admission policies, image provenance rules, network restrictions, runtime detection — so the compliant configuration is the default and any departure is visible. A guardrail that refuses something must say what to do instead, or teams route around it.
Identity and secrets for workloads
Giving every workload a verifiable identity and short-lived credentials issued on that basis, so applications no longer carry long-lived keys. Distribution, rotation and revocation become platform properties rather than something each team implements differently.
Reliability of the platform itself
The platform is a dependency of everything built on it, so its own availability objectives and error budget matter more than those of any single service. Failure modes deserve particular attention: a platform that fails closed can stop the organisation deploying during an incident, which is exactly when deployment is needed.
Interface evolution and deprecation
Versioning what teams depend on, and retiring old interfaces with a migration path, sufficient notice and — where possible — automated conversion. Deprecation handled badly is the fastest way to lose the trust a platform runs on, and trust is harder to rebuild than machinery.
Technology ecosystem
Common technologies in platform engineering are listed below. This is a description of the landscape of the discipline as it is practised, not a claim about any particular engineer’s toolkit. Platforms are assembled rather than bought, so the more useful question is how someone decides what to build, what to adopt and what to leave alone.
Runtime and orchestration
- Kubernetes
- Nomad
- ECS
- Cloud Run
- Knative
Developer portals and interfaces
- Backstage
- Port
- Cortex
- Humanitec
- Internal CLIs
Control planes and provisioning
- Crossplane
- Kubernetes operators
- Kubebuilder
- Terraform modules
- Pulumi
Configuration and templating
- Helm
- Kustomize
- CUE
- Jsonnet
- Cookiecutter
Policy and workload security
- Open Policy Agent
- Kyverno
- Falco
- cert-manager
- External Secrets Operator
- SPIFFE
Telemetry
- OpenTelemetry Collector
- Prometheus Operator
- Grafana
- Tempo
- Pyroscope
Languages for platform components
- Go
- Python
- TypeScript
- Rust
- Shell
How this role works with your team
Engineers work inside your team, on your priorities, to your standards. You direct the work; Talent.ID carries the employment. The division below is the whole arrangement.
You keep
- Product
- Business priorities
- Roadmap
- Architecture
- Sprint priorities
- Engineering standards
- Day-to-day technical collaboration
Talent.ID handles
- Employment relationship
- Payroll
- Employee benefits
- Talent administration
- Ongoing employee relationship
What to look for when hiring
Platform engineering is a newer label than the work it describes, so it now covers a wide range of jobs, some of them ordinary infrastructure work relabelled. What distinguishes a genuine platform engineer is an orientation towards internal users, and an ability to discuss adoption as readily as architecture.
Orientation towards internal users
Ask who used the last platform they worked on and how they learned what those people needed. Engineers who have done this properly name specific teams, specific frustrations and specific things they got wrong; those who have not describe the architecture and assume the need was obvious.
- Can describe a feature they built that internal teams ignored, and why
- Has sat with a product team while they used the platform
- Talks about the platform’s users as people with alternatives, not as recipients
- Knows which parts of their platform were most complained about
Judgement about abstraction
Every internal abstraction eventually meets a requirement it did not anticipate. Ask what happens then. The answer reveals whether they design escape hatches deliberately or discover the need for them during an argument with a team that has a deadline.
- Provides a supported way to step outside the abstraction rather than forbidding it
- Can explain something they chose deliberately not to hide
- Has removed an abstraction that was not earning its maintenance cost
Adoption achieved without mandate
A platform imposed by decree accumulates resentment and workarounds; one adopted because it is genuinely easier accumulates users. Ask how a team was persuaded to migrate onto something they built — the good answers make the migration cheap rather than the alternative prohibited.
- Measures adoption and can say what it was, not only that it grew
- Reduced migration cost by doing part of the work for the team
- Distinguishes a genuinely adopted platform from one everyone was instructed to use
Running the platform as a production system
The platform is infrastructure for everything else, which changes the standard it is held to. Ask what happens to the organisation when their platform is unavailable, and whether they have designed for it failing open where that is the safer behaviour.
- Has explicit availability objectives for the platform itself
- Has considered which failures should still allow teams to deploy
- Runs the platform’s own on-call rather than routing its failures to product teams
- Can describe a platform incident and the change it produced
Guardrails that do not become obstacles
Automated policy is the mechanism by which standards become defaults, and it is also the fastest way to make a platform hated. Ask how they introduced a control that blocked something teams were previously doing, and how they handled the objections.
- Introduced a policy in report-only mode before enforcing it
- Writes rejection messages that say what to do instead
- Has an exception process that is recorded rather than informal
Measuring developer experience
Ask how they knew the platform was helping. Strong candidates cite something observable — time from an empty repository to a running service, how often teams open a support request — and are honest about what the measurement failed to capture.
- Uses a measure connected to what developers experience, not to platform output
- Combines quantitative signals with talking to the people affected
- Can name something that improved on paper and not in practice
Deprecating what they built
Internal interfaces accumulate, and an organisation that never retires anything maintains every version it ever shipped. Ask about something they took away, and listen for notice, migration tooling and follow-through rather than an announcement and an expectation of compliance.
- Provided automated migration or did the conversion themselves
- Gave notice proportionate to the disruption caused
- Confirmed the old path was unused before removing it
Interview questions worth asking
Questions that reveal whether a candidate thinks in terms of internal users or only in terms of infrastructure. They are provided for your own interview process — the judgement about fit is yours to make, against requirements only you can define.
Describe the platform you last worked on. Who used it, and what were they doing before it existed?
What a strong answer shows
Whether the platform was built for observed needs or assumed ones. The second half of the question matters most: a candidate who cannot describe the previous state has probably not investigated whether the platform improved on it.
A team needs something your abstraction does not support and they have a deadline. What happens?
What a strong answer shows
How they handle the situation that determines a platform’s reputation. Strong answers offer a supported way out, treat the gap as product feedback, and avoid either a permanent special case or a flat refusal.
How did you get the first team onto something you built, and how did you get the fifth?
What a strong answer shows
Adoption method, and awareness that the two are different problems. The first team is usually a willing collaborator; the fifth has a working arrangement of its own and no particular reason to change it.
Your platform is unavailable. What can the organisation still do, and what stops entirely?
What a strong answer shows
Whether they have reasoned about being a dependency of everything. Look for deliberate failure modes, particularly around whether teams can still deploy a fix while the platform’s own control plane is degraded.
How would you decide whether a shared platform is justified in an organisation this size?
What a strong answer shows
Restraint. A candidate who believes every organisation needs a platform will build one prematurely. The considered answer weighs the number of teams, how much duplication exists, and whether templates and shared modules would serve better for now.
Tell me about a control or policy you introduced that stopped teams doing something they were used to doing.
What a strong answer shows
Whether they can enforce a standard without damaging the relationship. Listen for a warning period, clear guidance at the point of rejection, and a recorded exception route rather than a private one.
What did you build that nobody used, and what did you learn from it?
What a strong answer shows
Honesty and product instinct. Everyone in this discipline has built something that was ignored. The candidates worth hiring can say what it was, why they misjudged the need, and what they now check before building.
What this looks like in practice
A hypothetical scenario, written to show how the working model applies. It does not describe a Talent.ID client or a completed project.
- Challenge
- An organisation with a growing number of delivery teams finds each has assembled its own way of shipping and operating services. Standards exist as written guidance and are followed unevenly, provisioning depends on a small group whose backlog keeps lengthening, and starting a new service takes long enough that teams avoid it. A shared internal surface is agreed in principle and there is no capacity to build it.
- Approach
- The added capacity works to the conventions the platform group already holds — its interface design, its release process, its review standards and the priorities agreed in its planning. Internal engineers keep the roadmap for what the platform becomes and which teams it serves next, and the paved routes are built alongside the teams who will use them.
- What this adds to the team
- Ownership of the platform’s direction and its relationship with internal users stays inside the organisation. What gets abstracted, what stays visible and which standards become defaults are decided by the people who will maintain them.
Related disciplines
Frequently asked questions
- What is the difference between platform engineering and DevOps?
- They differ in who the work is for and in what it produces. DevOps concerns the movement of change into production and the signals that come back afterwards, and it is normally practised within a delivery team on that team’s behalf. Platform engineering produces something many teams consume: an internal product with a self-service interface and supported routes through it, used without knowledge of the machinery below. One is measured by how safely and how frequently software reaches users; the other by whether a team can obtain what it needs unaided. The confusion is understandable, since platform groups often build delivery tooling and many platform engineers arrived from delivery work — but a platform nobody uses has failed even where every pipeline it produced is excellent.
- Is a platform engineer just an infrastructure or cloud engineer renamed?
- Sometimes in practice, when an organisation relabels a team without changing how it works. Genuinely, no. Cloud and infrastructure engineering produce infrastructure: an account topology, an identity model, a resilience posture, a cost profile. Platform engineering produces something a colleague uses — with the obligations that follow from having users who could go elsewhere, including documentation, support, versioning, deprecation with a migration path, and adoption that is measured rather than assumed. The platform sits above that infrastructure and depends on it being sound, which is why the sequence matters.
- How large does an organisation need to be before this is justified?
- There is no universal threshold, but there is a reliable test: count how many times the same infrastructure decision is made independently, and how much the answers differ. With two or three teams the honest answer is usually well-maintained templates, a shared module library and clear documentation. The case strengthens as team count grows and inconsistency costs more than a platform would. Building one for a single consumer produces an abstraction that serves one case and complicates it.
- Should using the internal platform be mandatory?
- Making it the obvious choice works considerably better than making it compulsory. A mandate converts adoption into compliance, which conceals the feedback the platform needs: teams stop reporting that something is awkward and start working around it silently. A few things are genuinely non-negotiable, usually security and regulatory controls, and those belong in automated guardrails that apply on or off the paved road. For everything else, teams choosing an alternative is information about the platform rather than about the teams.
- What happens when a platform team becomes a ticket queue?
- It stops being a platform team and becomes a shared services desk with a different name. The work reorganises around closing requests, the group is measured on throughput, and nobody has room to build the self-service capability that would make the requests unnecessary. The queue then grows regardless of how efficiently it is worked, because the demand is generated by the absence of the thing the queue prevents anyone from building. Recovery means deliberately protecting capacity for platform work while requests continue, which is an uncomfortable decision only leadership can take.
- Who is on call for the platform?
- The platform team, for the platform. That is one of the clearer arguments for the discipline: when a shared component fails, one group that understands it responds, instead of several product teams independently diagnosing the same fault. The boundary must be explicit — what the platform is responsible for, what stays with the team owning a service, and how a page is routed when it is unclear. Ambiguity produces the worst outcome, where an incident opens with a negotiation about whose problem it is.
- How do platform engineers work with an existing engineering team?
- The engineer joins your team under a staff augmentation model and follows how that team already works: its review conventions, its release process, its architectural direction, and the priorities set in your planning cycle. Direction of the work is yours, together with the product, the roadmap and the engineering standards. Talent.ID holds the employment relationship for as long as it continues, and looks after talent administration, payroll and employee benefits.
Tell us what your team needs
Describe the gap — the work, the stack, the way your team runs — and we will tell you what we can support. If it is not something we can help with, we will say so.