Note: This is an edited and condensed transcript of the podcast and will differ slightly from the original recording.

Interviewer (Sid Maestre): Hi, I’m joined by Richard Fortune. We’re going to be talking about developer experience. Thanks for coming on today, Richard. Why don’t you take a moment and introduce yourself to the folks?

Richard Fortune: I worked with Sid at Xero for almost a decade. I joined Xero, a FinTech startup in New Zealand, in 2010 and started out on the API team as a quality engineer. Later on in my tenure, I transitioned into product work. During my time there, I was involved in testing all of Xero’s APIs and witnessed the business grow from a handful of integrations to its own transactional app store, with thousands of integrations connected to it.

Late last year, I left Xero and moved to Europe, specifically Ireland, where I worked with a company for a while. I’m excited to chat with you today and share my experiences with you. Thanks for having me!

Interviewer (Sid Maestre): I believe that one of the questions I will be frequently asking my guests is about developer experience.I have noticed it starting to crop up in different places. I don’t want to attribute it to the “red car syndrome” where after buying a red car, you start seeing red cars everywhere, but I am seeing more podcasts having an episode dedicated to developer experience or more conversations happening on different platforms.

The field of developer experience is still very new and developing, similar to developer relations ten years ago when the industry was still figuring out what it meant. So, I’m interested in exploring what developer experience means for each individual. In your opinion, what is developer experience?

Richard Fortune: That’s a good question.

When I join a new organization or introduce someone to an organization, they often have a lot of questions around what developer experience is. If you Google it, you’ll find it defined as UX for developers, but I think it’s a bit blurrier than that in the real world. 

For me, developer experience is all about the journeys that people take when trying to connect to systems. As someone who has worked on the platform side repeatedly, I think it’s important to make that journey as easy as possible to help developers achieve success quickly. It’s important to consider what role they are playing when they’re building with you on that particular day, and that’s a really important first step. If you do that well enough on the first cut, it’s important to do it repeatedly on all the other stages of the journey. This really works well when you have additional offerings later on as well.

Most people tend to fire and forget an integration, meaning they build something and won’t go back to it. That’s where persistent engagement comes in. If your developer experience is assisting them in reaching that point, you’ve hit the mark because you’ve helped someone build awareness of your system and get to a point of truly shared value. If you’re not leveraging that repeatedly, both parties are losing value at that point. 

A good developer experience requires both consistent and voluntary engagement.

Interviewer (Sid Maestre): In my opinion, when you examine the developer journey, the stage that’s typically referred to as retention is all about the relationship you cultivate throughout that journey. What do you say?

Richard Fortune: While no one wants to feel like they’re being retained, I think growth is a strong argument for it. It’s about providing opportunities and creating value for builders beyond just solving their problems.

Regarding the term “builder,” I believe it defines the developer experience beyond just an engineer. But as someone who’s paid to think about the engineer, I find that bringing the engineer on the journey is important because of the complexity of the problems we’re trying to solve and the value we’re trying to unpack. At Xero, we had a vast catalog of over a hundred endpoints, so a good developer experience there is crucial to making an engineer successful.

When speaking to a unit of our team that is not involved in the project, I use the language of partner or platform experience. This is because there may be a business person on that side, potentially wearing a different hat each day. The platform experience is the broader language I use, but I bring developer experience into the literal sense when they’re creating something by consuming some of the stuff we and others have built, such as SDKs, explorers, command line runners, etc.

Finally, I have a strong opinion about businesses not fully understanding what developer experience means to them as a platform. It’s not just about having a developer portal or program but about the broader platform experience and the value you want to bring as a platform business. Starting a relationship and sharing domain knowledge is crucial to unlocking the full value of the developer experience.

Interviewer (Sid Maestre): When I think about developer experience, there are various aspects that come to mind. For instance, if a company serves APIs, there are engineers who build them, technical writers who work on documentation, people like myself who are responsible for developer relations and advocacy, and someone like you, who is a product owner for the entire portal—not just the documentation but the entire portal experience.

I am curious to know how a company decides who owns the developer experience. While it is easy to say that everybody does, I think there should be some internal champions. In your opinion, where do you think the responsibility of owning the developer experience should fall?

Richard Fortune: Companies often stumble into a situation where they begin a journey towards improving their developer experience but don’t have the necessary depth of experience to take it to its fullest. Some businesses may have a champion internally, but that person might not be in the right room to take ownership of the entire journey.

Nowadays, some entities offer developer experience-as-a-service, which can help companies get further than they would have a decade ago. However, the initiator of the project may still end up being accountable without actually being in the right position to own the journey fully.

At my previous workplace, the evolution of our API team was quite specific. We built APIs and attached a DevRel function to support external parties. Looking back, I think this was a good model for the developer experience at Xero. When asked about who owned the DX, I said that it was split between the DevRel team and us, the product builders who supported the customers daily.

Drawing hard lines between the different parts of the journey isn’t helpful, and it’s better to collaborate on ownership. At Xero, we divided our APIs into different verticals, but we still helped each other out when needed. We had a journey map for the developer experience, and it eventually evolved to reflect our partners.

It’s hard to split ownership of the journey any tighter than two teams: one for customer-facing and one for internal work. It can get complex quickly, and many external businesses don’t have clear ownership of their developer experience. They often leave it at that and don’t try to improve further, leaving value on the table.

In my opinion, leaving the developer experience as a fire-and-forget effort is not enough and isn’t making the most of the opportunity.

Interviewer (Sid Maestre): When I hear leadership say that the end goal is to get the developer portal spun up, I see it as just the beginning of the journey to delivering a good developer experience. It’s great that you mentioned the feedback loop between our teams at Xero. Even though we didn’t always report to the same leadership, we were part of a larger organization and had weekly meetings where we shared everything we heard and saw. I always felt that the team was heard, even if things couldn’t be prioritized. 

As a developer advocate, it was amazing to have that level of communication and collaboration with the team that was building the APIs and owning the developer portals. I’m not sure if that’s common in every engineering team, but I think your team did a great job of listening to the customer or my team who acted as a proxy for the customer.

Richard Fortune: I also have the same reflection on that. As a globally distributed team, I think it worked well to have weekly meetings internally. Looking back, I think it was a little taxing from a personal experience because you had to have massive amounts of patience for us, and it might have felt like we were raising the same issues over and over again. However, when I reflect on it, I realize that many of the issues we raised, the legacy we left behind, and the things we talked about implementing took longer than we predicted. It supercharged our understanding and nudged us to discuss what DX means.

Interviewer (Sid Maestre): Yeah. I put out a call on Twitter to see if anyone could recall a specific year when DX became a thing for them, and I got a few responses. The most interesting one came from a PM in leadership at Intuit who said that in 2008, when they were doing some re-platforming for the QuickBooks Online API, they actually used the term DX in their meetings. This predates when I personally became conscious of it with Twilio who were working on creating easy, delightful experiences for their users.

I was thinking about your work at Xero and Stripe. One of the things that Stripe did really well from the start was their dashboard. The experience when you went into their portal was smooth, and you could easily switch between sandbox and live environments while seeing the actual API calls that were coming through. There were also metrics available. I would love to hear about the work you did at Xero around the portal, dashboard, and onboarding for developers.

Richard Fortune: When I joined the product team, I initially focused on extending what we already had. It took me a while to step back and build my own sense of what we were trying to do. Reading academic stuff around platform businesses and business fundamentals helped me take a 10,000-foot view and understand what we’re trying to achieve as a business. I realized that while we had built the means for people to speak to us and manage the relationship, it wasn’t the best and it wasn’t actually a SaaS experience on its own. It was quite hands-on and required a lot of laboring in the background. We had to orchestrate the situation at Xero, but the external experience was disjointed.

We had limited funding, which meant we had to figure out where we wanted to get to and how to manage experiences at scale. So we dialed everything back and fragmented the portfolio. We broke it down into its constituent parts and prioritized them in their own verticals. We consciously stopped working on some parts while focusing on others.

When we rebuilt the overall administration console or developer console, we wanted to model what we were trying to achieve. We wanted to serve multitudes of experiences to our parties on the other side. So we built a journey that developers could follow and introduced different stages they could work through. We ported everything we had and rebuilt it to ensure that developers could manage integrations, have an overview of those integrations, and update listings. We didn’t try to emulate everyone else. Instead, we stepped back and asked ourselves what we wanted to have as a business.

I think nowadays you can see examples of this in companies like Google, where if you venture into the darker corners of their API or developer world, the user experience suddenly becomes outdated and clunky, making you feel insignificant and out of your depth. It’s like you’ve entered a world of “there be dragons” and need to strap in for the ride. That’s why we decided to re-platform, so we could iterate quickly and keep up with the fast pace of development.

Our vision was to create a cohesive platform experience, which meant implementing a UX library to ensure a consistent experience. It was table stakes, but we knew it was crucial.

Interviewer (Sid Maestre): When I heard about the blog post “do things that don’t scale” written by Paul Graham, the founder of Y Combinator, it really stuck with me. Especially when I’m working at smaller companies, I try to keep that in mind. It’s easy to get caught up in trying to create a perfectly optimized and scalable experience, especially if you’ve worked at larger organizations before. But sometimes, when you’re still trying to nurture an early community, that’s not where you should be investing your time.

Regarding the Google analogy you mentioned, while Google may not do this, I can understand the frustration of landing on a beautifully designed developer portal only to be redirected to outdated, poorly designed documentation. As a developer, that would raise concerns about the investment being made in the developer platform or offering.

I’ve also been experiencing more interactions with different stakeholders or personas who interact with developer experiences. For example, at Xero, the marketing team wanted to update their marketplace listing. It can be challenging to balance the needs of different stakeholders and personas, and I’m still figuring out how to navigate that effectively.

Richard Fortune: I find it challenging to look back on our past decisions regarding Xero and our approach to integrations. In hindsight, I believe we may have spent more time and resources than necessary optimizing the developer portal and marketplace listing page. We had around a thousand integrations, and realistically, our partners would only update their listings once a year unless prompted by an external event. As a less mature version of myself, I may have overemphasized the importance of optimizing the workflow to update marketplace listings as a benefit for our partners, but in reality, the manual update process was being carried out by internal teams, slowing them down and robbing us of capacity.

When building a developer experience, creating value indirectly is crucial, and sometimes it requires taking a longer route. We couldn’t simply go to the customer and expect them to understand the value of updating their listing frequently or playing with keywords to improve their exposure on Google. Instead, we needed to release the DevRel team from the manual support of our marketplace listing management experience, allowing them to create real human value for our partners and developers, fostering a more engaging relationship. This approach would lead to higher-value conversations and nudge different personas involved in the relationship. 

It’s challenging to draw a hard line between developer experience (DX) and user experience (UX), but when we drop the ball in the DX area, the cost can be disproportionately high. Developers are a multiplier effect, and neglecting their needs can have far-reaching consequences.

I think that’s why people are now playing it safer in the market, not wanting any bells and whistles or cascading menus, but rather giving people the right tools that don’t lead them to dead ends with redirect URLs. 

Poor DX can cause friction in the funnel, which is why it’s crucial to pay attention to the life cycle of the relationship with our partners and developers.

Interviewer (Sid Maestre): Something you worked on during my time at Xero that I found particularly valuable was a project focused on providing users with feedback on the health of their API usage. Instead of just counting the number of API calls, you aimed to share information on the success of the API calls and highlight any issues that users may not have been aware of in their API usage. You came up with some pretty clever ideas and I would love for you to share some of those so listeners could potentially benefit from them. 

Richard Fortune: Sure. One of the things that I came up with was the concept for Integration Health as a solution to the integration issues we were facing as a business. Our integrations were being treated negligently or casually by developers, resulting in issues such as polling, errors, and mismanagement. As a product person, I knew that being aggressive on the matter would not get us where we wanted to be. However, we needed a way to start a dialogue about it, which was missing. That’s where API Health came in, providing a tool for the developer relations team to talk with our partners about how to manage integrations. The idea was to make the experience more proactive, educational, and supportive, rather than just logging activity and error checking. 

Integration Health got to an early stage where it wasn’t proactively indicating issues to people, and it wasn’t giving advice on the best course of action. The end goal was to observe the errors and lead with education, which could be folded into our SDK or implemented as catches or hooks to make implementation easier for our partners. 

The relationship between our team at Xero and external parties was key, and our partners didn’t always have a dev team, so they may have had someone build the integration for them without knowing its true value or success. Integration Health aimed to change that and make the experience better for everyone involved.

Interviewer (Sid Maestre): I would like to draw a picture of this health dashboard for people. If I remember correctly, you could go and look at the history and see all the raw API calls and errors grouped into broad categories. However, the health dashboard was more like KPIs. It would give you a single number or indicate with some color coding whether you were yellow or green, showing how well you were doing in different areas.

Richard Fortune: Yeah, it was almost like a steam meter on a train. We were quick to implement it, and we had an internal conversation about whether to redline everybody right away. However, we decided to take a soft approach and start a dialogue about what a healthy integration looks like for both parties and the value of making these changes. This approach also gave people a place to self-serve.

Fundamentally, I believe that most people are motivated to do the right thing. For instance, if they receive a notification on AWS that something isn’t right, they will investigate it. Giving people the tools to do the right thing and get value from it seems obvious in retrospect.

It also means that the next time they start a new build, they have the knowledge of what we care about as a business and what a good integration looks like. This way, the overall network improves, creating a self-fulfilling cycle. The DevRel team can then have more advanced conversations around developer success instead of developer reprimand.

Interviewer (Sid Maestre): The end goal is to serve our customers better and create a better experience inside our products.

It’s been awesome talking to you! I really appreciate you taking the time to chat with me today, Richard, and sharing some stories and good memories that we’ve had working together. It’s great to see how we’re helping developers and pushing developer experience forward. Thanks again! Let’s call it a wrap.