If there’s one thing a platform engineering team doesn’t lack, it’s ideas. When your customers are your colleagues and friends, you have an ever-expanding wishlist to improve developer experience — you only have to ask!
But as with any product team, you have limited resources and the need to balance both business and engineering objectives. So many stakeholders inform your developer experience roadmap that it can be difficult to prioritize.
Yes, you need a roadmap
The biggest thing that distinguishes platform engineering from the top-down platforms of tech days of yore? Nobody has to use it.
When you’re building any developer experience tooling — whether it’s an internal developer platform or portal or just a directory or better documentation — you have to build something that your engineers actually want to use. Your platform strategy — sometimes called a developer experience or DevEx strategy — should make developer lives so much easier that they need a really good reason to go off that golden path.
Platform engineering requires a Platform-as-a-Product mindset, packed with user-centric design, prototypes and demo days. Your colleagues become your customers.
You not only need an internal product roadmap, you need to actively publish it within your organization. This way not only are you making commitments to solve your developer-customer’s problems, you are closing that feedback loop, so your platform team knows early and often if you’re building something that they even want or need.
Know your stakeholders
Perhaps even more than when you are working with external users, a platform team, as stewards of the developer experience, is beholden to many stakeholders.
As Sergiu Petean from Allianz Direct pointed out, a common anti-pattern for platform teams is only addressing the single stakeholder of the software engineer. The larger the enterprise, the more regulated your industry, the more stakeholders you have to consider from Day One.
At the insurance giant, his team initially highlighted eight different stakeholders that all bring different demands:
- End users
- Quality
- Security
- Software delivery
- Data
- Sustainability
- Incident management
- Compliance
Later they realized the platform has the capacity to interact with even more teams.
Work to build a relationship with each of your technical and business stakeholders. Learn what part of the software development lifecycle matters most to them. And then bring them into your feedback loops that impact your platform engineering product roadmap.
Learn to prioritize
The more stakeholders you identify, the even more feature requests you’ll receive. Yet, according to research by DX, the average team focused on developer experience is a fraction of the whole engineering org. That can seem overwhelming, but a platform engineering strategy is all about centralizing and solving frustrations at scale.
How can you possibly balance so many conflicting demands? HashiCorp’s platform engineering lead Michael Galloway recommends looking to remove the pebble in their shoe.
The biggest points of friction will be an ongoing process, but, as he said, “A lot of times, engineers have been at a place for long enough where they’ve developed workarounds or become used to problems. It’s become a known experience. So we have to look at their workflow to see what the pebbles are and then remove them.”
Successful platform teams pair program with their customers regularly. It’s an effective way to build empathy.
Another thing to prioritize is asking: Is this affecting just one or two really vocal teams or is it something systemic across the organization? You’re never going to please everyone, but your job in platform engineering is to build solutions that about 80% of your developers would be happy to adopt.
Go for the low-hanging fruit
Another way that platform engineering differs from the behemoth legacy platforms is that it’s not a giant one-off implementation. In fact, Team Topologies has the concept of Thinnest Viable Platform. You start with something small but sturdy that you can build your platform strategy on top of.
For most companies, the biggest time-waster is finding things. Your first TVP is often either a directory of who owns what or better documentation.
But don’t trust that instinct — ask first. Running a developer productivity survey will let you know what the biggest frustrations are for your developers. Ask targeted questions, not open-ended ones. You can get started inquiring about the 25 drivers of developer productivity — which socio-technically range from incident response and on-call experience through to requirements gathering and realistic deadlines.
Mix this with informal conversations and pair programming with your devs to uncover big and small problems that need solutions.
As startup advisor Lenny Rachitsky suggests, you can rate each idea from 1 to 5 across the X of how impactful it’ll be to solve a problem and Y of how much effort it’ll take. Just make sure anything that shows up on that “guesstimation graph” meets the requirement that it solves a problem for a majority of your developers — because a platform team should never work for just one dev team.
Don’t forget to value quick fixes to help ease some pain. Following the agile practice of “walking the board,” prioritize features closest to Done. This allows for early wins to foster platform advocates, which can go a long way to increase adoption.
Be open to changes
As CTO of Carta Will Larson put it, “If something dire is happening at your company, then that’s the place to be engaged. Nothing else will matter if it doesn’t get addressed.”
Your roadmap is just that, a map — there’s always more than one way to go. You need to be ready to deviate and change your priorities. This could be a global pandemic or an urgent vulnerability patch. It could be the need to adopt a new developer technology because it will help you work with a big-name integration partner.
Especially in a well-regulated industry, your cybersecurity and compliance stakeholders can influence a lot of change. Just because platform engineering is opt-in, doesn’t mean it can’t facilitate some mandatory changes too.
No matter what the reason, it’s important that you communicate any fluctuations to your internal customers, explaining why the roadmap priorities have changed.
Continuously measure
Engineering is a science, so we know you can’t improve what you don’t measure. This “metrics-backed intuition” as Diogo Correia, developer experience product manager at Pipedrive, calls it, fosters continuous improvement, not just for your platform strategy but for your developers too.
His team uses DX for quarterly developer surveys. Then it developed and open sourced a one-hour developer experience workshop to help dev teams not only surface their own struggles but to set individual team focus areas for the next Q.
“It has an immediate impact in terms of the sentiment and priorities that they report in the next quarter,” he said. For example, a lot of developers complain about technical debt, but almost no devs want to spend time fixing it. This knowledge has fed into Pipedrive’s rotation of teams focusing on paying down that debt versus releasing new features.
“The workshops help by identifying the concrete services or libraries that any given team owns that most developers in the team are feeling pain with,” Correia continued. This helps the team prioritize and plan to refactor, “instead of suffering through it for years on end, as before.”
In the end, the most important measurement of any developer experience strategy is if your internal dev customers are adopting and using it. Work to tighten that internal feedback loop to make sure you are building what they want. Only then will you achieve measurable, long-term success.