However, simply recruiting a team of platform engineers won’t equate to achieving a competitive edge. This is only possible when technology firms create a culture that’s poised to effectively facilitate a platform engineering function. One that can fail-fast and pivot quickly, enables experimentation, encourages autonomy and empowers teams.
Platform engineering's role in developer velocity
Platform engineers design, build and maintain a shared set of tools, services and systems - most often referred to as an ‘Internal Developer Platform’ - that forms a robust foundation that any developer in the company can use. This enables them to build software faster and more easily given they don’t have to start from scratch each time.
Platform engineers essentially provide paved roads that enable developer self-service. The platform consists of many different technologies and tools glued together in a way that lowers the cognitive load on developers as they create products and offerings while maintaining context, understanding cost and underlying technologies.
Ensuring Two-Way Doors Decisioning
Organisations that are successful in adopting platform engineering can achieve significant gains. Implementing a two-way doors decision framework allows them to experiment, test and learn with minimal risk.
Picture a door that can only be opened one way and is locked from the other side versus a swinging or revolving door. A one-way door represents consequential, ultimate and non-reversible decisions; a two-way door demonstrates decisions that can easily and quickly be rolled back and re-jigged.
Many organisations place equal value on almost every decision because they don't want to be wrong. Instead, they should match their chosen decision framework to its impact, recognising that not all choices are equal and one-size-fits-all thinking will slow them down.
By embracing a two-way doors decision framework, organisations can experiment and learn fast, but not dangerously. For example, choosing a Virtual Machine (VM) instance type in the cloud or leveraging different large language models might feel like momentous decisions, but they can easily be reversed.
Using models like challenger vs champion is another great way to test success and lower negative consequences. This is where you send a fraction of traffic to a challenger tech setup or tool to see how it performs. If it fails, it won’t impact a large amount of data or cost and if it performs well, it can become the champion and you can increase traffic going to it.
Transitioning to a Shared Fate Model
There is an appreciation for why centralised governance structures exist in highly regulated enterprises, however the key is in balancing centralised policy with decentralised decision making.
The term ‘ivory tower’ describes an organisational structure where leaders are isolated from the rest of the organisation and make decisions without truly understanding their end impacts. What is key here is that there is no ‘Shared Fate’ between the functions that are critical to build and operate.
This over centralised setup where the IT architecture function is bound to a Standard Operating Environment with no local admin rights is stifling to platform engineers. Architects need autonomy and admin rights to undertake tasks like installing the latest version of Powershell or Docker. Operations will have little idea why a specific microservice API error rate is increasing, and conversely, developers will be at arm’s length from reality and seeing how their software fails. It’s not conducive to speed. It creates red-tape and bottlenecks and removes full visibility.
Centralised operations can build economies of scale, for example, one large Kubernetes cluster. However, sometimes scaling to meet demands can introduce a single choke point. This increases your business risk profile as all your assets are now in one account with a concentrated blast radius and the same resource limits.
In successful, large-scale platform engineering-based organisations, there may be 50 to 1000 different service teams with linked / peered Azure vNets/ AWS VPCs. Each team is self-empowered and accountable for their environment, completely controlling how and when they deploy and release without impacting others.
They each build their code, then run their own infrastructure themselves and in most places, pay for it. While the pitfall of each squad running their own platform is inefficiencies, the upside is that it reduces risk. It removes tight coupling and instead promotes platform independence, speed and innovation.
Fostering Discovery Over Directive
Rather than dictating the journey, outlining where the business needs to get to and then giving these individualised teams the freedom and decision-making powers to problem solve and find a method to get there will instil a sense of accomplishment and foster innovation.
Platform engineering is an enabler for organisations as it accelerates development through the right developer experience. However, the mere establishment of a platform engineering team on its own is insufficient.
Success hinges on cultivating a supportive culture that prioritises developer needs with embraced experimentation, autonomy, and decentralised decision-making. By leveraging a two-way doors decision framework and empowering teams with the freedom to innovate and manage their own infrastructure, organisations can enhance developer velocity and minimise risks. Implementing these cultural changes will transform platform engineering from a functional necessity into a strategic advantage.
