The technical landscape evolves at a staggering pace, consuming more of our lives than we sometimes realise. For engineers building the backbone of the systems and applications that power the everyday, navigating the growing complexity of languages, toolchains and workflows is becoming increasingly tricky.
So how can software engineers decrease their cognitive load while ensuring quality? Enter the platform engineer, and more specifically, the Internal Developer Platform (IDP).
The evolution of DevOps
Platform engineering is the natural evolutionary step in adopting DevOps at scale. A helpful way to understand this evolution is with a metaphor. Imagine you design and deliver cars. Back in the day, you had one option available for your customers – no choice in model, chassis, engine, power or anything else. This wasn’t working for your customers. So you found a way to create more options, deliver more value. Suddenly, from no choice at all, you now had complete free range – any combination and extras you could think of. But with all that power comes a lot of decision-making, mental fatigue and responsibility. Learning from the journey you’ve taken so far, you’ve now pre-planned the best combinations of options into standard templates that offer your customers a limited range with restricted customisations. The result is a streamlined factory, improved outcomes and a lot less mental and admin overhead.
This is what’s happening in software engineering.
In the early days of DevOps, the principle of 'you build it, you run it' gave software engineers unprecedented control over their applications, from code to deployment. With these near-endless options came greater responsibility for engineers, and a need to master numerous domains. The result: sprawling complexities, wasted resources, cognitive overload/mental exhaustion and often slower output. Platform engineering seeks to solve this by offering a structured, scalable approach supported by the underlying platform framework and API, evolving how development teams at scale operate.
As this next evolutionary step, platform engineers treat platforms as a product used by development teams and designed to function in a self-service manner. They do this by defining golden paths that, with feedback from the software engineers as the client, allow development teams to move quickly and safely. Ricardo Pinto, lead platform engineer at software solutions company BBD, makes it clear though that “golden paths are not golden cages. It’s not about dictating how everything must be, but rather lowering the barrier of entry for development teams and creating build clarity across distributed teams in an organisation. This clarity allows teams to build with speed, accuracy and in a way that’s easy to use”. Everyone wins.
These golden paths exist in what’s known as an IDP. Pinto stresses that these IDPs are predominantly necessary only for large organisations with multiple development teams delivering at scale.
How IDPs are changing the game
IDPs consolidate APIs, tools, services, knowledge and support into a self-service experience for engineers by creating golden paths that essentially standardise workflows. Through this centralised portal or set of tools, teams can easily access preconfigured environments, deploy code, manage resources and access monitoring services. This self-service experience empowers engineers to work autonomously while adhering to best practices baked into the platform. Examples include standardised CI/CD pipelines for deploying micro-services, or preconfigured testing environments that align to the company’s compliance policies.
Perhaps the most fundamental aspect, though, is that IDPs act as a flexible and supported abstraction layer between the engineering teams and the underlying technologies of their applications. Abstracting this layer allows the engineers to focus on building features rather than wrestling with infrastructure or configurations. For teams working at scale, this kind of consistency translates into faster iterations and fewer operational headaches such as security, monitoring and compliance.
In his role developing a platform engineering centre of excellence at BBD, Pinto explains that the trick is to see the development teams at client organisations as the platform engineer’s client. He explains that your goal is to develop golden paths and paved roads that make their work easier, quicker, safer for the organisation, and smoother. You are not building everything for everyone, but rather meeting the developers where they are and improving their experience on the repetitive tasks they spend 80% of their time on. “I like to say that platform engineers build the world the engineers want, not a world you’ll impose on them. At the end of the day, the IDP is only useful if it works the way our clients need it to.” It is also an iterative journey where needs will change. So start small, measure, illicit feedback, adapt and measure again.
Key takeaways
Having worked at the forefront of platform engineering adoption within BBD’s client spaces, Pinto has gathered a list of the most practical advice for platform engineers and organisations considering starting on this journey:
- Measure, measure, measure. If it’s not effective, what’s the point?
- The platform engineer’s goal is user-driven and focused on improving the developer experience. The goal is not to add to their experience with another ivory tower.
- The greatest platform is useless if not adopted by the teams.
- Think of adoption like trading power for experience: if the experience isn’t worth it, then it’ll be easier for the engineers to forgo the platform and build it themselves.
- Not everything has to be automated – there’s no point automating something over three weeks that takes two hours to build once a quarter.
- If you could buy it off the shelf, you don’t need a platform team.
- And lastly, build something useful.
A new frontier in motion
As organisations continue to scale and the demands on development teams grow, platform engineering and IDPs are emerging as critical solutions for streamlining workflows and reducing complexity. Gartner even predicts that 80% of software engineering organisations will have platform teams building IDPs by 2026.
By paving golden paths, platform engineers are not only enhancing productivity, but also reducing cognitive overload, empowering engineers to focus on innovation rather than infrastructure.
The shift towards IDPs signals a pivotal change in how modern development teams operate – one that prioritises consistency, security and autonomy, while still allowing flexibility when needed.
The role of platform engineers will only grow in significance, serving as the architects of these golden paths that will guide development teams through an increasingly complex landscape. As the space matures, the next challenge will be ensuring that IDPs remain adaptable, evolving alongside ever-shifting industry demands, all while keeping the developer experience front and centre.
Share