Building an IDP: avoid Rail Tracks, create Guardrails & Paved Roads.

In my earlier articles I explained that cultivating healthy competition is key to preventing a platform from becoming monopoly, and that developing 'paved roads' is one of the ways to make space for that competition, but what are 'paved roads' and what happens if you get them wrong?

This is the third article in a series about Internal Developer Platforms. I initially wrote about The Platform Monopoly Trap and then I followed it with an The Olympics-themed article about how to create the healthy internal competition I referred to in the first article.

Let's get a few definitions out of the way...

Paved Roads

The term 'paved road' originates from Netflix's engineering culture, where it was coined to describe the concept of providing developers with a smooth, well-supported path (like a paved road) for software development. A 'paved road' usually combines standardised tools, frameworks, and best practices, to ensure efficiency and reliability, while still allowing developers the flexibility to go "off-road" and develop custom solutions if needed.

Rail Tracks

A 'rail track' describes a similar concept of a path that combines tools, practices and processes in a similar way, but where the platform does not allow or enable developers to go 'off-road' when they need or want to.

Guardrails

In this context a 'guardrail' is one or more policies that limit the flexibility, access or permissions that developers have. It's normal for a well-organised and well-run team to create a guardrail that places limits on who can perform root or admin activities, for example.

How rail tracks negatively impact productivity

It's not uncommon for organisations early in their adoption of cloud to allow developers a lot of freedom then react to security incidents or unplanned/unexpected high charges by locking access down. These decisions create rail tracks - limited routes that only enable travel between specific locations, analogous in platforms to strict controls with few permissions.

Under pressure many organisations seem unable to take the time to consider what the right balance is; it is common for developer productivity and rates of feature delivery to decrease - which increases other costs in a way that is much harder to measure. Attributing the costs of delays to poor developer performance is an easy leap to make, if the controls that now hamper productivity were emplaced as a result of the problems above being a result of developer activities.

It's important to note here that a rail is not inherently bad and the platform may need to define rails for some activities, such as provisioning expensive infrastructure or enabling external access to internal resources, but if those rails are the only routes available to developers then a platform is probably stifling the competition it needs to remain healthy.

Is there a balance?

One of the key contributions from the extensive DORA research, documented in the book Accelerate: The Science of Lean Software and DevOps was that high performers are not forced to choose between speed and safety. Traditional thinking often posited that increasing the speed of software delivery would inevitably lead to compromises in safety, quality, or stability. However, the research in Accelerate challenges this assumption and provides data-backed insights into how organizations can achieve both high speed and high safety simultaneously.

The book's research found that organizations that deliver software quickly (high deployment frequency and low lead time for changes) also experience high levels of safety (low change failure rate and fast recovery times). This finding contradicts the conventional wisdom that prioritizing speed leads to a reduction in quality or an increase in failures. High-performing organizations were shown to be capable of deploying multiple times per day with low failure rates and quick recovery from any issues that did arise.

The belief that there is a tradeoff between speed and safety has been shown to be faulty.

What role do Paved Roads play?

Accelerate identifies several practices as key to achieving high performance; two of these that explain how Paved Roads help achieve this are:

• Empowerment and autonomy: high-performing teams are often given a high degree of autonomy and responsibility for their work, including the ability to deploy code themselves. This autonomy enables teams to iterate quickly and safely because they have a deep understanding of the system and ownership of their code. This empowerment leads to better decision-making, as teams are closer to the problem space and can respond to issues more effectively.
• Use of Automation: automation is a key enabler of both speed and safety. By automating repetitive, error-prone tasks such as testing, deployment, and monitoring, organizations can reduce the risk of human error and accelerate their delivery processes. Automated systems can consistently apply the same checks and processes, ensuring that safety standards are maintained even as the pace of development increases.

Note the focus on autonomy and how automation can improve speed and reliability. The act of enabling autonomy is where well-designed paved roads with guardrails can provide constraints that direct and channel activity rather than prevent it, while protecting the organisation, its data and systems.

Remember: giving teams autonomy is also the property that allows an organisation to cultivate the necessary competition that keeps a platform healthy.

For related reading, I recommend following my colleague Lorenzo Murrocu, who has been digging into the detail of how to design a platform that meets developers needs in an excellent series of articles that use an analogy of a platform as a kitchen, and developers to chefs - a great and thought provoking read.

As ever, thanks to those who've reached out and commented - I love to hear what you think!