Throughout my career I have had to work with quite a few platform teams, and I was part of two for a couple of years. Some were bad, some were good and some should not have existed at all. I want to tell you my user experience, what I have seen work and what not and what you should definitely avoid doing.
Be The Multiplier
This is the main goal of a platform team. As a team, it needs to be a multiplier. If the platform team supports 10 teams, then each work it commits should multiply by 10. If the team member builds a new feature, it should be helpful for all the other teams. Otherwise, the platform team is an addition, and in most cases it is then better to split the platform team and add them to all other teams, instead of being a separate team. Because the amount of communication needed is in most cases quadratic in relation to the number of teams.
Reducing Cognitive Load
The platform should take away cognitive load for all the teams it supports. By doing so, they will have more time to implement business requirements. Let's say a platform team provides Gitlab runners or Azure Agents where people can run their CI/CD code on. They should not need to know how the runners are scaled, or how the agents are updated. This takes away the need for that skill set in all the teams.
Build a Community
A platform team has a unique position. It is building something that all other developers probably can build as well.
Some could do it even better than the platform team itself. For some platform teams, their ego sometimes comes in to play or just straight up refuses their help because they are not the team. But it is not the job of the platform team to build a product, but a platform where everyone can thrive and/or build on. So onboard the community on the platform!
The Law of Diffusion applies to almost all companies. You will have the innovators that want to build it themselves and the early adopters that will voice their opinion, but will not build it themselves. Those two groups are the ones that the platform teams need, because they want the most optimal solution. If the platform team can guide them to build with them, then they will see in the end that the platform scales beyond their own teams. It will require quite some effort and people skills to get them along, but I see that as part of the job of the platform team. The early and late majority will follow, so they don't require any time. As for the last group, the laggards, make sure to invest some time to sit with them and make them feel heard. From time to time they will have criticisms that are true. It would be a waste to miss that.
If you are going to organize meetings, hackathons, pizza parties etc., don't force the community to join. Make them want to join it. One of the things we did was to listen to the complaints, and make those subjects you can solve during a hackathon. We needed to clear a whole day for them through the managers, but it was worth it in the end. The platform grew because they had the opportunity to solve it themselves when we did not.
Reputation
This one is really important if you start as a new platform team. Your goal is clear: remove cognitive load and build a platform. The problem, however, is that each team is already working in a certain way for quite some while. They might even have perfected their solution. Or it is very integrated in their product. And now here is a fresh team, taking away what is already working. Furthermore, their time is precious, they probably have a backlog list of 300+ items and their PO is breathing in their neck to finish a feature. And then you are barging in, demanding time and taking away a solution that works. You are starting 0 - 1 behind.
This is one of the largest pitfalls I have seen going wrong. You are basically creating a problem that didn't exist before. But you know that in the future all teams will gain from the platform you are building. So how do you handle this: by taking away work they currently have. Let's say you are a new security team that wants to reduce the number of critical and high security vulnerabilities that exists in the packages that the teams use by introducing an artifactory that is quite strict. So how do you get all the teams on your platform? By doing the dirty work for them, create a dashboard that shows the number of vulnerabilities found and then get to work to reduce them for each team. After doing that for a while, then move them to your platform. That is a signal for them to think: "Hey, they are here to help me."
Providing Support
I have seen so many different forms of ticket systems that platform teams would use. The only moment a ticket system is absolutely necessary is when you are overwhelmed with support questions. And if you are overwhelmed with questions, try to figure out why. If it is because you can not give the necessary tools to the devs to solve it themselves, then I can understand why, in all other cases, you have a problem that can be solved.
Having a ticket system creates an unnecessary barrier, it makes it feel like the platform team is in a different company. Or even worse, it will prevent people from asking for support or submitting issues. At that point, you are moving away from providing a platform and moving towards providing a product.
The best way to do this: create a support channel that is visible to everyone. Let everyone be able to post in the channel to ask their most simple or complex question. Make sure to also show the answer. This way, everyone can search through previously asked questions and see if they have already answered, or even better, let AI also train on that channel to help the teams during development. To prevent burnout from context switching, you can create shifts, so that one person at a time can focus on the support channel.
If you want to go an extra mile (and as a platform team if you have the time for it), contact your teams, sit with them, talk with them. Having a personal connection will give you insights you will almost never have. If the company is doing SAFe and you have pipes where the whole department is in the office, that would be the best moment to walk around and see what the needs are.
Be non-blocking
Just as product or feature teams have P1, P2 and P3, platform teams have those as well. I experienced a couple of platform teams that were not willing to run when their platform was down. The platform is down, work has stopped, the company is losing money. Get the platform up and running asap! It is even worse if those developers could have continued if the platform team did not exist at all. Because then not only will they lose time, the reputation of the platform team will decrease, as will the willingness of the community to contribute.
Make sure that if it goes down, the other developers are able to analyze and help. Especially if the platform grows towards hundreds of developers, that means it also increases in complexity. Provide the means for every user of the platform to analyze and create fixes, not directly but through pull request. That will increase the sense of control of the users.
Scaleable Solutions
As said earlier, the platform team needs to be a multiplier. If there are features that will only apply to 10% of the teams, then only provide the means to let the teams build them themselves. That way, the platform team can focus on making an impact for all of them.
Stay Ahead of the Curve
When I was part of the monorepo platform team, staying ahead of the curve was quite important to keep everyone happy. The moment an issue (for example, connection problems within ci/cd agents) started to become a trend, we would drop everything to prevent it from escalating to become a blocking issue. The time between a trend and becoming blocking will get shorter the more teams you have on your platform. As a platform team, you want to prevent creating hacks because all 150 developers are messaging you that they are blocked and can't continue.
To be able to do this: measure everything. Do not only measure the technical parts but also the sentiment of the community. Some things can't be put in to numbers on your DataDog Dashboard.
Their issues are the Backlog
A platform team can't be a multiplier if it builds something no team will use. Get the input every x weeks from all teams on what they need to be able to do their work better and that is the backlog of the platform team. Yes, there are features that the community will not think of, but if the platform team keeps thinking for their community, they will not contribute then.
Final Words
Not all points apply to all platform teams. But next time, when you are part of a platform team and notice that the community is not hooked, go through these points, I hope they help :)
Top comments (0)