In 2024, Platform Engineering is fast becoming the modus operandi of many organisations. In case you are wondering what Platform Engineering is, it is the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organisations. 

One may argue this is an evolution of DevOps and Site Reliability Engineering (SRE) approaches to meet evolving business needs.

Platform engineers provide an integrated product in the form of a platform that is most often referred to as an “Internal Developer Platform”, covering the operational necessities of the entire lifecycle of an application.

An Internal Developer Platform is built and maintained by a platform engineering team to build paved roads and enable developer self-service. It consists of many different technologies and tools glued together in a way that lowers the cognitive load on developers without abstracting away context and underlying technologies.

Understanding Platform Engineering's Role in Developer Velocity

Platform engineering done right means providing golden paths and paved roads that match the preferred abstraction level of the individual developer, who interacts with the Internal Developer Platform as they develop products and offerings. 

In part 1 of this multi-part series on Platform Engineering, before we talk technology, we need to move further down the stack and start with culture. Will your culture facilitate a transition to platform engineering?

We run our own path, but I still say I have been pretty lucky to see a lot of architecture in the last 15 + years, from some rather average to some pretty amazing architecture. The ones I count as amazing ones, you probably interface with as a user in your daily life as apps on your phone.

As the Greek philosopher Heraclitus said, the only constant in life is change. Are you keeping up to speed? If you know me, you would know I used to use VbScript and Classic ASP for almost ten years, I was not keeping up, and a lot of this was due to the culture around me.

You may not know me and my history, which has helped form my perspective. I come from a background of some pretty amazing engineering organisations.

Working for these organisations has landed me deep in the bowels of many organisations you interface with on a daily or near-daily basis. Organisations that build.

What is the cultural secret sauce of high-performance IT organisations?

First, a quick disclaimer, I am framing this article based on my personal experience. I have been fortunate to have owned tech relationships and first-hand experience with some amazing brands, you can see a few of these here.

This article reflects organisations that have been largely successful in adopting a platform engineering mindset, and I am going to talk to companies I have had exposure to, either with their architecture or to their culture. What they all have in common is having successfully adopted a platform engineering mindset.

All of these brands are disruptors in their own way.

They know how to experiment. They experiment and learn, and they do this using a method unlike traditional organisations. They do it fast, but it doesn’t mean they experiment dangerously. In fact, I would say they are safer than 95+% of organisations I have worked with.

They have systems and mechanisms in place and are structurally organised, so there is a controlled blast radius in place, and they can be very targeted in their experiments and measure constantly. You can't improve what you can't measure and their culture brings data points out in the open. Cloud spending, failure rates and so on.

So, if you know the one-way vs two-way doors decision framework, we are talking about two-way doors. This framework guides you to match your decision to its impact, recognising that not all choices are equal and one-size-fits-all thinking will slow you down.

Many of us place equal value on almost every decision. Why? We don't want to be wrong. 

So a one-way door is almost impossible to reverse. It's hard to go back once you make one of these decisions.

A two-way door means they can be quickly changed, like by choosing a VM instance type in the cloud or leveraging different large language models. While these decisions might feel momentous, they can be reversed with a little time and effort, often a lot less than you think.

Cultures that support Platform Engineering all use this principle. They make rapid changes and aren't afraid to roll things back. They’ve built cultures and processes around rapid innovation.

They use models like challenger vs champion, where they will send a fraction of traffic to a challenger to see how it performs, and if it performs well, it will become the champion.

Most importantly, they ship faster to learn faster.

Culture Eats Technology For Breakfast

You can teach tech to almost any organisation. I hold expert-level certifications in many public clouds. Does it mean I really am an expert?
You can answer no, that’s okay. The thing is, what's unique in organisations with a strong platform engineering focus is their culture.

Source: Conway's Law LinkedIn Post by Vivek Kant

I worked with a client a while ago who was the third-largest food manufacturer in the world.

Unfortunately, I saw first-hand how their culture was not set up for success. In my opinion, you can’t run a global IT Architecture function without giving enough autonomy to architects to at least install the latest version of Powershell or Docker because the IT Architecture function was bound to a Standard Operating Environment with no local admin rights.

Conway's law, like Moore's and Brooks's laws, holds true to this date. Its culture. Organisations design systems that are constrained to produce systems that are copies of the communications structure of the organisation.

This is the typical structure of many organisations. Development, Non-Production and Production environments (you may even have a few more environments). A staple of the enterprise.

This assumes your governance is very centralised. This assumption may work in a highly regulated enterprise organisation, but do you know what they say about assumptions?

This approach is atypical of organisations that adopt Platform Engineering. Why, you may ask?

This picture should make it clearer, especially the snapping crocodiles.

Centralised operations are not conducive to speed, full stop. They bring other benefits, but speed with an ivory tower is not one of them

You could argue that by having centralised operations, you can build economies of scale, for example, one large Kubernetes cluster. Throw us your containers, we will run them, that single name space.

Whilst this is technically true, scaling to meet the demands will mean a single choke point, which increases your business risk profile as all your eggs are now in one account, a concentrated blast radius with the same resource limits. This centralised model also drives a hero mentality, which we want to avoid.

These soldiers, the operations people in this picture, often have little idea why a specific microservice API error rate is increasing, and conversely, the developers are really at arm’s length from reality and seeing how their software fails.

This command and control style will not allow you to successfully transition towards Platform Engineering.

Decentralisation and Speed: Platform Engineering Essentials

If you are reading this and are working for an organisation that is trying to run faster and is experiencing outages, technology may not be the solution, have you looked at your culture? It can be difficult to approach, so use tact.

I am going to say everything fails all the time. No matter whose cloud.

Broadly speaking, complex systems and microservice architectures contain changing mixtures of failures latent within them.

How can we address the speed to market constraints whilst reducing business risk where change is embraced and is a non-event?

We spoke about moving fast, this is a good start, but we need to expand on this architecture.

Let me frame it like this. 

I want you to take this picture, of which I have scaled out a huge 8 AWS accounts. Now imagine what this would look like with 1000+ accounts.

What do you notice about this picture?

Gone is the castle, the soldiers.

Each team is accountable for their environment.

You build it, you run it (that includes supporting) and in most places, guess what. You pay for it. Do you know what the cost to serve is, well in this topology you do, there is no way to hide costs.

What I am trying to convey here is in successful platform engineering-based organisations, there may be 50 to 1000 different service teams. 

Each team will have many subscriptions, I have one per team in this diagram here, but there could be 5 to maybe 20+. For example, you might have 5 dev subscriptions, staging, QA, stress and volume, and production.

When they finish building their code, they don’t throw it over the fence, they run it themselves. What was the production subscription today may be destroyed tomorrow. 

Each team is self-empowered and completely controls how and when they deploy and release.

Yes there are guard rails, and we will talk to these in future articles in this series.

In summary, the true production environment may include hundreds linked / peered vNets/VPCs to create a pseudo-production environment.

What I want you to really hone in on here is empowerment.

This is empowerment and decentralisation. All of these self-empowered teams, in effect, are running their own small business. There are inefficiencies, sure. For example, each squad will run their own infrastructure in most cases, but it also reduces risk. Guess what? You have bought yourself a ton of speed. Tight coupling, be gone. Hello independence, speed and innovation.

This is culture here ladies and gentlemen, this is what separates the organisations that have made the shift to a platform engineering mindset.

If I had to codify this, this is what I would say.

This approach delivers platform independence, as we saw in the architecture diagram prior, and teams can deploy when they want without impacting others.

We have transitioned from the waterfall approach that most of us cut our teeth on, where change is a big deal and for many large enterprises, that is still their way of working.

Change freezes anyone? Guess what, competitors aren’t stopping. The amount of conversations I was exposed to where “it’s a race against company x or y”. If you require change freezes, it speaks to your maturity or lack of maturity in effectively managing risk.

When your culture is conducive to Platform Engineering, then IT will no-longer be a business blocker, that is where the magic happens.

True Innovation, where one can hypothesise, happens in an environment where it’s structured to fail-fast and pivot quickly.

You can read a lot about culture, far more than what I have spoken to you about today, but this is my lived experience dealing with hundreds of high-performing organisations in the last 15 years and what they all have in common. From my perspective, this is their secret sauce.

I want to close this article with a picture from Spotify on their own engineering culture.

Source: Spotify

Think about your organisation, to be successful in adopting Platform Engineering, how do you get to the top right quadrant? Will you continue to tell people to build a bridge, or will you allow them to find a method to get to the other side (perhaps it's not even a bridge)?

Summary

In summary, Platform Engineering is an enabler for your organisation by providing sensible defaults that drive developer velocity, but your culture plays a big part in getting there.

Centralised operations are not conducive to the establishment of platform engineering. Can you transition your culture to one that is decentralised and an enabler for your business? Of course you can, and if you need help in breaking free from the shackles of Conway's Law, reach out to us at V2 and we will help get you there.