Spencer Hunter-Dwolla
16 November, 2017

7 mins

Developer Experience with Spencer Hunter of Dwolla

Regardless of the question that comes in, there’s always something our team can learn from it.

In this special interview, we spoke with Spencer Hunter who is the Lead Developer Advocate at Dwolla. He has previously held roles both as a Technical Community Builder, helping to grow Dwolla’s community of developers, as well as a Partner Integration Engineer, working side by side with partners to help them successfully integrate Dwolla’s technology. Launched in 2010, Dwolla powers billions of dollars in commerce annually. They allow businesses and individuals to build applications that facilitate bank transfers, manage customers and instantly verify bank accounts. Dwolla is also supported by leading venture capitalists including Next Level Ventures, Union Square Ventures, Foundry Group and Andreessen Horowitz. Spencer and his team are front row in the adoption of the Access API and financial technology. He spent some time with us to share what he’s learned about the developer experience along the way.

Developer Relations

OpenChannel [OC]: One segment of your primary customers are developers, they’re ultimately the ones who will be interacting with your API. How do you define the role of Developer Relations?

Spencer Hunter [SH]: I see Developer Relations as a multifaceted term, encompassing a few different areas. It focuses on improving the developer experience for external developers leveraging our APIs. From the technical side, it includes writing sample code or developing SDKs. It also involves engagement with our community by interacting on forums, writing blog posts and creating developer-focused content.

As a whole, Developer Relations entails listening to our developer community, building and establishing positive relationships with the individuals. Most people that come to Dwolla have questions. Sometimes those questions are simple and other questions can be more complex. Developer Relations plays a role in helping answer those questions. In turn, we use those questions and answers to improve our product and developer experience.

Dwolla API and Product Description for Developer Experience

The main driver and goal for our team is understanding a developer’s needs and helping them integrate our technology. We want to really understand how developers work and what supporting content is needed. Ultimately, it’s what can make it easier for them to come to Dwolla and launch their product with as little friction or confusion as possible.

Tracking Developer Relations

OC: What are the main metrics that you track in Developer Relations, and why?

SH: One metric we track is the level of engagement on communication channels within our own developer ecosystem. For example, we look at how much time are we spending on support forums, Intercom, or Github.

The frequency and type of questions we receive and trends in feedback, give us a representation of our various developer personas and the pain points encountered while interacting with our API. Whether a developer is asking questions about a specific product, the complexity of ACH payments, or how to perform a very specific task, we’re always looking to build understanding.

Understanding and tracking those questions allow us to keep up and stay ahead of the needs of our community of developers.

An additional marker for success is how easily or quickly our API can be integrated. Our ultimate goal is for a business or individual to go live with the API as quickly and as seamlessly as possible. A developer will explore the API, support guides, etc. It’s always a great sign when someone reaches out and says “We’re integrated, everything’s ready to go, it was super easy. Anything else I need to do to go live?” It means that they were able to figure out everything on their own. That’s always a great indicator of success as it happens more and more frequently.

Reducing Friction For a Better Developer Experience

OC: What’s had the biggest affect on decreasing the friction for developers? 

SH:  Ensuring our documentation and guides are clear and accurate, make the integration process quicker and provides a better developer experience. There’s also a bit of an educational role. Companies that come to us understand APIs, but they may not understand ACH (the Automated Clearing House) and other payments business logic. From an API design perspective, we make it as easy as possible to remove that business logic, so you can take in the API and interact with it as is beneficial to your business.

Building Trust

OC: Especially important with payments, how can a company instill trust in their developers?

SH: Reliability and transparency help build trust.

At Dwolla, we are an API-based company. Issues do happen, and when they do, you have to be transparent about what’s going on, be quick to respond and be open about what you’re doing to resolve any issues. For example, we have a Dwolla status page in an effort to be proactive in communicating our status. Also, if there are changes coming in the API, we communicate those to our developers as clearly and as early as possible.

On top of that, we have found that focusing on “the little things” like promptness in response and providing a thorough answer can help build trust. Regardless of the question that comes in, there’s always something our team can learn from it. Interactions and a personal touch of working through a problem with a developer is so important.

Making An API Easy to Use

OC: What is it specifically that makes an API easy to use?

SH: At Dwolla, we offer a RESTful API and try to follow REST principles as closely as possible. By following best practices in API design, the interactions with the API become intuitive and developers avoid any “gotchas” in the integration process.  Further, as a developer, if you do encounter an error, you should be able to go to the docs and clearly understand the error based on the endpoint you’re calling.

To make an API easier to use, we also think about the developer experience and cutting out as much busywork as possible through better design. Some of the developer experience improvements we focused on were designing step-by-step guides. They are clear and highlight the need-to know-items.

Even things as small as a ‘copy’ button in the right-hand corner next to your code can ease the process. You don’t have to select the entire block of code, you can just hit a single button. It’s simple but impactful.

Providing easily accessible code examples is also important. We’ve found that developers want to understand the high level of what they’re interacting with, how it works, and then see real code examples of how it works. Simply put, they want to take something, plug it in and see what the outcome will be.

Noteworthy Developer Platforms

OC: What other developer products or platforms do you really admire and why?

SH: I like what Twilio is doing. I also really like Box.com; they are great at ensuring the content you need is easily readable and accessible. Both Box and Twilio do a very good job with their documentation. One specific feature I like is that when you sign up in the sandbox, you receive an email with simple links to start.

5-Year Predictions

OC: What parts of building a developer facing product will be different in five years?

SH: I’d say the time between releasing an API and getting developers using it is going to start to change. When we released Version 2 of our API, Swagger really helped us go to market quicker in terms of documentation and SDKs.

The tooling for API design and helping developers use it is going to change drastically. I predict there will be far less manual content created and far more content will be created programmatically. Additionally, communication between developers may change notably in the next five years. For example, we’ll find more effective ways to properly communicate through language barriers.


OC: What’s something you love to do or are really good at that most people don’t know?

Spencer: My wife and I travel somewhere new every year and our goal is to visit every continent in the next seven years. Hiking and traveling are big for me. I love seeing new cultures, experiencing new things and being outside. She’s in environmental education, so we both love the outdoors.

Build Your Developer Experience

A big thanks to Spencer and the Dwolla team for helping to put this interview together. If you want to learn more you can follow Dwolla on Twitter, check out their website and connect with Spencer on Linkedin.

Want more from platform leaders at Shopify, Intuit and Box? Check out our Community Interviews, where we deep dive and gain invaluable insights from industry greats.

Related posts

How to Build Great APIs with Mike Amundsen of Mulesoft
Community Interviews

How to Build Great APIs with Mike Amundsen of...

Now you’re creating a set of tools to solve a problem that nobody knows about, for people you haven’t met....

From Industry to Ecosystem with Michael Jacobides of London Business School
Community Interviews

From Industry to Ecosystem with Michael Jacob...

We have a bad habit of saying “take a look at what Google or Facebook are doing” and trying to...

App Marketplace Strategy with Alan Glickenhouse of IBM
Community Interviews

App Marketplace Strategy with Alan Glickenhou...

Table of ContentsIt’s a matter of getting businesses to understand that’s where the real money is, and it’s definitely not...