Beyond DevRel: Exploring the rise of developer experience

We sat down with Sidney Maestre, VP of Developer Relations at APIMatic, to talk about how developer experience can support sales and marketing.

You can listen to the full podcast interview on Spotify and Apple or enjoy the highlights of our convo in this article.

My career path to developer relations

Like a lot of folks in developer relations, I came here through a very unusual path. I actually studied history and was going to be a high school history teacher before I decided that life in technology was more interesting.

I took a pivot pretty early on. I've been self-taught programming, and I spent a decade developing e-commerce websites and content management systems.

At a certain point, I started getting involved in developer communities, organizing meetups, and going to conferences. That led me to my first developer evangelist job at PayPal back in 2011, so I've been doing this for quite a while.

After that, I skipped around a couple of companies. My longest stint was seven years with Xero, a cloud accounting software platform out of New Zealand, which was a great experience. I was able to work with that team and build out our app marketplace and partner program there.

Recently, I've moved into the tools space because while I was at Xero, I was actually building their SDK program. We built that all in-house. I'm now at APIMatic, where we actually do that for companies.

Originally, I was a musician. It's funny because you actually meet a lot of engineers who have musical backgrounds. Maybe there's something about how the brain works with music and technology.

I was writing and composing music on my computer, and after trying a couple of different jobs, I just reflected on what I actually enjoyed. I’d just get lost in writing music on the computer, and I thought, There's got to be something here. There's got to be a way to make a living doing something that I enjoy.

So, that's how I fell into it.

Building developer experiences with APIMatic

I joined APIMatic at the end of 2022 as their VP of Developer Relations. We're a fairly small team, so I get to wear lots of hats.

In addition to developer outreach and awareness, I'm thinking about our marketing programs, as well as the developer experience overall, from the point that we introduce someone to the product all the way to helping our customer success team understand how our customers are enjoying and experiencing our products. I can offer advice there as well.

APIMatic itself is an interesting product. It's a product for building developer experiences, and we do that by working with companies to help them take their open API specifications and use them to generate SDKs in multiple languages.

In addition to the code libraries that we build, we generate documentation that’s specific to the language, we create all the code samples to show developers how to use those code libraries, and we also have interactive documentation.

There's a lot that comes out of the product and it can all be added to a CI/CD pipeline, so you can really automate the building of it.

One of the real problems is not just building SDKs, but how you keep them up to date and maintained as your API changes. So, what we're really trying to do is help companies not have to hire a huge team to build and maintain their SDKs as part of that overall experience.

Understanding the emergence of ‘developer experience’

When I left Xero, I was the Head of Developer Evangelism. I’d been an evangelist or an advocate (I use those terms interchangeably), but when I left and went to a new company called Lob, I actually talked with them about my title. I thought ‘Director of Developer Experience’ was more appropriate for the kind of work that needed to be done.

For me, developer relations had been focused more on the relationships, the conversations you have with developers, building community, working with advocacy content, and going out to events. However, it always omitted some of the engineering work, and I felt that developer experience was a bigger umbrella that allowed us to go beyond relations.

In a way, developer relations is a pillar of developer experience and it incorporates some of the building of SDKs and building of tools. Those could be command line tools. There are so many things that we can build to improve the developer experience, so we should have a term that encompasses it.

That's my interpretation. I imagine there are other people out there helping to shape this term because it’s quite new. I'm seeing it in lots of people's titles now, and I don't think it's synonymous.

But I think a lot of people who did have a developer relations title in the past are now getting ‘developer experience engineer’ as their title now. And I think it's maybe adding a bit more description to what they actually do.

It's helping to encompass more than just the activities that a typical developer advocate or developer relations person does. And when you get a term like that, you could say the definition is that it encompasses every event or interaction that a developer experiences.

And when you put that lens on it, you're really saying that it's not just one team's job, it's everyone at the company's job, from customer support to sales, to engineering, to the product teams that are building the APIs or the technology.

Developer experience is everyone's job, but having someone with that in their title means that they have an extra level of investment and they're championing that internally at the company.

Creating the developer experience through cross-functional collaboration

If you look at how companies traditionally get organized, you get a sales team with a sales leader, you get a marketing team with a leader, you get an engineering team with a leader, and sometimes they have a separate product team, or sometimes product and engineering are merged.

And what you've got is this gap between those two groups. Engineering is on one side, and sales and marketing are on the other. And developer experience or, traditionally, developer relations, acts as a bit of a bridge between those two because they’re more forward-facing, like marketing and sales, but typically have a technical background or a technical understanding of the product.

They're really focused on how to translate what the engineering teams are building into a product that can be sold and how to communicate this in the best way. And they help with that translation layer and actually feed back to the engineering teams what they're hearing from the customer as well. They're a bit of a proxy.

In fact, when I'm at APIMatic, I often join conversations with our product and engineering team and act as the customer because I've been in those shoes for several years. It's easier than them having to try and book an interview with a customer who's probably pretty busy, so I can act as a bit of a proxy for them.

The saddest thing that can happen is if you have these barriers between the teams, especially a marketing team because they rely on other folks who have a deep technical understanding of the product to collaborate with them. And, sometimes, the engineers get so focused on building the product that they don't have time, or when they talk, they talk at a very deep technical level.

So, it can be tough for marketing teams to translate that.

I think everyone probably knows this, but when the customer is a developer, you have to speak their language. If you use a lot of fluff, they get really turned off and typically don't trust the product or what you're sharing with them because they’re naturally skeptical. They have a bit of a BS meter that goes off when they see that kind of marketing jargon.

That's where that collaboration is so important because you want to build credibility with your audience.

How to build trust and credibility through your content

Depending on how the different teams are organized and resourced, sometimes you have a technical writer who's part of the developer experience team, which is really valuable for a sales and marketing team.

Sometimes you don't have a lot of resources and someone in the developer experience team can act as an editor, or someone who can validate the marketing message that you're putting out there. They may not be able to write it for you, but they should be able to make time to validate that you're actually hitting all the right notes in that message.

I was working with APIMatic on building a one-page brochure for the events that we’re going to this year, and there were a lot of iterations we did to make sure that we were communicating clearly, concisely, and truthfully about what the product does and what it delivers. And that's another thing I feel really strongly about.

When I write a blog post, I make sure I’m being very clear and concise, and I'll do five or six iterations on a piece of content to make sure I'm saying it in as few words as possible, but still getting the point across because I respect the people who are reading my content and I don't want to waste their time with unnecessary words and fluff to make it sound really exciting.

I just want to get to the point and give them the information they need.

If you're creating content and you're attracting them to your content, they're showing up there because you've hit on something that's of interest to them. So there's actually a lot less selling that needs to happen at that point. It's more about educating.

As long as your focus is to educate the developer who's your customer, then you're on a really good path toward building that trust and credibility.

Does education always have to involve really deep technical diagrams and code samples? It can, but there's also a level of education around the business value.

Something that we always have to remind ourselves is that not everyone who shows up at your site to learn about your product is necessarily the person who's going to be building on the technology.

There are other stakeholders you need to be able to communicate the business value to because those folks want to be able to understand things like, “I have to come up with the budget for this, is it going to help us achieve our goals and objectives?”

It's a real challenge. Developer experience is hard. And it's probably why we keep talking about it because so few companies really nail it. So, we have to keep pushing ourselves to do better.

Tailoring the developer experience to different audiences

To strike that balance when selling your product to developers and stakeholders who don’t have that deep technical knowledge, I’d say you need to start by making sure that both audiences can self-direct to the information that's important to them.

When I’ve gone to a site and landed on its homepage, like a lot of developers, I immediately look for the menu item that says ‘developers’ so I can click into that, because I want to understand what they’re offering technically.

But then there are other things. Someone else might be more interested in the pricing, so they're going to go to the pricing page. So, having those paths for your different personas to traverse is important.

Depending on where each persona is in the journey, whether they're evaluating the product versus building a proof of concept, you're going to need different levels of technical content.

A Getting Started Guide is great for someone who wants to start getting hands-on experience with the product. But maybe you want to offer a way for them to interact with your API directly from your documentation without having to download any code and set up their IDE.

So, you can have different entry points into the experience based on where they are in the journey and how technical they are, or how technical they want to get at that moment in time.

So, having multiple paths with multiple layers means you're going to be able to cater to those different stakeholders. It's hard, but the worst thing I think you can do is to think that there's just one happy path. Everyone's going to go down this one path and it's going to be like a funnel.

If you've been around for a while, you know that developers bob in and out of your sphere of influence, and there are so many touch points that they might experience before they actually sign up and try your product out. So, you want to work really hard to make each of those touch points a positive interaction.

This is where it really goes beyond your DX team and goes into other teams. For example, how you interact on social media with a developer audience, that's a real opportunity to leave a positive impression on them so that they’re more likely to take that next step in the journey.

Everyone's got a role to play in that DX.

Top tips and best practices for creating a strong developer experience

When I join a company, I like to do a little bit of an audit. I look through the different touch points that they have available today and I'll look at the journey and think about what questions we’re trying to answer.

But if we're talking just concrete artifacts or things that you’d have as part of your developer experience, I work with APIs a lot, so a full API reference which is top to bottom, every endpoint, every method, and every parameter accurately documented with human-readable descriptions.

That alone can be a challenge, but if you start there, I think that's very important.

And then from there, I’d layer on things like a Getting Started Guide. I’d also put in your use case guides, which can be a recipe for how to actually accomplish a specific task, explain your authentication, and all of those things.

And then what we do at APIMatic is actually build the SDK portion of it. And with each code library, we essentially create a version of your API reference. But it's all about how to use the different methods in your SDKs along with code samples, and a way to interact with those code samples right from the documentation.

So, to me, that takes it to this next level, where it's not just, “Here's a static piece of code.” You can actually add and change the values and add and remove different properties that influence the code sample that's being provided. And then you just copy, paste, and run those code samples.

Making sure they're runnable is a huge part of the developer experience as well.

All of those things to me, make up the foundation.

Then, from there, I like to do starter projects. So, put it up on GitHub, have your SDK there, have a fully runnable starter project that a developer can download, add their API keys, and run it.

And then I'll create a video and put it up on YouTube, and it’ll explain how you actually download and run this project. Those will be five or 10 minutes long. And then developers will start commenting on your YouTube video and share it on social media.

Just keep adding those extra layers and opportunities because every developer learns in a different way. Some are very visual learners and some just love to consume documentation. By providing multiple ways of learning, you're having the best opportunity to have a good experience for as many developers as possible.

APIMatic’s interface is just a little drop-down menu, and you can switch from one language to the next. Then the whole documentation changes and it becomes the user’s preferred language.

If you think about a Python developer, a Java developer, and a TypeScript engineer, they all feel a sense of pride in their community, so when they see a company that’s gone to the effort to create documentation specifically for them, they feel understood.

They feel heard by the company and then they feel a greater sense of trust. “Oh, wow, they get Python developers. Look at the great code samples they just provided to me, even if I don't use the code samples.”

Some developers prefer to roll their own solutions, but just having that available to them sends the message that we care about Python developers or we care about Java developers, and that builds a new level of trust between you and the developer.

Some of the feedback we've received from our customers is that because we build documentation that has that interactivity, a lot of the sales and enablement teams are using it as a no-code way of explaining the product visually and in an interactive way to the customers. And it actually helps them sell.

Our customers are using it to enable their sales and enablement teams to help onboard customers using the SDKs and the documentation that we generate for them.

I found that really fascinating and it validated some of the things that I was feeling around that sort of experience.

If you think about product managers, product managers may or may not have engineering or coding backgrounds. And if they do, it's not what they do every day.

If you ask them to go and download a sample app or to spin up a proof of concept in Node.js, maybe they could do it and maybe they've done it in the past, but if you could provide a way for them to explore your APIs without having to write a bunch of code, that just saves them time and gets them more quickly to a, “Yes, this is the right solution for us.”

Another great tool that isn't APIMatic that I've used in the past is Postman. A lot of companies will just provide a downloadable Postman collection, but they now have these public workspaces that you can launch directly from your documentation with a link, and it’ll open up the full Postman experience.

You can interact and make API calls without having to write a bunch of code. That's another option.

While APIMatic offers that experience, I'm all in favor of providing as many ways for companies to connect with their audience as possible, and that's another really great way.

Integrate developer advocates into your team

For me, having folks on your team, whether they have the title of DX or not, or whether it's a developer advocate or a team of advocates who are really thinking about this experience and helping to be that bridge, I’d say if you're a startup, getting them into your team is really important.

I know it's important to hire engineers, but I think we shouldn't underestimate the role.

If you're building a tool for a developer audience, have that advocate there who's having those conversations with your customers and listening to the pain points they're experiencing. They'll build content to educate, but they’ll also help educate your engineering and product teams to level up your experience and help you win with developers in that way.

I just released a piece of content for APIMatic. It's a pretty sizable project. It's called SDKs.io. It's a resource for anyone building SDKs.

We understand that some people will automate building SDKs, so we talk about that, but we also know that some people have to build their SDKs from scratch because that's what their community needs. We've documented the best practices around that. We're also doing some research on trends in the industry for people who build SDKs.

Join our Slack community to chat about DevRel, developer experience, and everything developer marketing-related. You can also connect with your peers, ask your most pressing questions, and check out job opportunities.

Going beyond relations: Exploring the rise of developer experience

Teresa Garanhel

Sidney Maestre