This post discusses some of the common issues around platform teams.
In my previous post Importance of Developer Experience, I talked about platform teams, their value in engineering org and the importance of developer experience. There is a lot of buzz lately around platform teams, drawing a comparison with DevOps/SRE teams and highlighting the benefits.
But being a member of platform teams in multiple organisations, I came across certain problems that are difficult to navigate through.
Celebrating Wins
Projects the platform team take on are usually long term. If it’s a larger org, then adoption becomes slow. As compared to product teams, which start to get instant feedback from a large user base, the platform releases take time to conclude whether they are a success or not. Other factors like an increase in support requests, outages etc also contribute to delays in releases.
During this long period, the excitement and motivation level often drops. Thus it becomes really important to celebrate wins whenever possible.
Another friction in celebrating wins is understanding whether it is a win or not. Product teams, usually have clear-cut metrics to measure success, which is often missing in platform team releases. Few examples of metrics
- Improving Observability? Can measure MTTD(mean time to detect), MTTR(mean time to repair)
- Setting up CI/CD? Time to complete, number of deployments, failures, number of downtimes etc
Bottleneck
In fast-growing orgs, the platform team often ends up becoming a bottleneck for different product team releases. Depending upon the level of automation, product teams have requirements from access rights, infrastructure creation, observability setup, networking issues etc.
There will always be a dilemma to follow the right approach or hack your way to release. You don’t want product teams to delay their release because of a lack of available automation/product as it can directly impact the business.
IMO, following the principle of “Convention over Configuration” helps bring in standardisation, which in turn cuts down a lot of unnecessary decisions. Implementing “Convention over Configuration” can be in any form, be it documentation or automation.
CatchAll
Anything that is not in the path of the product team's development routine often ends up as a platform team support ticket. This increases a lot of Ops/Support work for the platform teams. Managing support tickets sometimes requires separate sprints or even separate teams.
Having been on one of these teams, I realised, the majority of support tasks are simple and could be done by developers raising the ticket. This often happens because of the lack of clear ownership among teams. There are ways to avoid it, like decentralised teams, clear ownership, education and playbooks.
Thats all folks! Is there any other problem you have seen or experienced with platform teams? Let me know in comments!
Any feedback is welcome. You can catch me at @adityachowdhry
Top comments (0)