7 Aug, 2023
Most of these frustrations stemmed from how the team was operating, which didn’t match how I thought a platform team should operate. A platform team should provide internal services (through infrastructure, tools, wikis or other resources) that enable software development teams to build and deploy software more efficiently and effectively. What happens when your platform teams aren’t doing this? Keep reading and I’ll give a couple of examples, and also some tips on building ’real’ platform teams that actually help your organisation and software development teams.
One of these frustrating experiences was when I was in a ‘devops’ team, who rebranded to a ‘platform’ team, in order to try and reap some of the benefits of having platform teams and focus on more self-service tools (to reduce dependency on those of us in the Devops team). Up until this rebrand, the main interaction modes for software dev teams with the Devops team was via a jira ticket/slack. People would raise a request, with a problem/request for resources, and the team would respond to these requests one by one. Occasionally we would be invited to consult on bigger projects, and provide on-call support, but that was about it. So how did this interaction mode change when we transitioned to a platform team? It didn’t, instead now there were a couple of senior devs building some cool tools they thought would be helpful. Most of us were still just responding to requests, because they were still coming in.
Another frustrating experience was in a very technically competent cloud team. They had great engineers, who all knew what they were doing, and had built a really good cloud ‘platform’ as a foundation for other teams to use. As the demands on the platform grew, and the cloud team expanded, the work that was prioritised was based on what the team thought their platform needed. Whether this was a faster process to deploy AWS accounts, or a more streamlined way to deploy VPC’s for new teams, they updated processes/added new features based on their knowledge and experience of what good looked like. The problem was, there wasn’t really much interaction or feedback from the ‘customers’ of this platform (i.e. software development teams). Things weren’t on fire, but the team was unable to make the lives of software development teams easier because they weren’t talking to them.
From looking at both of these experiences, and with the benefit of hindsight, I see similarities in the problems the teams experienced:
Work was being prioritised and decided upon by those in the team either managers/seniors
There was no consultation/feedback from ‘customers’ - i.e. software dev teams around what they wanted
There typically wasn’t much measure of effectiveness once these new tools/features had been provided by the team - how do we know if we are solving problems
The platform teams were typically working quite ‘siloed when delivering their platform’ - i.e. not much collaboration with the software teams
If we look again at the purpose of a platform team, which according to Matthew Skelton and Manual Pais’ book Team Topologies is ‘to enable software development teams to deliver work with substantial economy’...do we think the above examples are helping achieve that purpose?
What I see as really missing in both of these examples is applying the product management mindset to the platform that is being built. All tech companies should have a great understanding of product management (most of them are delivering some sort of tech product to market). Why are we not taking more of these approaches when building platforms? Why are we allowing these platforms to be built from within, with very little feedback?
Again this doesn’t apply to everyone, ‘not all platform teams’ I hear you yell, some mature platform teams are great and are already working in this manner, but not all.
So where do we go from here? If you are in one of these topsy-turvy platform teams, that isn’t really servicing customers, how do you come back from the edge? Here are some of my ideas:
Talk to your customers - I know, I know, very obvious. But just like if you were building a new product in the market, you would talk to people to understand their needs and problems. Talk to the different software dev teams in your organisation to gain an understanding of their skill sets, priorities and pain points. Yes they may vent at all the problems you aren’t fixing, that’s ok, use this as valuable data to help inform the future of your platform.
I know some teams might use tools (like surveys) to gather this data if you have many software dev teams, but don’t forget simple conversation (both in person and virtual) goes a long way.
Understand your priorities - After chatting with your customers, you will probably have a whole bunch of items and ideas to make your platform better. These will form your product ‘backlog’ as it were, however not all of these items will have equal priority or size. This is the tricky bit, understanding rough sizing and priorities.
Priorities will really depend on the goals of your platform, and these goals should be driven from your customer’s needs. Are you trying to increase self-service for teams because they are time poor? Increase resiliency because your customers keep suffering outages? Reduce costs? Depending on the outcomes your platform is trying to achieve, will affect the priority order of what you work on.
Estimating can feel like a naughty word in teams that haven’t done this before, the main thing to emphasise is that these aren’t used to hold people accountable. It’s to get a very rough starting point for how big something is, yes this may feed into a high level roadmap, but especially if the teams haven’t estimated before…it’s not going to be accurate anyway.
Hopefully, overtime, the team will better understand the platform and the work involved to do things.
Create a roadmap - Once you have a ‘backlog’ of items prioritised, this is the perfect time to create a product roadmap and socialise this amongst your organisation. Don’t put super strict timelines that will freak people out, highlight what are the key goals for the next month/quarter, why they are next up and what benefits/outcomes this work will achieve.
Get feedback - Just because this is the last dot point does not make it the least important, this is the only way you are going to get people to continue to engage with and use your platform. Team needs evolve and change as your organisation does, so your platform team needs to be across this. And this isn’t just feedback from the software development teams either, from leadership in your organisation and other parts of the business. Are there any big future changes that might impact how you deliver a platform? Are there budget considerations etc.?
All of these ideas aren’t new or ground breaking, they are all within the realm of product management, that the tech industry has been doing for many years. These are just some thoughts around how to bring these skills and focus them internally, to make your platform as effective as possible.
Something I’m cautious of in today's tech environment are fake platform teams. Like the ones described here, they were called a platform team to…but without a focus on the customers! Like the examples, often the focus is just on the technology rather than the problems it’s solving.
I’m going to leave you with some ideas from Matthew Skelton and Manual Pais’ book Team Topologies. They say that a good platform is just big enough. A well-designed platform can be a force multiplier for software delivery, however care needs to be taken to ensure that the platform always serves the needs of consuming applications and services (not the other way around). Therefore teams should focus on building the thinnest viable platform, this could just be a list on a wiki page of components/services.
Start very small and focussed on your customer needs (sometimes just a wiki will do), even though it might not be what you expected your platform to look like. The platform itself should not dominate the discussions, rather the problems you are solving for software teams. Treat your platform as a product that is to be consumed and manage it as such, to make sure your customers are able to be as autonomous as they can.
.png){kind=logo}
