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 adoption is won.
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 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.