How to Host Your Own Platform as a Product Workshop
Often, when organizations start talking about platform engineering, it’s not necessarily about getting started. After all, most companies already have some form of platform. It just likely will have low adoption rates because it’s been a top-down initiative where operations is throwing something over the silo.
That should change when organizations adopt a Platform as a Product strategy. This practice embraces the socio-technical side of platform engineering that considers the intersection of people, processes and technology — not just the latter. This mindset shift is about focusing first not on building internal features, but on serving and engaging with your internal developer customers. Perhaps most importantly during a time of tech layoffs, this practice focuses on learning to solve complex problems using the platform technology — so not thinking tech first, but problem first.
Anna Ciula and Cansu Kavili Örnek consult with Red Hat customers to help them build fit-for-purpose platforms that embrace this platform engineering mindset. Red Hat’s Open Innovation Labs team has developed and open sourced a half-day Platform as a Product workshop. At WTF is SRE, the team’s engagement lead Ciula and architect Cavil Örnek reflected on their last two years leveraging this workshop to help teams get the most out of their platforms.
Platform as a Product Delivers DevOps
You might’ve read that DevOps is dead. While a catchy headline, platform engineering is seen as finally the delivery mechanism of DevOps.
“What I see is that platform engineering is the natural extension or natural next step to DevOps implementation — like the mature version of DevOps. Because the technology got super complicated and there’s this overhead, new things coming up every single day that developers need,” Kavali Örnek said. “Platform engineering is here to provide them with some common, reusable capabilities to take this cognitive load from them so that they can actually focus on what they like to do — the business applications, developing the software.”
With the DevOps is dead mindset, she fears, job titles will change, but the ways of working will stay the same. In order to address the challenges highlighted in Puppet’s State of Platform Engineering Report — including cycle time too slow, resistance to platform team adoption, and lack of communication — these teams must adopt a Platform as a Product mindset, a term coined by Team Topologies.
“Applying this modern product management mindset into the building of platforms,” she defined Platform as a Product, admitting this is a “big hard shift from focusing on the underlying technology of the platform, but, instead, focusing on what are actually user-developer needs, and building that platform around them.”
The Platform as a Product workshop is designed in response to common challenges Red Hat customers have shared, Ciula explained. “We saw the devs being utterly frustrated with the ops throwing all the obstacles under their legs. And then, ops being utterly frustrated with developers calling them stupid because they don’t know how to use the platform.” These reactions have all led to ops deferring to command-and-control mandates to use the platforms and, what she called, “the shadow IT rebels creating their own clusters somewhere on the credit card.”
Like all of platform engineering, this workshop looks to create a common language and get everybody on the same page, with all stakeholders buying into the benefits of a Platform as a Product mindset.
Wait, What Is a Platform?
Your Platform as a Product workshop is only useful if everyone can be useful to is at the table. This would be users and customers, but also who Ciula calls influencers like the compliance and security teams. As we wrote about before, platform engineering abstracts out what Syntasso’s Abigail Bangser calls “non-differentiating, but not unimportant work” so that app teams can focus on delivering business value faster.
After a brief introduction, this workshop has all those stakeholders prioritize your challenges to platform engineering success, including:
- High developer cognitive load
- Developers don’t trust and don’t adopt the platform
- Poor developer experience
- Customers are suffering bad services
- Platform is too expensive
- Platform is too slow to change
Contrary to its name, DevOps has mostly focused on operations, while this workshop highlights both the developer experience and the end customer experience more, as well as connecting the whole platform initiative to the business.
“This is usually a very very helpful discussion,” assured Ciula, but, particularly with regulated environments, she warned, “it tends to be heated because people have different views of what’s more important.”
That’s why you should allow enough time to get everyone focused on the biggest problem, without letting the conversation derail.
Next, you break out the virtual or very sticky Post-Its and clarify as a group:
- What is a platform? (It’s a single pane of glass.)
- What is not a platform? (It’s not just Kubernetes.)
- What does a platform do?
- What should a platform not do? (It’s not a catch-all that supports all edge cases.)
It’s essential, Kavali Örnek said, that all stakeholders are in the room so you don’t just have an ops view or a dev view — anyone who would benefit from the platform should feel represented.
“This helps us draw the boundaries around what this platform is going to look like and what this platform is going to be responsible for,” she said. “It’s really important for everyone to understand what this platform is and what sort of problem we are trying to solve.”
What Is a Platform as a Product?
“Typically, everybody here knows what a product is, that it is solving a problem or [is a] response to a need,” Ciula said. But it’s important to reiterate that “It has to be feasible. It has to be technically viable. It has to be desirable.”
This relies on everyone understanding the distinction between a features team and an empowered product team — platform engineers will solve the problems but not necessarily implement the solutions.
“Empowered product teams are handed problems to solve and not solutions to implement,” she said.
This enables teams to apply this product lens onto the platform, which has a distinctive business skew. Most often, goals include reducing: time to market, operational burden, and/or developer cognitive load.
“It should be built for developers, with developers, responding to their basic needs,” Ciula said, “and obviously it needs to be technically feasible.”
She pointed to this as an “ah-ha” moment, when “a lot of our customers are saying ‘Shit! No one is really doing this. We don’t really have a platform product manager whose job is that to make sure that we’re doing something for the business’.”
Furthermore, she receives feedback that the platform teams weren’t really thinking about the developers and the services they need, beyond educating them on how to use the platform.
One of the first steps to treating the platform like a product, not just like another top-down Waterfall initiative, is by having a product backlog.
“In that backlog, you don’t just put things about building and maintaining the platform,” Ciula said. Internal marketing is just as important: “You have to think about things like evangelizing your product, making people want it more.”
This not only helps create transparency for developers, but, once they get word of the platform, requests will come pouring in. That backlog helps manage your internal users’ expectations.
“We want developers to come to our platforms. We don’t want to make their lives miserable. This evangelism and understanding what they actually need, what they want,” Kavali Örnek said. Pointing to one of the three pillars of DevOps, she emphasized that “It’s really important to have this conversation and feedback loop with them.”
Next, the workshop applies Team Topologies’ four characteristics of a product to the platform:
- Optional to use
- Carefully designed and curated to user needs
- Simplifies something for users
- Evolves alongside technology
For each of these points, ask yourself, can this be said of your current platform?
Of course, especially in regulated environments, Kavali Örnek hear nays in terms of optionality. And that may be fair if regulations and security cannot be optional. But, this exercise is really show all stakeholders that “you should build your platform in a way that developers want to use it,” she explained. “It should be so compelling that they don’t want to look for any other alternative. They want to use your platform.”
Otherwise, you’re facing what she calls the Empty Cluster Problem, where a few applications are on top of it, but the majority of your app teams are not on board with your platform.
“This platform is optional. We’ve got to make it so good and we will listen to them and they will come and use it and hopefully evangelize for us internally,” Kavali Örnek said, setting the ideal objective for platform teams.
Creating Platform Metrics that Matter
The third module for this Platform as a Product Workshop comes down to measuring success. Typically, when running this workshop, the Red Hat team finds people are simply measuring velocity, story points, and number of defects, which Ciula dubs a bit disappointing.
While the DORA metrics — deployment frequency, lead time to changes, mean time to recovery, and change failure rate — are considered an industry standard, rarely her customers are applying them. That means a lot of this 15-minute module is an aspiration.
“We want to reiterate to them that platform should do something for the business,” Ciula said. “The platform is not just for technology. It is supposed to deliver something that can have a measurable outcome on the business.”
Beyond DORA, this workshop encourages consideration of platform adoption rate, developer onboarding time, developer net performance score,
“We want to leave them with some food for thought so that once they get serious about the platform and they buy into this approach of Platform as a Product, they do it properly.”
Mobius Loop for Continuous Feedback
While there are other modules available in this workshop, perhaps it’s most important that it ends on the next steps, so participants are ready to take action.
Red Hat has facilitated the creation of an open practice library around an iterative delivery cycle with a tighter feedback loop, as portrayed like a sideways figure eight or infinity symbol. This Mobius Loop pulls from DevOps, agile, design thinking, impact mapping and human-centered design, among others, so teams can choose the relevant practices for each situation:
- Why are you solving a problem?
- Who are you solving it for?
- What are the problems being solved?
- How can they be solved?
Then, they can design and then implement experiments they believe can solve the outcome. It’s a continuous discovery and delivery journey. In part, Ciula explains, this is to make sure that the platform team doesn’t get stuck on just delivering features without taking time to revisit the discovery phase.
In the end, Kavali Örnek argues, a successful Platform as a Product strategy hinges on organizational psychological safety, which is why the Mobius Loop contains both technical and cultural practices for the sociotechnical practice of platform engineering.
Images by Ana Ciobotaru.
