Lessons Learnt from 3 Years as Head of Platforms
How we supercharged our Software Engineering Team using Platforms.
Before my current role as Head of Engineering, I led our Platforms Team. Companies like Google have understood the power of Platforms for a long time, however outside of the Tech Giant World the idea of a whole team dedicated to Platforms is still quite new. Taking the plunge paid off, our Platforms Team catapulted us at a rate of change and maturity that we had never seen before.
What drove the decision?
At the time there was (and still is) a lot of noise in the industry around Platform Teams. We keep a close eye on the ThoughtWorks Tech Radar for understanding new trends and fads; Platform Teams popped up on there around the time as a concept to ‘Adopt’.
We consider platform engineering product teams to be a standard approach and a significant enabler for high-performing IT — ThoughtWorks
At the time we had also started to see rapid growth in our team, and as a result the number of Products and (micro)services we were managing was proliferating. We were looking towards better ways of structuring our teams to be more effective. Team Topologies really resonated with us as an approach; one of the key drivers it advocates is Platform Teams.
If you haven’t read Team Topologies, I would highly recommend it! It discusses how Conway’s Law can be navigated by using Team First principles and 4 distinct Team Types.
What is a Platform?
We are generally pretty familiar with the idea of building Products to meet the needs of our clients, and hopefully make some money. Platforms are built and managed in exactly the same way as Products, however there is one key difference. Our key stakeholders are internal teams, generally Engineers.
Platforms exist to empower our Product Teams to get things done quicker, more securely and more effectively. Platform Teams are also important for pollenating knowledge across the team and driving standards and consistency, so that teams can flex around different cross-functional problems.
To get the most out of Platforms, we shouldn’t treat them as an edge of desk activity. They should be managed, resourced and funded independently, just like any other Product.
A Platform could range from anything as simple as a Wiki, to a full blown infrastructure platform.
Google’s Borg platform is used to host almost all of their infrastructure and Tech. By pushing their teams to deploy to a standard platform, they have built a humongous network of knowledge around it; this has enabled them to grow at an unprecedented rate. Borg is the predecessor to Kubernetes, which now sits at the centre of lots of companies infrastructure platforms.
Successful Platforms
Over the last 3 years we have built of a portfolio of almost 50 different platforms. One of our most valuable platforms is simply a Wiki which the whole team can access for understanding standards across the team and also our Platform Catalogue. We have even explored feeding this into a Generative AI solution so that people can ask an Assistant questions about how our team operates.
Infrastructure Platform
Our largest and most important platform is our Kubernetes Infrastructure Platform. I have covered some of the principles and design decisions taken in previous article: How We Built an Infrastructure Platform on Top of Kubernetes.
If you have a fairly large team, then a platform like this can be extremely effective!
All our new apps are deployed to our infrastructure platform. We try to make everything self-service so that engineers can manage their own apps themselves. We have a whole team who manages the platform and also trains our teams to use it and get the most out of it.
Admin Portal
We have our own Admin Portal built in-house. It’s used for anything that helps our Product teams get stuff done easier and quicker. That could be managing user permissions, infrastructure provisioning/monitoring or managing our Product Catalogue. We try to make as much as we can self-serve so that our teams can scale independently.
There’s also some Open Source Admin Portals out there now as well. I’d recommend checking out Spotify Backstage to see if that meets your needs before you build yourself.
Design System
Our Design System is an Angular library with components which can be used in our web apps. We also have a website built around the Design System, with guidance and standards from our Designers and Front-End Gurus.
Our Design System provides a few benefits:
- Less component code needed for our Developers
- Better standardisation across all our apps
- Designed and built by experts
Lots of large companies even publish their Design Systems, here’s a few to take some ideas from:
Template App
We are creating a huge amount of code and services across the team. Lots of this code is just cross-cutting scaffolding code. Some consistency across all of our apps makes maintenance and moving teams around much much easier.
We have a Template microservice application which scaffolds a whole solution for you. It has loads of different options that can be selected, however everything conforms to our Development standards. At the click of a button we can have a whole repo generated with an API, web app, authentication, database, infrastructure-as-code, deployment pipelines, tests and documentation. This means that our teams can get to building their Domain code more quickly and not worry about everything else.
I have previously written an article about how to create your own Template App: How to Create a Configurable .NET Project Template.
Developer CLI
We have our own team Developer Command Line Interface which is used to automate tasks that are regularly performed. It is used by our Engineering team and also within automated Continuous Integration Build pipelines. Having an Admin Portal is great however building most stuff straight into the CLI is much quicker and easier.
Where does DevOps fit?
This is a topic which tends to spark heated debates whenever brought up. There’s lots of ways of running DevOps successfully, however these are the principles that my team follows successfully:
- DevOps as an activity should not be centralised. A centralised DevOps delivery team goes completely against the philosophy of DevOps!
- DevOps is a mindset that all of our teams should embrace.
- Strive for cross-functional teams, where Developers can meet all DevOps requirements.
- Our DevOps Engineers aim to enable and teach our Developers. Their primary goal is not to do all DevOps activities for them.
Our DevOps team fits within the Platforms Team because much of their work is around improving and supporting our Infrastructure Platform. The rest of their time is spent upskilling our whole team around DevOps and researching better technologies and processes. Sometimes they will get stuck-in to help a Product team on DevOps delivery, but that is not their main goal.
More recently, a big objective of ours is to embrace DevSecOps and shift-left mentality. There’s so many different security tools out there, so it is important to assess and adopt some standards. Our DevOps team have been essential in defining our DevSecOps Strategy and helping our teams implement a suite of different security tools.
Challenges
There have certainly been some challenges along the way.
Costs, Budgets and Resourcing
I found that running Platform Teams was not hard; they work just like any other Product Team. Getting the resources and budget however is much harder. Running shared Platforms is a different to what we are familiar with, it generally requires sharing costs across all of the Products using the Platforms. Working out who pays for what and how much they pay can be really hard.
Adoption
As with any technology, adoption can be hard at first. I think that a Carrot and Stick approach is often needed. The Carrot is building powerful Platforms and celebrating them as much as you can; the Stick might mean bringing in standards which MUST be adopted.
It’s really important to cultivate some Communities and Champions to help your team learn about all of your amazing platforms and help your teams get started using them.
It took a year or so for our Platforms Team to get going, however it’s now a vital part of our Engineering Team. Once the wider team had gone through the mindset shift of understanding the benefits of Platforms and how to work with them, everything else fell into place quickly.
If you have a medium to large Engineering team (50+ Engineers), then setting up a dedicated Platform Team could hugely improve your teams productivity. Good luck on your own journey!
