The team at Syntasso wrote a series of blog posts outlining twelve challenges that platform teams face. These challenges include having a small platform team support a large organization, failing to understand the needs of the platform users, and struggling with the build-vs-buy argument.
Abby Bangser, principal engineer at Syntasso, wrote about the challenges that a small platform team can have in trying to support a much larger organization. The platform teams that Bangser has worked on have "hovered around 5% to (at most) 10% of the headcount for the total engineering team". This small group is expected to provide a number of services and tools to a larger organization with the goal of improving developer productivity.
Bangser shared that platform teams can quickly become bogged down in responding to tickets from their application teams. This can be corrected by introducing self-service options:
As a team we aimed to provide self-service options for anything where we were confident to define a good or best practice (see Cynefin framework for more detail).
The Cynefin framework is used to help decision-making. It offers five domains that range from clear to confusion. In the clear domain, problems tend to follow well-defined patterns and solutions can implement best practices. As problems move towards the confusion domain, it becomes harder and harder to define consistent practices and the platform team will be needed to handle the solution with a more hands-on approach.
Christopher Hedley, VP of engineering at Syntasso, wrote about the challenges in trying to buy a ready-made platform. Hedley notes that:
Taking high-level PaaS or SaaS-like platform solutions might buy you productivity gains, but efforts to bend their opinionated workflows to match the will of your organisation often result in frustration or failure. Often you end up changing to meet the needs of the tool rather than the other way around.
Hedley stresses that the better path is a focus on building the platform as a product with close feedback loops with application teams. While off-the-shelf components can be used as building blocks for the platform, as Hedley notes "you cannot buy what only you need".
Bangser wrote in another post in the series that another failure mode is the platform team assuming they understand the user experience and needs without doing the necessary research and collaboration. In the book Team Topologies, Matthew Skelton and Manual Pais outline that an ideal platform is built following the methodologies used to build successful consumer products. This includes techniques such as user interviews, tight feedback loops, and building a platform that delights the users to drive adoption.
Sam Newman in a recent blog post stressed the importance of making the platform be optional for adoption. Newman notes that:
When you make people use the platform, you stop caring about making it easy to use, because they don’t have a choice. You aren't incentivised to improve the user experience to attract people to the platform, as they have to be there anyway.
Similar to Bangser, Newman also worries that platform engineering is not about empowering the application developers by building what they need. Instead, Newman wonders if "it’s about hiding the towering pile of crap we’ve assembled and now have to hide from the people we apparently got it for in the first place."
Michael Coté agrees with Newman and Bangser that "infrastructure builders get easily distracted by building infrastructure when it’d be more helpful to pay more attention to developer usability and needs." Cote also stresses the importance of paying "close(r) attention [to] the what developers need, and track developer-related metrics and improvement".
While the current hype around platform engineering is new, the recommended techniques and approaches are not. As Aaron Erickson, CEO at Orgspace, wrote in a recent piece for InfoQ, "Be a good, dedicated product manager, and get closer to your customer — preferably well before you start building anything."
For more on these platform challenges, readers are directed to the Syntasso blog.