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.

The post Prioritizing your developer experience roadmap appeared first on SD Times.

What is API Developer Experience (DX)?

Simply said, DX refers to the question of how well an API works as a product that a developer is using to build an application. This means that very specifically, DX is not about the functionality of the API (i.e., about the service that is delivered through the API), but about the usability of the API itself. DX is just about the interface.

Practically speaking, DX is measuring how easy an API can be used by the developer for building an application. Specifically, this does not include the question of how useful that application will then be for users.

This means that the perspective of DX is relatively narrow. It just involves the API and the ease of building an application with it. This brings us to questions that take a slightly wider perspective and go beyond just looking at an API and the application that’s built with it.

What else matters for API success?

While it’s certainly useful for a developer to be able to easily build an application, there is also the question of who that application is for. This brings the end user into perspective, i.e. the user of an application that leverages the service the API delivers.

A second step back looks at the even bigger question of why that service is provided in the first place. Certainly, there are many services that users would enjoy, but there must also be an underlying value model that makes it reasonable for a service provider to provide such an API.

Let’s look at these two issues in a bit more detail.

User Experience (UX)

By their very definition, APIs are used by applications. These applications then are, directly or indirectly, consumed by users who are exposed to a User Experience (UX). These users should find the application useful, and the API then helped to create that useful application. 

That’s rather different from DX, which only looks at how usable the API is, but doesn’t include a perspective that involves the end user.

What this means is that UX is at least as important as DX. There could be a perfectly usable API that would make it fantastically easy for developers to build applications with it, but if it doesn’t contribute to the usefulness of the applications built with it, it would never be widely used (other than maybe as an educational API for great DX).

Value Exchange (VX)

But the perspective must be even broader than that. Because even if you can think of a perfectly usable API that’s providing an extremely useful service, there must be somebody bearing the cost of designing, implementing, and operating it. There must be a Value Exchange (VX) happening that means that the provider is willing to provide the service through the API.

In most cases, this VX may be based on economics, but even for economics, that’s a very wide range of possible motivations. For example, if a government improves the life of citizens by providing a service through an API, then this improvement of the quality of life may be sufficient for the value models that are often used in public sector economics.

As we can see, VX is an even bigger factor than UX or DX. If there is no value exchange that justifies the existence of a service, then there is no sustainable foundation to provide it.

What does all of this mean for my API program?

As mentioned in the introduction, the idea here is not to belittle DX. We all want our APIs to be usable and used, and it’s important to invest in DX so that APIs see as much adoption as possible. It would be a shame to cripple a useful service by delivering it through a badly usable API.

But just focusing on DX sets a rather narrow focus. We must also always think about the usefulness (UX) of an API, and we also need to think about its viability (VX). Without taking those aspects into consideration, we may overinvest in DX and forget to take the bigger picture into account.

One last word about DX: Many examples and motivations discussing DX explicitly or implicitly assume that there’s competition. Sometimes that’s the case, but looking at all of an organization’s APIs, there often are very few if any APIs that have competition. 

Of course, if you’re providing an “Product-as-an-API” and there are competing providers, then DX can become an extremely important differentiating factor. Some of you may remember Twilio’s “Ask Your Developer” campaign that explicitly targeted this differentiation. But it’s important to keep in mind that APIs such as this are a small fraction of API landscapes in today’s organizations, and it’s wise to invest accordingly.

The post Is API developer experience overrated? appeared first on SD Times.