“What we’re pursuing isn’t a technology problem at all. It never is. It’s a people and process problem.”
– Travis Gosselin, Principal Software Engineer, SPS Commerce.
This is the kind of thinking we see time and time again when it comes to defining developer experience. It’s not just about the technology; it’s the people who are using it, the processes put in place behind it to ensure a quality experience, and the organization’s overall culture. But what does starting that journey actually look like? What are the pain points? What are the important things to keep in mind? We spoke with Travis Gosselin, Principal Software Engineer at SPS Commerce in our latest API Intersection episode, to answer exactly that.
Travis has been a part of SPS Commerce for over a decade and has played a significant role in building out internal and external products. Now, he’s focused on reducing friction for those teams dealing with APIs, looking at it all through a developer experience lens. Developer experience heavily intersects with APIs in every capacity, and Travis collaborates with various leaders across SPS Commerce as they use this new API program and start to scale up their thinking on API design.
Collaboration was one of the key themes of our conversation on the podcast. We discussed these collaboration themes from a developer experience perspective and the people behind the technology, as well as through the processes (such as Style Guide implementation) put in place to improve that experience.
“I think that a large focus of my job from a developer experience perspective is reducing those day-to-day cycles and making a better quality of life for our developers specifically,” shares Travis.
SPS has reached an inflection point in its API journey; maturity and timeliness are prevalent. The next phase in this API program will focus on organizational adoption, starting from the top down.
The People
A Rainforest of Developers
“When I think about developer experience, my favorite analogy is the rainforest one. Developers work in the rainforest now; they’re not just working in planned gardens. [I’ve] got to move from tool-to-tool-to-tool in my everyday job and somehow connecting those through confusion and obscurity is difficult to solve. And I know I’m not alone in that struggle,” shares Travis.
Travis is tasked with working across those teams to make bridges and form relationships to understand how to move his team through that jungle. His goal is to connect the craziness of that rainforest into horizontal connections within the organization, making ‘some lanes through the jungle,’ as he says. He looks at all elements of a developer’s life that his team can empathize with and aims to create a system that works for all.
“How do you start with developer experience when it encompasses every single event of the day that a developer touches and any part of the system? We start by defining the most important capabilities where we think we will see the biggest gain,” shares Travis. His team has assessed the capabilities horizontally across the organization they want to enable. They are currently defining those capabilities as specific items that his team intends to curate.
APIs are a significant aspect of that journey, especially for developers. Travis equates APIs as their universal language.
One of the problems with developer experiences is that any event can change developers’ thoughts or impact what they think of your product, so it’s essential to be mindful of every stage and component they may come across. While Travis’s team is thinking about solutions to that problem primarily for their internal audiences right now, it is also a problem they seek to tackle in the future from an external standpoint with their APIs.
The Processes:
The Developer Workbench
“The company has some larger initiatives right now dealing with what they’re calling workbenches. With this, we have different value streams that we’ve defined as individual workbenches that affect different personas within the organization,” shares Travis.
One of those personas is the developer workbench, and what is in that developer’s workbench is all that they need to use in a day-to-day kind of perspective. SPS Commerce’s API team is still exploring what that developer persona and workbench shape up to be in the end. They also have other workbenches curating alongside the developer one for their implementation teams and customer support teams.
Developer Experience with Style (Guides)
“We dive into style guides a lot. We’ve been pushing that, and we’re kind of in a position to start really distributing that out to the organization for further approval,” shares Travis. “Over the last five months, we’ve been working on really building this style guide, definitely not from scratch. We took a lot of the stuff from existing style guides out there. I believe you’ve had the API Handyman (Arnaud Lauret) on this podcast before, and his resources are just fantastic.”
Implementing style guidelines across their API team is one of the main priorities for better collaboration and creating a sound developer experience. Travis emphasizes that it’s a collaborative effort across groups, working together to define style guides that are both appropriate and adoptable.
Currently, they are in the API design review phase of style guide implementation. They’ve done some initial investigations, a few POCs, as well as some betas of reviews.
“[Stoplight’s] Spectral is definitely where we want to head in our next direction. We haven’t codified any of the style guides yet, so right now, it’s very much just a lot of text,” shares Travis. Their team is currently tackling issues related to who will read their guidelines and whether they will actually adopt the policies they create.
Their team has worked with a cross-functional group of engineers through the collaboration process, and they hope to continue to evangelize and disseminate information on the design reviews they have currently. Travis emphasizes that they’re approaching it from a holistic approach, trying to think about, ‘Is this API even the right thing to build? Should we be augmenting or changing a different API?‘
In parallel, SPS Commerce’s team has also been dealing with many APIs. Their team has about 400-500 APIs out there today, most of them internal. But, they also have a few external ones that are available through public documentation. In the short term, one of the team’s next steps is learning more about the APIs already in existence, their use cases, their owners, how old they are, and how they can best be reused or replaced.
“Our first process goal will be to think about a centralized API reference for everything that we do, hosting it in one place that we can all go to find this information across the board,” shares Travis.
In the end, it’s no doubt that Travis’s team at SPS Commerce is taking all the proper steps and approaches to scaling their API program. Getting the right people involved, at the right time, with the correct processes and resources in place is a sure-fire way to create a winning API program. And, it doesn’t hurt that they are using some excellent API design tools to do it (but I may be a tad biased there).
To follow SPS’s story, check out their Tech blog for more insights, or follow Travis on Twitter. As always, for more insights and tips from industry experts, visit our API Intersection podcast. Stay tuned for an important announcement regarding Style Guides in Stoplight Platform happening on March 8. Thank you, Travis, for the conversation and SPS for being a member of the Stoplight Community!
