Platform team challenges
Posted 24 July 2023
In an engineering department with many teams it becomes necessary to look to standardise on solutions to common problems for both consistency and development speed. The approach of introducing a "Platform team" to take ownership of these shared solutions can help solve issues around maintenance and direction of these projects but also introduces new challenges.
Why create a platform team?
Development teams, from infrastructure to application development, face a variety of common challenges. To boost productivity and ensure consistency, it's essential to standardise solutions for these issues. This approach speeds up development, reduces maintenance costs, facilitates team mobility, and supports business-driven needs such as UI branding and GDPR compliance.
Initially these solutions can often be shared on an ad-hoc basis - whether it's copying code, introducing shared libraries or hooking into another team's API. But allowing these systems to grow organically with no overall direction, no accountability for long-term maintenance and unclear knowledge transfer can quickly make them time-consuming to work with and sometimes impossible to use. Forming a team responsible for these solutions, often called a 'Platform Team' can help solve this - but introduces a new set of challenges.
Prioritisation
One early issue faced by a new platform team is prioritisation. Given the numerous engineering teams that depend on the platform, the team can easily get pulled in various directions. The key question is: How do you decide what to tackle first?
Having a Product Owner is crucial for engineering teams, especially those following Scrum. However, finding the right person for this role within the platform team is challenging. They must possess a good technical understanding of requests from engineers while also being knowledgeable about business priorities to effectively prioritise across business initiatives. In reality, it's often difficult to find someone who can both fulfill this role and have enough time to do it.
One approach is forming a committee to make high level prioritisation decisions. This could be made up of individuals including senior engineers, architects, product managers and senior management. However this group can't meet frequently and there still needs to be someone empowered to make day-to-day decisions on priorities and scope of work, be that a senior engineer or manager that works closely with the team.
Scheduling
Despite having set priorities, a platform team can still become a central point of failure and obstacle for project delivery. Continuously hearing that projects are blocked due to the platform team is disheartening and detrimental. While the primary goal of a platform is to enhance delivery speed, mismanagement of cross-team dependencies can lead to slowdowns.
A useful approach can be employing "fixed time projects", like with Basecamp's Shape Up. Committing to fixed time limited scope projects can help provide clarity on what a team will and won't deliver over a longer period of time than short sprints. The idea of a 'Betting Table' can also fit nicely with the prioritisation committee approach too.
If your platform team is always swamped with multiple initiatives, it's time to rethink things. A good platform should speed up engineers, not slow them down with blockers. Flexibility is key! Make common requests self-service with clear documentation. The platform team could be like helpful 'consultants', supporting other teams with system design and code reviews instead of taking on everything.
Don't get stuck being constantly reactive to new feature requests. Focus on making changes easy for other engineering teams. Let them solve challenges using the tools and frameworks you provide. This should drive most of the platform team's work to end up being those major new additions or changes.
Building things people actually use
As a platform team your primary mission should be helping other teams solve problems. However by forming a separate team it's easy to become detached from the issues other engineering teams are actually struggling with.
Having someone as a Product Owner can make a huge difference. Avoid getting carried away solving problems with solutions that the teams you support don't actually want to use, whether that's because they don't work for their use case or the problem isn't a priority for them.
Remember that the platform is a product and other engineering teams are your customers. Aim for them to want and choose to use the platform, not be dictated to. Find a way to stay customer-focused and re-evaluate your solutions if adoption is low before considering ways to "enforce standards".
Sharing too soon
With the addition of a platform team there's now a home for all the great ideas that a wide range of individuals will want to push for as "universal solutions". Resist the urge to share too soon!
Getting the right level of abstraction for a shared system from a single solid use case is impossible. Committing to a shared implementation too soon can lead to a confusing API with additional options tacked on as new requirements are encountered. Making breaking changes with multiple consumers is expensive.
It's good to be aware of the potential for a new platform addition early, but let engineering teams have the autonomy to solve problems themselves even if there is a potential for a platform level solution later.
I've found the rule of three to be a useful approach for defining some guidelines to follow when deciding whether to add a solution to the platform: "a reusable component should be tried out in three different applications before it will be sufficiently general to accept into a reuse library".
- First request: just solve it yourself
- Second request: let's look at existing solution and collaborate on system design, still implement it yourself
- Third request: implement a platform level solution that supports all three use cases
Replacing legacy
If you've formed a platform team it's probably because there's some number of shared solutions that have evolved organically and likely fallen victim of a lack of ownership, system design and maintenance. These systems might be a nightmare to work with, poorly documented and be running on beyond end-of-life software versions. The call to tear it down and re-write it from scratch can be incredibly tempting... and risky!
Chances are, a complete replacement won't necessarily be better, especially from your users' perspective. Battle-tested production solutions, despite being messy, often carry the weight of complex business requirements accumulated over time.
Worse still there's a good chance it won't ever fully replace the old system, especially if it's used in multiple places. Migrating to a new system creates work and risk for other teams. If there's only a partial migration you've now doubled your maintenance workload, supporting two systems instead of one and managing a divergence of capability between the two.
Absolutely identify the ideal solution but focus on incremental improvements to the existing one. Alarm bells should ring when a re-write project is suggested. Understand the current system better, document it thoroughly, and create automated tests to boost your team's confidence in making changes.
Of course, sometimes a major replacement is unavoidable and justified, but be cautious when scoping the work. Consider everything beyond just the implementation phase—supporting migrations, proper validation, documentation, and convincing other teams to prioritize the switch. Don't rush into a rewrite without a solid plan. Incremental improvements might just save you from unnecessary headaches down the road!
Becoming a knowledge silo
It's also very easy to become a silo disconnected from the day-to-day issues other teams face when using the platform. Defining a team brings a group together with a shared focus, but also draws a line between us and them that can bring about conflict.
It's important to keep talking to people and reaching out to hear about their issues. Engineers don't want to be blocked and they'll often workaround issues with your solutions rather than talk to you about it if you haven't built those relationships.
Building connections is vital. Encourage open communication and make it easy for others to approach you. One effective technique is to share platform knowledge through engineer rotation. As team members shift, they bring fresh perspectives and valuable insights from their previous experiences.
Foster a culture of collaboration by welcoming code contributions from across the department. Your users can provide unique perspectives and valuable input for improvements. Remember, the platform team may be responsible for solutions, but engineers throughout the organisation are more than capable of contributing to its growth.
In the end, collaboration and open dialogue will lead to a stronger and more effective platform team. Embrace the power of shared knowledge and perspectives for continuous improvement.
Conclusion
Introducing a platform team is a great way to establish clear ownership over shared solutions, but it also comes with its unique set of challenges.
To succeed, treating the platform as an internal product is crucial. Finding the right person to fill the product owner role is essential for smooth operations. Collaborate with other teams to create a platform that engineers genuinely want to use.
Remember, documentation is just as, if not more, critical than the implementation itself. Prioritize getting the API design right, implement it swiftly, and then shift focus to crafting detailed and comprehensive documentation.