Prioritizing Your Developer Experience Roadmap

If there’s one thing a platform engineering team never lacks, it’s ideas. When your customers are your colleagues and friends, you have an ever-growing wish list to fulfill. improve the developer experience — just ask!

But as with any product team, you have limited resources and must balance business and technical goals. Many stakeholders inform your team developer experience roadmap that it can be difficult to prioritize.

Yes, you need a roadmap

The main difference between platform engineering and the top-down platforms of yesteryear? No one is forced to use it.

When you build a developer experience tools — whether it’s an internal developer platform or portal, or just a repository or better documentation — you need to build something that your engineers actually want to use. Your platform strategy — sometimes called a developer experience strategy or DevEx strategy — needs to make developers’ lives so easy that they need a really good reason to deviate from that ideal path.

Platform engineering requires a “platform as product” approach, with user-centered design, prototypes, and demo days. Your colleagues become your customers.

Not only do you need an internal product roadmap, you also need to actively publish it within your organization. That way, not only are you committed to solving your developer customers’ problems, but you’re also closing that feedback loop, so your platform team knows early and often if you’re building something they need or want.

Know your stakeholders

Perhaps even more than when working with external users, a platform team, as the custodian of the developer experience, is accountable to many stakeholders.

As Sergiu Petean of Allianz Direct pointed out, a common anti-pattern for platform teams addresses only the single stakeholder of the software engineer. The larger the company, the more regulated its industry, the more stakeholders need to be considered from day one.

At the insurance giant, his team first identified eight different stakeholders who all bring different demands:

• End users
• Quality
• Security
• Software Delivery
• Data
• Sustainability
• Incident management
• Compliance

Later, they realized that the platform had the capacity to interact with even more teams.

Work to build a relationship with each of your technical and business stakeholders. Find out which part of the software development lifecycle matters most to them. Then, integrate them into your feedback loops that impact your platform engineering product roadmap.

Learn to prioritize

The more stakeholders you identify, the more feature requests you will receive. However, according to a DX studyThe average developer experience team is a fraction of the entire engineering organization. It may seem overwhelming, but a platform engineering strategy aims to centralize and solve frustrations at scale.

How do you reconcile so many conflicting demands? Michael Galloway, head of platform engineering at HashiCorp, recommends looking to eliminate the stone in their shoe.

The biggest friction points will be an ongoing process, but, as he said, “often engineers have been in a situation long enough that they’ve developed workarounds or gotten used to the problems. It’s become a common experience. So we need to look at their workflow to see what the roadblocks are and remove them.”

Successful platform teams engage with their customers regularly. It’s a powerful way to build empathy.

Another thing to prioritize is asking yourself: is this just affecting one or two very active teams or is it something systemic across the organization? You can never please everyone, but your job as a platform engineer is to create solutions that about 80% of your developers would be happy to adopt.

Focus on low-hanging fruit

Another difference between platform engineering and legacy platforms is that it is not a giant, single implementation. In fact, Team Topologies has the concept of Thinnest viable platformYou start with something small but solid on which you can build your platform strategy.

For most businesses, the biggest time waster is searching for things. Your first TVP is often either a directory of who owns what or better documentation.

But don’t trust that instinct: ask first. Developer Productivity Survey will help you find out what your developers’ biggest frustrations are. Ask targeted questions, not open-ended ones. You can start to learn about the 25 Factors of Developer Productivity — which, on a socio-technical level, range from incident response and on-call experience to requirements gathering and realistic deadlines.

Combine this with informal conversations and pair programming with your developers to uncover problems big and small that need solutions.

As a Start-up Advisor Lenny Rachitsky suggests that you can rate each idea from 1 to 5 based on X value of its impact on solving a problem and Y value of the effort required. Just make sure that everything on this “estimation chart” meets the requirement that it solves a problem for the majority of your developers, because a platform team should never work for just one development team.

Remember to value quick fixes to help alleviate some of the pain points. Following the agile practice of “walking the board,” prioritize features that are closest to completion. This creates early wins to encourage platform advocates, which can go a long way toward increasing adoption.

Be open to changes

As CTO of Carta Will Larson said it“If something bad happens in your business, that’s where you need to step in. Nothing else will matter if the problem isn’t fixed.”

Your roadmap is just a map: there is always more than one path to follow. You must be prepared to deviate and change your priorities. It could be a global pandemic or an urgent vulnerability fix. It could be the need to adopt a new development technology because it will help you work with a reputable integration partner.

Especially in a well-regulated industry, cybersecurity and compliance stakeholders can influence many changes. Just because platform engineering is optional doesn’t mean it can’t also facilitate some mandatory changes.

Whatever the reason, it is important to communicate any fluctuations to your internal customers, explaining why the roadmap priorities have changed.

Measure continuously

Engineering is a science, so we know you can’t improve what you don’t measure. This “metric-driven intuition,” as Pipedrive’s Developer Experience Product Manager, Diogo Correia, calls it, drives continuous improvement not only of your platform strategy, but also of your developers.

Her team uses DX for quarterly developer surveys. She then developed and open-sourced a 1-hour developer experience workshop to help development teams not only surface their own challenges, but also define the team’s individual areas of focus for the next quarter.

“This has an immediate impact on sentiment and priorities that they report in the next quarter,” he said. For example, many developers complain about technical debt, but almost no developers want to spend time fixing it. This knowledge fueled Pipedrive’s thinking. team rotation focus on paying off that debt rather than launching new features.

“Workshops help identify the concrete services or libraries that a given team has that are problematic for most developers,” Correia continues. This allows the team to prioritize and plan for refactoring, “instead of suffering for years, as before.”

Ultimately, the most important metric of any developer experience strategy is whether your internal customers are adopting and using it. Work on tightening that internal feedback loop to ensure you’re creating what they want. Only then will you achieve measurable, long-term success.