What does developer success look like in different industries and contexts? Why is it worth the investment of time and resources? These are just some of the questions that the panelists at the recent API The Docs conference answered in a discussion hosted by Carla Teixeira (DevRel Program Manager at Miro).
We thank John Daffern (Senior Commercial and Product Manager at BT Group), Jack Bambury (Product Manager at Shell), Koen Adolfs (Head of API Portfolio at ABN AMRO), and Suzanne Daniels (Developer Relations Lead at Port) for bringing their knowledge and experience to the conversation.
We’re honored to share their insights with you on the following questions:
- What is developer success to you?
- When did developer success become important to you? Why did you start investing in it?
- What are some examples of things that you've put in place that turned out to actually enable developers?
- How can developer success look different in a bigger company compared to a smaller one?
- What advice would you give to someone who is looking after empowering developers?
- Questions from the audience:
- What makes a difference between a happy external developer and a happy internal developer? Do you think there is some transferable knowledge, or are they totally different directions?
- Do you see some former decisions, made five or six years ago when the API landscape maybe looked a little bit different, that you are running into now as technical debt for example?
What is developer success to you?
John: In the last few months, I’ve been moved into a role which I suppose you could describe as developer success. One of my key [responsibilities] is to ensure the successful uptake of our APIs which are mostly transactional in my area but drive more business for our lines and broadband business.
Koen: I'm really inspired by [the expression] “time to first dopamine”. When I'm working at my house and automating stuff, if something works, that's a nice experience. And if you can trigger that [experience] with developers internally or externally, and that comes together with new functionality for a customer, then developer success is really in line with your business as well. I think [developer success is] matching the dopamine for the developers and the business model that you have, and being successful in both.
Jack: We tend to work with businesses that already work with Shell. So [developer success] is making sure they can access our services at the time they want, and do what they want to do at the time. If they can't do it, they are immediately turned off. Developer success for me is delivering what they want at the right time.
Suzanne: The discussion [about developer success] is moving towards approaching a developer as your customer and treating your portal and the tools that you offer them as actual products, so you’re giving your developers the most delightful experience possible. For internal [developers], the sense of belonging and the feeling that they don't get stuck everywhere - those are the most important components. It is mostly mindset, but also a prioritized approach.
When did developer success become important to you? Why did you start investing in it?
John: We're moving to a new portfolio of broadband products and new REST-based APIs to support them. We’re building the portal and we're building APIs at the same time. The API team was quite separate from the portal build [team] and they started to produce these APIs that nobody knew how they worked. One of my colleagues realized that we needed to get someone in just to try and explain this to the customer because you can't just read some API documentation and understand the business process. So for us [the reason for investing in developer success] was very much ‘How do we talk about our APIs to a business audience rather than just a technical audience.’
Suzanne: The problem is, how do you actually empower developers to do their work properly? One of the things that is really problematic is finding the right documentation. And if you can't find the right documentation, you're not empowered. You have a problem, and that [causes] frustration. If not everyone can access the same information and learn the same things, then not everybody plays. If you have an organization and you want to onboard new people, you need people to onboard them, but you don't have those people because they're already working on products. So all these things just add up at some point.
Koen: The term “developer experience” is something from the last four or five years, and for me, that journey started with launching the external developer portal. In 2014, the PSD2 regulation came into banking and we needed to offer payment APIs to third parties. So we needed to invest in [offering] APIs as a product to third parties. We combined what we already did with internet banking and mobile banking with external developer experience, we set up the API documentation, and then we were looking at internal experience. The interesting part is that that external shop is easier to build than that internal journey. That internal journey is one hell of a journey.
Jack: Shell has built APIs for years, but we only did them internally. So how do you then externalize them? What do you have to tweak and change? How do we share something a customer actually cares about? [We started with] a couple of people, and now we're a team of twenty, so it just grows exponentially. You think it's just a little bit of an idea then you're monetizing and creating a whole new ecosystem business model. You start from a lot of legacy and then you go ‘let's tweak it and do something’. And there's a lot you can do without having to go and build a whole new back-end to it.
What are some examples of things that you've put in place that turned out to actually enable developers?
Jack: Having a service center team of like three, four or five people who were dedicated to serve our partners on individual queries was super important to go from zero to [where we are] now. Now we can automate and self-serve and work with partners to self-serve customers better. Instead of onboarding like one customer a week, we can do about thirty a week. That was a huge win for us.
Koen: Having one internal API gateway where you can police the API experience on, where we have an API competence center, which is approving API designs in both integration, architecture, specification, and resource model. I think centralizing that policing is a good choice that the organization made a couple of years ago. And then to design that part, we created a very nice API handbook and we invest a lot of time in that API handbook to document our processes. We also introduced API case management, which is an internal tool that really enforces our processes.
Suzanne: We had a lot of problems getting our developers to work on a new platform to collaborate on. To be honest, the collaboration was very bad. And there were a lot of discussions about unclarities. To solve that, we went back to the problem board and treated it as a product. It's about deeply understanding the question they have and creating an experience around that. For the developers, it was a delightful experience. They were able to understand really deeply what it was and how it worked. It worked for them because they knew they could find the documentation and they could push the button. It wasn't hard to do.
How can developer success look different in a bigger company compared to a smaller one?
Koen: Even within a big enterprise, you have small enterprises. If we look at Tikkie then I see one smaller company within ABN AMRO, dedicated to one product and their API and how their journey from business to developers is. If you want to have that on a larger scale in the whole organization, that becomes difficult, because everybody needs to have the same way of thinking. But even within a large company, the startup mentality can be there in certain areas. And that's nice to see.
Jack: I think no matter how big or small [the company is], focus on what your business world has a value for. Why should developers be using your services? What's the value your company adds? And focus on that. Don't think about making money too soon. Get partners on board and get feedback early. Don’t try to do too many things at once - just focus on some really key ones, and build from there. A big company will put more money into it, and if it's a small company, it’ll grow quicker. So either way, it works.
John: Even when you're in a big company, start small and challenge those preconceived ideas that you have. Some of the most insightful things that I've had is when somebody else has interviewed the customer for me, and I’ve taken that feedback. It has to be at the right stage of the cycle. So if you are at that sort of early stage where things haven't become a monolith, and they haven't become that sort of “truck on the road” that you just can't turn around, take those learnings early.
What is the one piece of advice that you would give to someone who is really looking after helping and empowering developers?
John: Listen to your customers. Sometimes your customers ask you for something specific, but what are they really asking you for? They've got that one thing in their mind because that's what they think they need to do their job. But you have to step back and ask ‘What's your end objective? How can we help you towards your end objective, rather than just the question on your list today?'
Koen: Yes, as John said. Leveraging on that, I see in our other channels that we have all kinds of best practices. For example, you're going to sit next to a customer and you are going to track where they are looking, and you are testing your products before you bring them to the market. Testing how the things work, and seeing how people are using them has also been a crucial point for us.
Jack: Make sure you are always making conscious decisions towards something, towards what your vision is and what your goal is, and be clear on what you're not going to do as well as what you are going to do. [Otherwise] you'll end up trying to master too many things at once, so just think about those trade-offs and why you're doing them.
Suzanne: It is important to think not just about the metrics, [but to] look into more human components that you can maybe measure. If your developers are happy and productive, only then you can ship great products. If you offer good experiences to everybody inside, that will reflect on the experience outside.
Questions from the Audience
Leading up to the conclusion of the discussion, the audience also raised some questions.
What makes a difference between a happy external developer and a happy internal developer? Do you think there is some transferable knowledge, or are they totally different directions?
Suzanne: For your internal developers you are worried about retention, onboarding, and collaboration. From the external point it is more limited, but there's also some overlap because you want them to be involved with your product, you want them to feel that they are a part of your developer community and set them up for success. So having documentation, and making sure that they are able to go somewhere when they need support [is important].
Koen: If you have a good internal developer portal for your own developers, you're also setting the basics for a good developer experience outside. The other way around, what I learned from external developer portals, I can bring that insight towards my own internal developers, so there is a strong connection.
Do you see some former decisions, made five or six years ago when the API landscape maybe looked a little bit different, that you are running into now as technical debt for example?
Koen: Of course. Working at a big bank we continuously talk about IT debt. Because once you create software, you already have new IT debts created by the next way of thinking. For example a couple of years ago, thinking in SOAP, we thought it was the enterprise service bus that was the holy grail to create a logical enterprise architecture. Then we've put our external API case on top and we thought, 'we miss something in the middle.' So now we have that internal API case, with REST APIs. We still have a lot of SOAP services not integrated to the internal gateway, which we try to expose by the internal portal, but that's still a journey to get that into the future state architecture... And we already have graphQL. When we started, when we created our first developer portal, a year in I thought, 'I'm done. That's nice.' And it doesn't work that way. Indeed, with IT debt there's always something new.
John: Yes, big companies have technical debt. Often we have to build something because it is the quickest, cheapest way to build it. Not because it's the strategic thing that's gonna serve us for years. And we know that and we do it because we've got customers who want something now, [even though we know] we're building technical debt.
Jack: In a very similar vein, [with] Shell being in the mobility space moving away from traditional fuels to EV vehicles, it has acquired various companies over the years and the more you do that, you just get a new company's tech along with your own that you already had. [We have to make] sure that how we present that to a customer, you just see Shell. It's still the Shell logo, so we have to present a unified front and it's a tough journey.
Acknowledgements and closing thoughts
We’re immensely grateful to our panelists for sharing their insights. We would also like to express our gratitude to Carla Teixeira for moderating the discussion and ABN AMRO for providing the venue for the event. If you are interested in hearing more about developer success, you can check out our Developer Success podcast, and if you’d like to receive regular updates about devportal-related news, you can also sign up for our newsletter here.
All Pronovix publications are the fruit of a team effort, enabled by the research and collective knowledge of the entire Pronovix team. Our ideas and experiences are greatly shaped by our clients and the communities we participate in.
