The concept of platform engineering has finally gotten a name, but its roots are older than the term suggests. When we label something, we invest in it, and platform engineering is no exception: it's about hiring the right people, building the right org structures, and allocating the right resources.
At small scale, each developer can set up their own environment, pipeline, and infrastructure. But as organisations grow, this approach becomes unsustainable: inconsistent environments, repeated setup work, security configuration drift, and a cognitive burden that's hard to bear. Platform engineering addresses these issues by building internal tools that make developers more productive, without forcing each team to reinvent the wheel.
The golden path is a pre-approved, pre-configured way to build, test, and deploy a new service. It's defined by the platform team: the CI/CD template, the container base image, the monitoring configuration, and how to register the service in the catalog. Developers who follow the golden path can get a working service fast, while those who deviate have to configure everything themselves.
For example, at a previous company, we implemented a golden path using GitLab CI/CD templates and Docker base images. This resulted in a 30% reduction in the time it took for developers to get a new service up and running. However, we also had to balance the level of standardization with the need for flexibility, as some teams required custom configurations that couldn't be accommodated by the golden path.
The Team Topologies model provides a useful framework for thinking about platform teams. It suggests that a platform team should provide a self-service platform that enables stream-aligned teams to deliver without relying on specialists for infrastructure tasks. The goal of the platform team is to reduce the cognitive load on feature teams, not control them.
So, what should you automate first? The highest ROI targets are new service bootstrapping (project setup, repository creation, CI/CD wiring), environment provisioning (dev, staging, production environments on demand), and on-call runbook automation (common operational tasks that on-call engineers execute manually). These are the tasks where the time cost of manual execution across many teams justifies the investment in automation.
In our experience, automating new service bootstrapping using tools like Terraform and Ansible can save around 2-3 hours per service, which adds up to significant cost savings across the organisation. Additionally, automating environment provisioning can reduce the time it takes to spin up a new environment from days to hours.
In mature organisations, platform engineering has been around for years, but the naming and formalization have accelerated its adoption. As organisations grow, platform engineering becomes increasingly important: it helps reduce inconsistency, setup work, and security configuration drift, and it alleviates the cognitive burden on developers.
By providing a self-service platform, platform teams can enable stream-aligned teams to deliver without relying on specialists. The platform team's goal is to reduce the cognitive load on feature teams, not control them. This approach allows feature teams to focus on their core work while the platform team handles the underlying infrastructure.
New service bootstrapping, environment provisioning, and on-call runbook automation are the highest ROI targets for platform automation. These tasks justify the investment in automation because of the time cost of manual execution across many teams.
Platform engineering is not just about building internal tools; it's about creating a self-service platform that enables developers to be more productive. By investing in platform engineering, organisations can reduce inconsistency, setup work, and security configuration drift, and alleviate the cognitive burden on developers.