Meet the platform team (1/4)
Stream-aligned teams are fixated on producing features. They never have enough "free time" to perfect their delivery. You need a platform team for that.
This is “Effective Delivery” — a bi-weekly newsletter from The Software House about improving software delivery through smarter IT team organization.
It was created by our senior technologists who’ve seen how strategic team management raises delivery performance by 20-40%.
TL;DR
Platform engineering is not just infrastructure work,
The team’s purpose is to help the core team ship faster by avoiding repetitive work.
Platform engineers deliver standardized services and teach how to use them,
We’ve seen a 25-50% faster delivery time thanks to our platform teams
Contents
Hey, hey! Adam here.
Previously, you learned Scrum isn’t even a team organization framework.
If you have multiple feature teams under Scrum, you’ll hit the efficiency ceiling soon.
But you can use Team Topologies to form new IT team types.
Companies like Adidas, Microsoft, and Docker did this.
Today, we're unpacking the platform team.
But you won’t read a simple transcript of what the Team Topologies book says.
You'll learn from our realistic experience of deploying such.
Do Platform teams work?
Yes. Beautifully.
I assume you still need some convincing.
You probably don’t have one now.
As a service company, we assigned at least 4 engineers to a commercial project.
These would take 3-4 months to complete.
After forming platform teams under Team Topology rules:
We only need 2-3 people to deliver the same project,
Delivery time dropped by 25% to even 50% thanks to our platform of shared services.
So, our platform team builds anything the stream-aligned team needs to get unblocked.
Some of the solutions we carry project-to-project include:
architecture building blocks,
pre-set infrastructure frameworks with observability and monitoring,
design systems with components for login pages, client panels, or dashboards,
or authorization solutions,
Bottom line, we engineer anything that lets us avoid repeated work.
But our success comes at a cost.
Our platform teams have clear responsibilities, the right number of people, and a mandate to act independently and not like support teams.
But that’s not an industry standard…
How platform engineering should look like
Some of the technology managers I connect with believe they’re already doing platform engineering.
It turns out to be a myth that works like this:
Company policy gives engineers 1 day per month for R&D.
2 engineers are asked to create a CLI tool to automate the creation of standardized microservices.
The goal is to reduce manual setup time.
If they both worked 1 day per month on this, it would take them… 1 year to complete!
This is just 1 example!
The paradox of “free time” shows precisely why the Platform team needs to exist.
And some companies have a Temu version of such a team.
One client had a few developers assigned to maintain a component library.
Technically, they were the platform team.
But DevOps had their own blocks, and so did frontend.
There wasn’t a person ensuring all of the library’s elements were updated and standardized for all teams.
Let’s look at the rules that make platform engineering work possible.
Platform teams are long-lasting
Like all other Team Topology types, it’s supposed to live parallel to the core team.
Its purpose is to build shared tools and services, maintain them, and teach how they can be used.
Don’t forget about that last bit.
Use one definition of a “platform”
It’s not just the server of cloud infrastructure, as many of us think.
Any technical solution that improves development velocity is a part of the “platform”.
Imagine it as a sandbox.
In it, platform engineers develop reusable blocks IT uses to avoid building from 0.
Understand the team’s responsibility
This new team should practice DevOps culture as it was designed.
Their purpose is to support other IT teams by automating repeatable processes in the development cycle.
The platform team then passes their solution to the stream-aligned team, which is responsible for how it’s used in production.
The team works on internal rather than product goals
They’re not feature teams, all right?
If you see a drop in lead and cycle time, your platform engineers do their job.
It’s the only viable way to show the team’s impact.
Use the optimal team composition
Put at least one full-stack developer and a DevOps engineer into your platform team.
They’ll be able to code, set up infrastructure, create libraries, and do QAA.
But beware.
Keep one team below 5 people to avoid communication overload.
Of course, big organizations can have many platform teams.
Form your own platform team
Startups of 3-4 members won’t have much use for one.
But if your company has 20+ people in IT, this team could help you perfect delivery.
For me, what it does depends on your architecture type.
Monolithic architecture
The platform team can build self-service tools that let the core team:
automate deployments,
simplify environment setup,
manage tests and deployments,
When it’s time to chunk the system into modules, they’ll be the best-fitted to help.
At smaller companies, the platform team can be grown inside DevOps.
But before it becomes a mature unit, they need a mindset switch.
DevOps engineers tend to fixate on infrastructure work until a manager explains what “the platform” stands for.
Microservice architecture
The platform team is best suited to help with scaling a product.
When the feature team builds another service, platform engineers can:
standardize practices,
create starter kits and libraries,
manage the infrastructure,
Without a platform team, the services always grow apart so much that one is needed…
But that also gets my company refactoring work, which is excellent.
Then, the external refactoring team.. acts as the platform team.
Regardless of the architecture, there’s one good job for platform engineers.
It’s R&D.
On the inside, you probably have AI advocates.
But does your IT have an engineer testing AI solutions all day?
Probably not. That’s why AI adoption drags on.
Someone has to dive into it. Test it.
Then, they have to reach a bright conclusion about it.
It’s the platform team that tests new technologies and suggests their application.
Who to recruit
I’d be looking for software engineers with that old-school DIY mindset.
They might come from the frontend, backend, or DevOps,
Regardless of role, what matters is if they’re driven to deliver a fully functional package.
Do you have any engineers who like to do their own tests? 😀
Case studies
Here are just 2 of many practical applications we found for our platform teams.
We built a manual test platform to unload QA work
Problem
As our partnership continued, manual QA testing became a bottleneck.
Regression testing times jumped from minutes to days, making deployments slow.
Solution
Our platform engineers built an automated testing platform and tools.
Under the shift-left approach, developers wrote tests, while QA engineers ran the platform.
Result
QA engineers had less overhead, and developers took greater ownership of code quality.
We standardized microservice development
Problem
Maintaining shared libraries and infrastructure for the client’s many microservices became costly and distracting.
Solution
We created standardized pipelines, infrastructure templates, and client libraries.
These boosted service setup and communication.
We also built a command-line tool used by developers to select which components they needed.
Result
This enabled faster and more consistent service deployment.
Still, our team of 3 people soon had a hard time maintaining this new platform.
Next time
Congratulations! You’ve unlocked a new team type.
To be certain you introduce the platform team correctly, we will look at the stream-aligned team next.
Are you expecting too much from it?
We’ll review what Team Topologies say about its role — and the boundaries it should have.
Thanks for reading today ✌️
Have I covered everything?
The comment section is below.
Published with a smirk by The Software House
Twarda 18, Warsaw, Poland
tsh.io →
 | A guest post by
|
Valuable insights and I really like the form.