“Some of the biggest companies out there are transforming into API companies, bringing people along that journey quickly. It’s an exciting thing that we’re doing, but it takes time to get it right. It hasn’t been an overnight thing.”
— Matthew Forrest, API Product Manager at Fiserv.
This week on the API Intersection podcast, we chatted with Ryan Clifford, API Product Lead, and Matthew Forrest, API Product Manager, at Fiserv. Fiserv is a Fortune 500 fintech company with around 40,000 people across the globe and an API team of 20 that focuses on enabling money movement for thousands of financial institutions and millions of businesses. Full disclosure, they also are a Stoplight customer, so stay tuned for more details about their success in an upcoming case study.
Trying to juggle a massive company alongside a transforming industry and many APIs isn’t easy. But luckily for other enterprise-level API teams, Matt and Ryan have some great advice on what to keep in mind when running an API program at this scale.
1. Align Silos and Create Consistency
“One of the big challenges in doing what we’re trying to do is to align everything under one roof, one developer portal, and the same standardization across the board,” shares Ryan.
With a large organization like Fiserv, there are many groups to liaise with, multiple leaders to speak with, and various products to consider within the larger organization. Company silos quickly become a thing, so it’s prudent to be able to reach all areas and understand the architecture of products across teams.
When navigating an enterprise-level company, the other issue is accounting for the various technologies acquired under the same brand. Matt’s team is responsible for building and delivering both functionally and the design layer on top of all of the different technology umbrellas that reside under the Fiserv brand. The API team needs to take a considerable amount of time thinking about what the overall strategic platform will be and recognize that there are migration needs of different customers to newer systems and different technologies across the company.
“What’s been nice to see over the last 18 months is domains working a lot closer with us and actually coming to us saying, ‘hey, we’re starting work on something. Would you mind helping us with some of the design?’ It’s a bit of a ‘let’s help you learn and let’s work together,’ which has been nice,” shares Ryan. “It’s great to see the organic growth as the organization gets used to this idea of being API-first or design-first mindset.”
Before anything is even developed, the Fiserv team focuses on getting a design implemented first, even if it’s a rough design. Then, they engage with the customer for early feedback and build out from there.
Fiserv’s API team focused immensely on driving the broader organizational consistency in terms of how API design is done and using the externalization factor as a lever to drive home that standardization.
“There has been this kind of established set of standards that the domains are now adhering to even when it comes to the internal APIs,” shares Matthew.
Trying to create that level of consistency when it comes to the design of APIs, the types of fields, the types of data types that you’re using, how to do things like pagination and sorting, etc., can be complicated. All of those things need to be consistent and easily interpretable by clients to create additional business value down the line.
“We are seeing this kind of level of standardization take place for sure. It might not seem like it, but these things affect your adoption significantly. I think it’s definitely a living, breathing thing for our kind of design style. I think it’s exciting just to see how our team of API product managers has put in little rituals and how they’ve adapted over time,” shares Ryan.
Over time, one instance of that adaptation involves how the team conducts design reviews. The Fiserv team used to have an API manager go away to work with a designer on the API, then return to do a design review just with their team. When they had a finished design, they would then show the design to the broader team to provide feedback and ensure consistency across all APIs. But, now the Fiserv team has found a more effective way of doing it; it’s not just about one end design review, but multiple reviews as you go throughout the design process.
“So, for example, we just had the first conversation with the domain to understand how to do a specific API. They will come back to our team and one of our team meetings, and we’ll just say, ‘Here’s the output file I’ve just found from this domain, what’s your thoughts on it?’ They haven’t actually designed anything yet at this point, but it’s kind of an iterative team-creating process, and it’s nice to start that early on as opposed to waiting for this end design,” shares Matthew.
The Fiserv team emphasizes that, in actuality, there is no ‘end design’ even in their old way of conducting design reviews because once an API goes into development, you’ll likely be tweaking a design up until it’s deployed. Even then, you’re managing it as a product, so it will change again after that. Therefore, keeping that constant iteration and multiple design review checks during the design phase ensures better consistency, closer collaboration, and a faster time to get their APIs into development.
If you’re looking for more tips on improving consistency and standardization in your own organization, here’s how you can enforce that more robust governance.
2. Build for All API Experiences, Not Just External
“Obviously, we look a lot at the experience layer of APIs, especially the ones that are external merchants and organizations that use us and will want to integrate with us to access the features that we provide,” Ryan Clifford.
However, as Fiserv’s API strategy evolves, the team has found themselves included more and more on the internal experience layer as well.
“Lately, we’ve been clued in on more internal API discussions, especially when it comes to what we call domains and our different system teams building our APIs. Our mindset is that the better our internal APIs are, the kind of better experience we can incorporate for our external APIs and overall API strategy,” shares Matt.
Internal APIs are just as important to your API business as external ones. In fact, for most companies that create APIs, the number of internal APIs they develop and use dramatically exceeds that of external APIs.
Over 75% of developers reported working on internal APIs according to RapidAPI’s 2020-2021 Developer Survey (if you need a proper resource on best practices for internal API creation, look here).
3. Place Importance on Customer Validation
“Leveraging customer feedback to build customer-centricity and empathy will keep you is so important,” shares Matthew.
API leaders often tend to get stuck spending too much time obsessing over their APIs instead of just reaching out and speaking to customers to get feedback early on. Taking in that customer feedback and continuing working with your users will help align your API strategy with your direct vision and goals for the future.
“We have existing customers who are eager to get access to certain things, so it ends up that we’re delivering stuff for customers who want it right now. But if we had the time, I’d like to conduct some good user research and understand what they want and how they want to consume it best,” shares Ryan.
Getting a few of your early and loyal customers together and collaborating with them on the design of what it is you’re actually trying to build will produce results much quicker than back-and-forth iteration with your internal team. It’s even better if you can do that without the overheads of technical debt and established architecture.
“One of the things that we are actively encouraging and doing more of at Fiserv is encouraging feedback all the time and early on via our homepage where we say, ‘here are our ideas, here’s our roadmap. Come and speak to us!’ And if a feature is something that folks really want, then our team will go ahead and build it,” shares Ryan.
4. Hire Key Talent
“I think the talent you bring in is so important. We’ve been lucky that we found some incredible people, but it wasn’t easy,” shares Ryan. “We conduct many interviews, and we are relentless in looking for people who have an element of being proactive in overcoming barriers, being major problem solvers and critical thinkers.”
Without the right talent, it is hard to accomplish anything on your API team, especially as you scale out a new program. Focusing on those soft skills of critical thinking and tackling challenges head-on should be just as important as the technical skills you’re interviewing for in a candidate.
“Challenging the status quo without taking over is important. If you want to conduct transformation around your APIs, step one is to build your band of rebels. Figure out how you will cross all the existing silos and lines,” shares Ryan. “That’s exactly the range you have to play to really drive a transformation. It’s to break the current rules and make new ones, envision a different future, and be willing to look past today.”
A good API team takes on a ‘rule-breaking mindset’ to get there. The Fiserv API team will continuously challenge things, develop new and innovative solutions, and think well beyond the typical box they’re put into. That’s the kind of talent you want driving your API strategy.
In the end, it’s always a mix of getting the right people and the right processes in place to achieve a well-functioning API program at scale successfully. I think Fiserv is doing an excellent job, and I look forward to seeing what’s next in store for them as they hire more developers this year! As always, subscribe to the API Design blog or our podcast for more insights.
