How Platform Teams Can Align Stakeholders
“I don’t really know anything about infrastructure. I’m not technical at all, but I’ve been lucky enough to work on a few different clients on infrastructure and platform products.”
That’s how Poppy Nicolle Rowse, business analyst at the Thoughtworks consultancy kicked off her talk at HashiCorp HashiConf Europe 2022. So why should we care about what she’s talking about? Because platform engineering is all about maximizing business value from technical products. It’s about breaking down another silo between business and technology. Platform engineering, at its core, is about bringing engineers closer to business drivers, and about giving businesses a better understanding of the value of technical work.
Appropriately, she was joined on stage by then-colleague and Deliveroo technical lead Chris Shepherd who brought ample hands-on infrastructure experience.
“When we’re talking about infrastructure, we mean all the stuff that devs need to build great products. So security, scalability, performance, all of that good stuff that you need to build all the good stuff on top,” Rowse said.
“But what you tend to see is development teams, infrastructure teams, building the same things again and again, to achieve the same results,” Shepherd continued.
This is where a platform and a platform team can offer these building blocks in a simpler way to reduce waste. But you still need people to adopt it. And not external customers. You have the often bigger challenge of persuading your colleagues to use your product. And for businesses to continue to fund it. Let’s learn from Rowse and Shepherd how to engage with and align stakeholders to achieve platform engineering success.
Scope out Your Developers
“When we talk about users, we mean developers. We mean the teams who are consuming your products,” Rowse said.
That means you should treat your internal customers the same way as you’d treat the paying ones. Except we know most companies aren’t. Puppet’s 2023 State of DevOps Report, which focuses on platform engineering, found that organizations consistently under-invest in product management skills for their platform teams. About a third of respondents didn’t even have a product owner on their team, and about half didn’t have a pure product manager, but someone that was handling that alongside their DevOps or engineering duties.
The report found that embracing platform engineering hinges on adopting a product mindset with tight feedback loops to make sure “that they’re building systems that solve the problems their users face.” The Puppet team found that the same steps are required for a highly effective internal product team:
- User research
- Product roadmaps
- Soliciting feedback
- Iterating
- Launching
- Maintaining
- Marketing
If a third of respondents don’t even have PMs, can you imagine how few have internal marketers or user researchers?
“We actually need to talk to our consumers and figure out what’s most important to them,” Rowse said, which is kicked off via a discovery or scoping phase to figure out what your customer wants. She recommends the agile practice of event storming or model storming, a practice of behavior-driven development that has all stakeholders — including those developer customers — jotting domains on sticky notes, then grouping them together and organizing them into logical processes. It’s called a storm because it kicks off a bit chaotic but then creates a safe environment for all ideas to be considered. It can be done co-located on a wall or on a visual collaboration tool like Mural, Miro or Jamboard.
“You want to put all the different pain points. This gives you a beautiful visual heat map of, ‘Okay, we can see the areas where there’s a lot of pain points going on. This is where we maybe need to focus some of our efforts’,” Rowse said, recommending running event storming sessions not just at the start of your platform engineering journey, but once it’s live-in-production as well as running day-to-day.
Plan for Each Persona’s Pain Points
“I know your users are developers, and I know a lot of you are developers, so you think, ‘OK, I already know what’s the best thing and what’s most appropriate here.’ But actually not all of the users are the same,” she said. Embedding on dev teams or borrowing devs to help build the platform are ways to overcome platform engineers assuming what the dev teams want.
From the start, Rowse reminds us to get a wide range of stakeholders talking: “Talk to different teams. Talk to your teams that have been running for five years. Talk to your new teams who are spinning up brand-new products from scratch. Talk to your people who are brand new to the organization. Talk to the people who’ve been there for years, and just get that broad range. Get them all in the same room. Do the event storming with them all at once.” Or else, she continued, “host asynchronous sessions and compare maps to find where they differ and where they are repeating work” — which often becomes first priority.
Rowse then makes an interesting point that just because it’s a shared pain point, doesn’t necessarily mean the platform team has to create something new for it. The platform team may just facilitate a conversation where learnings are shared across teams.
It also will vary by team, which is why she recommends building different customer personas. Infrastructure experts may just want to continue to build their own thing, while your front-end developers — that suddenly have to learn cloud engineering outside of their job descriptions — are “really frustrated at the process and don’t necessarily have the skills or capabilities to deliver infrastructure stuff themselves and spin up things themselves.”
If platform engineering is new to your organization, Rowse advises: “Be really purposeful about the scope and who you decide to be your customer. It might be that you’ve got a load of legacy stuff, and, actually, it’s a bit too mangled and awful to migrate over [to the cloud], so actually you’re going to focus on building infrastructure products that can really accelerate the delivery of your newer products. Or it might be that, actually, you’ve got a handful of products being built and they’re the top priority in your organization, so you’re really going to narrow in on those ones and make sure that you’re supporting the delivery of those products.”
Remember, at the end of the day, it’s about increasing the business value of engineering.
“And don’t assume that people are just going to come because you’ve built this fancy thing and you’ve spent loads of time on it,” warned Rowse.
This means continuously interacting and asking for feedback from your developer customers, especially during the build stage. Check that you’re building what they want and can use, she advised. The more you invest in engaging with them, the more they are going to be ready to use it — because the more it’ll suit their needs.
‘Architectaeology’ and Alignment
As a platform team is meant to serve several or all developer teams, it’s important to align cross-organizational values and then document and over-communicate any architectural decisions based on them.
Rowse said to kick off with a shared strategy like the lean value stream mapping:
- Vision
- Measurable, achievable goals
- Bets, the deliverables to support the goals
“The things that we might actually build are actually quite different depending on your vision,” meaning alignment around vision is key, Rowse said, clarifying what you want to get out of your infrastructure platform. “Maybe it’s cost. Maybe it’s just pain points from all your different developers and keeping your developers happy. Maybe it’s that you don’t have capability within the teams so you need these centralized products that are super easy to use.”
She also offered an adapted version of Scaled Agile Framework’s Weighted Shortest Job First (WSJF) as a way to take the objectivity out of privatization, looking for the biggest wins with the least amount of effort needed.
“This is so important, not just to get that priority, but also to get that alignment and make sure that actually all your non-technical stakeholders really understand the value you’re going to deliver here. And because you’ve spent that time doing it, you are fairly confident that that is going to deliver your vision and your strategy,” Rowse said.
Shepherd also emphasized that the platform team has to communicate out to the widest stakeholders. Diagrams, documents and Wardley Maps have to be circulated early and often.
The platform teams should outlive product teams, he remarked, “because you’re building stuff on which other teams are going to be running their stuff, right?” And staff changes pretty fast in tech. In order for an organization to adopt a platform mindset, he says you need to embrace “architectaeology” — which includes documentation about why the platform was built that way, the roadmap and the technical vision behind it.
“This is forward-looking, but also backward-looking, to help engineers in the future understand the decisions that have been made and the thing that you’re building,” Shepherd said, pointing to the C4 model as they best way to visualize “architectaeology”:
- Context diagram – describes at a very high level
- Containers diagram – zooms in on various components and how they connect
- Components diagram – how to use and configure in your environment
- Code diagram – entity relationships and classes, especially when building your own, highlight quirks
Not every diagram speaks to every stakeholder, but, as pagers pass and roles change, this architecture will always be valuable to someone.
This is also supported by architectural decision records, in your code repository with:
- Decision
- Date made
- Context of why
- Decision
- Consequences (can include licenses or subscription)
- Who was in the room
If You Build It, Will They Come?
It’s all well and good for stakeholders to be aligned, but will your developer customers actually want to use your shiny new, value-driven platform? And how usable is it, anyway?
“Time spent with your users is really valuable,” Shepherd said, “but time spent with your users to have to onboard to your system is wasted effort.”
From the start, he argues, you have to aim for a self-service experience, especially in onboarding. Whenever possible, this should be achieved via “one and done” where ideally users only interact with the operator one time, or, at least, reduce the operational steps down to a minimum.
And, of course, he says, eat your own dogwood and go through every step like onboarding to make it as smooth as possible.
Keep a Minimum Viable Product mentality and build enough to gain feedback and then iterate. Because, just like an external-facing SaaS product, your success in platform engineering hinges on having users.
