In order to scale a platform, it has to become a self-service product with software engineers and managers engaged, taking advantage of new technologies. Olga Sermon spoke about enabling platform adoption at QCon London 2023.
The platform team had to transition from doing all the work related to infrastructure to enabling others to work with infrastructure, Sermon mentioned. This was an easy transition for the team, because it meant there was less toil for their engineers, and more creative work: building new tools is more fun than running the bash scripts by hand, she added.
It was harder to sell this to their users, as Sermon explained:
Many of them still referred to us as "Ops team". At first, they simply refused to invest any effort into learning how the new tools worked, hoping we would go back to doing DevOps work for them. Some even went as far as claiming that we "abandoned them".
Sermon established a stakeholder engagement program with senior engineers and managers across the company, explaining how the new tools can increase developers’ productivity and team velocity. She promised that the effort invested into learning new tools would make them more independent. Eventually, they saw a complete turnaround: in every team, at least a few people were willing to engage with the new process.
In order to be a product, the infrastructure platform needs to act as a product, Sermon explained:
- Self-service: Users should be able to use it independently. The platform team will engage with users, and shadow users while developing the product, to make sure we understand their needs and get frequent feedback. Once the product is in production we expect it to be good enough for the users to be able to operate it independently.
- Flexible: The platform should continuously evolve to take advantage of new technologies and user feedback.
- Optional: We don’t force anyone to use the platform. But they chose us because our platform is suited to their needs; it brings clear value and it is fun and easy to use.
To ensure the platform covers enough use cases to help people, they use a combination of qualitative and quantitative metrics. In the user group, consisting of individuals representing different teams within the company, they discuss their roadmap and upcoming features, gauge their interest, and answer questions and concerns. They also developed a "problem map": for every domain within the platform with a list of problems they would like to address, and asked users to vote on the ones most valuable to them.
Sermon’s advice is to start with talking to your users:
What are their pain points? What are their hopes? What do they need? What do they not need, but really really want?
Come to an agreement on what good looks like, and deliver something that will bring them a step closer to that, Sermon suggested. Get their feedback, and then do it again. It is progress that helps to build trust and engagement, she concluded.
InfoQ interviewed Olga Sermon about enabling platform adoption.
InfoQ: How did you build a platform that is attractive and appealing to the stream-aligned teams?
Olga Sermon: Our first idea was "build it and they will come", where we just build whatever makes sense to us, and hope the users will be happy. You can probably imagine how this went: lots of effort was wasted on solutions no one adopted.
On our second attempt we steered too far in the other direction: we asked the users what they wanted us to build. This went better (they were happier), however, because the users don’t actually know what is possible, this resulted in a range of proposals that were very difficult to implement, and/or would only benefit some users.
The solution we landed on was RFCs: Requests For Comments. Anyone can submit a proposal for a platform feature. All they had to do was explain the context, the problem they wanted to solve, and provide a rough outline of the proposed solution in terms of technology and user experience. We would then publish and socialize this proposal, and let people (both customers and platform engineers) comment on it. This helps us understand how many teams the problem applies to, and facilitates the sharing of ideas: some of our customers were able to suggest solutions we did not even think of.
InfoQ: What do you do to make the platform easy to use?
Sermon: Map out the steps that users have to take, show this to our users, and get their feedback.
There are a few rules of thumb:
- Don’t ask humans to do the computer’s work: ask for the minimum information possible, and use that to obtain the rest dynamically.
- Don’t ask for things you already know: for example, if the user is already logged in, find a way to re-use that authentication rather than asking them to log in multiple times into different systems.
- Don’t surprise them: be consistent throughout systems, it helps to make the user journey easier and to build their trust.
- Measure the usage and provide opportunities to leave feedback from within the application, while their experience is fresh in their mind.