Platform teams — when to build and how to make them successful — Part I
When is the right time to build platform teams and how to make them successful at working along with business areas? this is the first topic of the short series of articles — Organising work into teams.
The series will cover designing organisations, aligning customers and serving areas, understanding the necessary talent, outputs, roles and responsibilities and sizing teams correctly, and why managers and leaders should care about it. If you want to know more about me here's a post!
This topic will be divided into two blog posts, the when & the how and measuring success.
The when—the front-liners awakening
To start, let’s introduce the concept of front-line engineers.
Usually front-liners are coupled with the business, on a daily basis they interact with data scientists, business analysts and work driven by business KPIs, you know CAC, LTV, Churn and all that Product Manager’s stuff.
There are some symptoms that help you to understand if your organisation needs platform teams and it's something that only the front-liners will know for sure.
They start spending too much time figuring out details like configuring IAM roles, long hours writing CI pipelines, automatising their own work and then organically, they start forgetting about the business KPIs and proposing objectives in other directions. And since they’re not necessarily opposing ones, it becomes less clear for product managers why engineers want to work in things not directly related to the business.
If you’re a front-liner and nodding while reading this, you may want to show this article to your favorite product manager.
And this is the when platform teams start to appear, sometimes in a form of sub squads in the same front-line team, because it takes time moving people around, and that’s fine. And other times it is crystal clear for upper management the importance of having these platform teams in place.
The platform — responsibilities
These teams’ job is making other teams more productive, by unifying the development experience, building and sponsoring a curated set of technology and tools. And avoiding duplications across front-liners.
The result at the end is solving common pain points across front-liners teams. Some examples are, alerting systems, clusters to process data or even SDKs to simplify data transformations.
Cool! We have a platform team in place, so getting back to front-liners. If they have a business need or found an opportunity using the newest cool tech in the market but is not part of the core of their team/squad, usually what happens is that they start asking the platform to own that.
Sadly for them, that’s not necessarily true, not because a platform team does "platform stuff" that everything that it's outside core of front-liners, should be something for that platform team to do immediately.
Platform teams should aim to cover 99% of the most common pain points, the other 1% it’s going to appear in the front line. And it's fine!
The reality is that front line engineers mustn’t be depending on other team priorities if they already know how to improve their KPIs. Of course the burden it’s on them to maintain the new technology stack with less experience and resources, but for the short-term they should be fine with that.
Sometimes I heard things like “not my responsibility” or the euphemism form “it’s going to be more efficient if the platform became the owner of this.”
But following the timeline, part of how to make a platform team successful is by respecting their responsibilities.
Unfortunately, often you see front-line engineers getting needy and lazy, for example when a stack trace appears in front on them they will call platform engineers right away, throwing to them the error without even google it, just because they saw something like:
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed — JavaScript heap out of memory.
“Give a man a fish, and you feed him for a day. Teach a man to fish, and you feed him for a lifetime."
Working together
Platform teams shouldn’t be troubleshooting other teams’ applications, not only because it isn’t their responsibility or because they don’t have enough context. It's because this kind of behaviour incentivises the culture of blame which can be very harmful for any kind of organisation.
And rather than spending time babysitting other teams, platform teams should simplify front-liners’ lives for example, by making less scary reading stack traces, have great tools to troubleshoot and plug alerts easily, but the most important part, they shouldn’t babysit all the time, incentivising culture of ownership.
If you’re a platform engineer and you’re nodding while reading this, you may want to show this article to your favorite front-liner that keeps asking you for a quick debug.
Well, I’ll drop here, hope you liked it! — and don't take me wrong, front-liners and platform teams are on the same boat, but they should share the same values, respect responsibilities and pursuing good incentives.
See you in the next post! A deep dive into measuring the success of your platform team.
