Chris Traganos, Stripe

All right, welcome to another episode of Breaking Changes. My name is Kin Lane, I’m your host. Today I’m the Chief Evangelist for Postman, and with me today I have Chris Traganos from Stripe joining me. Welcome, Chris.

Hey Kin, thanks so much for having me. Really appreciate it.

Yeah, no, thanks for joining me. I have been really eager to get you on the show and learn more about your style, how you all run your community over there, and how you do what you do, so I’m really stoked to have you here. Our audience is pretty wide. This show tends to go out to business users, and I’m not going to assume everyone knows who Stripe is. I’m hoping they have an idea who Stripe is, but let’s start with the basics. What is Stripe?

For sure. Stripe is first and foremost a technology company, and we focus on building economic infrastructure for the internet. This means businesses of any size, from startups all the way to public companies, are using our technology and our software to build online payments and to run their financial operations in, I think at this point, over 100 countries around the world. So that’s the summary of what Stripe is.

For me, any startup I’ve ever done, any app that I’ve built, once you hit that point where you need to make some sales, sell some products or services, do anything financial, Stripe’s where you go. You guys are the foundation of what I would say is the API economy as far as making it so that we all can make money doing what we do. But would you say that payments is the biggest impact Stripe’s made? I feel like you guys have also made an impact on just how we think about APIs, and I know you make lots of investments. What is the greatest impact Stripe’s made to the ecosystem, would you say?

I’ll just speak from my perspective. I don’t know what the official biggest contribution would be, but I would say from what I see and from my experience, the biggest contribution Stripe’s made in terms of impact is that first and foremost we were focused on the developer experience. It’s pretty exciting to work on a product where we put so much time into our docs, our web pages, just the experience of a developer connecting up into the API. Obviously we can talk about vanity numbers and everything, but just how many updates even today we’re putting into the API, all the parameters, the functionality for testing. It’s pretty fun to be on the inside and see just how much, first and foremost, we focus on being a developer experience company.

That’s kind of what I was getting at, because that’s what I think of. Y’all are a shining example that I point to when it’s like, how to do your docs well, how to do your developer experience. There’s just so much that you guys bake into the overall developer experience. So how do you see product adoption and developer experience working together in this way when it comes to getting people learning about Stripe, onboarding, and actually putting it to use in their applications or business? How does developer experience feed into that?

I think a lot about, I remember back in the day living in San Francisco, you’d see that huge Twilio billboard. I always got inspired by that, that’s the big one off the 101 or 280 that said just like, “Twilio, ask your developer.” I do think that we do best when we are the first recommendation from the payment infrastructure team or the payment architects or the developers that are trying to get a thing done and they know they need to rely on a product that works for them and is going to be able to support whatever they need. It’s pretty wild the different ways you’re going to be using Stripe to customize it for your own payment flow. Every single company’s revenue model is different, and so it needs to be about as adaptable and extendable as possible. How that leads to adoption mostly is recommendations. I think we just hit our 10 years as a company, and you would imagine for the majority of that time it’s word of mouth from developer to developer. You think about venture-backed startups that very often will build a product, and then demo day comes and it’s like, oh my gosh, we need to have our pricing page, payments is the afterthought because they’re focused on maybe hitting certain other numbers. But then the rest of the world is trying to accept revenue and collect revenue and make payments on day one, and so they’re going to be looking at what’s the top tools to accept payments. We want to always be in whatever developer community it is, whether it’s enterprise, SMB, startups. We want those actual frameworks that they use in those communities for it to always be like, it’s Stripe, definitely use Stripe, it’s going to save you headaches.

I’ve built a lot of commerce apps. I’ve been building and running teams since the 90s, and I’ve worked with a lot of payment providers. You mentioned allowing us developers to do what we’re doing best and focus on what matters so that we can make money. One of the things that changed when I started using Stripe is I don’t have to think about PCI compliance like I used to. I used to have to also become a security expert and think about how I’m storing credit cards, and Stripe’s abstracted away the payments industry but also a lot of these other things, so I can focus on what I’m doing best. That’s what fed into me having more time to even spread word of mouth that Stripe matters, because I don’t have a headache of having to store credit cards. I could go on and on and find a lot of other things that have fed into that. But do you see that with your developer communities? Are they just able to do more of what matters to their business each day because you guys have kind of abstracted away a lot of this complexity?

Yes, I would say I’ll speak from the developer’s perspective. You and I both are in the developer relations world. First off, Kin, I’ve been to many of your talks, so it’s fun to chat about developer experience with you because we’ve, two old dogs, have been thinking about this for a while. For payments, for Stripe especially, my impression from the outside, I joined about three years ago, but my impression was always like, all right, it’s an API, fire some card numbers at the API, make a request, get a response, 200 OK, payment succeed. Now working here and just being in the financial world, you realize how much more complexity there has been in the last couple years with online payments. There’s payments, but you’re referencing this whole world of know your customer, so customer onboarding and customer payment collection. How often do we sign up for like a marketplace where it’s like, oh yeah, I got to add my ACH bank routing info or add my card info. How much weight is on the individual entrepreneur or company owner to maintain all those details? Not to mention most developers, especially in the western world, can tend to forget that there’s a whole lot more than just cards. If you’re accepting payments somewhere else in the world, the burden and the regulatory requirements to just run a successful compliant business is intense. So there’s this whole other world of like Stripe Connect, where we build platform tools for platforms to be successful. Definitely some of the biggest platforms and marketplaces of the world are using this tech, collecting customer data and storing it safely, which is pretty dang important. I think beyond payments too, you think about if you want to accept in-person payments, maybe you’re running a live events company or you’re running some store that you are internet first and you want to have a point of sale system. Another thing that was eye-opening to me is how much burden the founder has to deal with syncing up in-person point of sale systems, online orders, mail orders, phone orders, and how often many companies struggle with having a single place of truth for customer records and product details. And yeah, I could go forever about the complexities of doing payments, not to mention optimizing it so that you’re actually not leaving any money on the table.

That’s huge. These are all things you don’t learn until you’re down in the trenches doing these things, and you’re just tactically kind of piecing it together. That’s part of your developer experience that I’ve noticed, that you guys aren’t abstracting and hiding these things away, it’s actually part of your rollout of new services and the overall docs, your SDKs and your tools, and everything kind of helps think through all of these things and know that there’s actually a strategy to it, even though I as the entrepreneur maybe haven’t encountered all of these needs. I’ve seen it in your docs. I can go find it and learn more about it when it comes up in my daily work. So what would you say, when it comes to developer experience, is top of mind for you when it comes to helping reduce friction for us new customers who come across Stripe and are trying to get going?

I think in terms of one of the top things, reducing friction and pain points, improving the developer experience, one thing that is top of mind for me and our team of developer advocates at Stripe is, no question, developers are very smart, developers are masters in many languages, many frameworks, understanding how complex systems work. One area of difficulty we continually run into, when especially a senior developer starts getting up and running with payments, is that the semantics and the terminology between payment infrastructure, finance, and developers are so similar but they’re wildly different. Very often I’ll realize, when meeting a developer, well before COVID meeting in person, talking to a developer online like in one of our live streams or in different conversations, when I talk about authentication, I’ll go into the importance of authentication, or how Face ID and biometric info is required to have certain payments in certain countries, a developer can often just jump straight to, oh yeah, OAuth, I know what that is. You also don’t want to be a jerk and tell them you don’t know what you’re talking about, but because the terms are similar, they’re all needed but it’s really hard. When the developer is told by a founder, or they are the founder, or they work at a large company and they are the payment architect, “okay, get payments up and running,” they’re trying to solve it like an engineer would solve it. But if they don’t have an idea of the revenue model, the business use case, how this syncs in with taxing, tax revenue recognition, all these terms that are not in the developer world but they are critical for payments, that can be a non-starter to actually get payments up and running. So I guess that’s addressing a big thing in the industry that happens often. No developer wants to admit, when you get started with payments, just accept you have no idea what you’re talking about and take some time to watch some foundational videos, read through the docs, really trying to wrap your head around how the heck does payments work. I think the second one is payments are progressive. There are great no-code solutions. If you were a business and someone’s trying to get payments running on day one, what’s the easiest way to get payments running? Probably a hosted checkout page, or just sending a hosted invoice, saying okay we’re accepting some one-time payment, good. And then over time the founder and the tech team are going to figure out, okay, how should we extend our revenue model, should we support both recurring and one-time payments, should we also support in-person payments. So it’s kind of like figuring out your payment strategy. Reducing friction requires you to have a baseline and then build on that as your company starts to get more advanced in the strategies of optimizing your revenue flow.

One thing I felt like Stripe’s done well over the last decade is making it more accessible to even non-developers to be at the table. I think as developers, if we can have a domain expert from our company at the table, having them as part of the conversation, we’re going to be way better off. I think classically business and IT folks don’t talk and don’t hang out, but Stripe’s simplified a lot of things along the way, with the low-code options, with the accessibility of your documentation and your overall developer experience. I don’t feel like you have to be a developer to land on Stripe’s homepage, make your way around the site, understand what’s going on, and be part of a conversation. You may not get your hands dirty when you dive into the SDKs and other things, but it definitely makes it more accessible. Are you guys really trying to speak to business users as well as developers in all of this, or did it just happen naturally?

I would say first off, being in the developer community world, one of the biggest mistakes we could make is say the word developer and think it’s some all-in-one persona. There is no such thing as a developer. There’s a blend of folks that are involved in the payment stack. You need buy-in from the decision makers, from the product folks, you need developers understanding what their part in the payment stack is. Very often we’re looking at what are the top requests we’re seeing in support, and if you’re on any one of our docs pages you can right there give a thumbs up or thumbs down on the page and give us a note. We pour through those notes, and very often we’ll see the rise of no-code or low-code solutions, whether it’s a Stripe solution or some partner that’s integrating our API, it’s increasing a lot. So it’s not enough to say okay, we just focus on our API ref or our deep docs. We really have to make sure if you’re trying to get your no-code app or platform up and running, you’re going to pick the best tool possible to start collecting payments on day one. Often it’s a partner’s app. We have this whole marketplace, we strongly recommend partners that make it just dead easy for you to get up and running. But also half the challenge is making sure you’re getting started with the right Stripe tool for your use case. I would say almost always it’s going to be Checkout or a deviation of that. So Payment Links is super popular right now because it lets you just generate one-time or programmatically reusable payment links where it’s all hosted, you don’t have to think about receiving webhooks and running a whole application, you just want to collect payment. So that’s some of the biggest growth, docs and content and especially video resources for folks that might not identify as a developer but they’re very much part of the decision-making process for a company.

I think the whole classic product catalog, cart, checkout still exists, but I think that world is much more distributed. It’s across social, it’s in person, and so there’s a lot more people who are implementing and setting those in motion, not necessarily someone building a commerce app or a mobile app. We can sell something and ask for a payment in just about any business process that occurs throughout the day. So I can imagine that linking is going to be pretty powerful. We’re seeing that in the Postman ecosystem as well, as embeddable. It’s not about a single portal for developers anymore, it’s about anywhere you need to initiate some API workflow or something that’s API driven, and giving people embeddable links is pretty key. Another area that we’re seeing a big shift is when it comes to open source. It’s one of the hats I wear here at Postman, in addition to being the host of the show, around the Postman Open Technologies program, because we see the technology is often more open source and the way the money’s made is a lot different when it comes to API integrations. I noticed that open source is a part of your title and what you do there. How does open source fit into the Stripe paradigm?

Yeah, definitely open source is so critical for everything we do within Stripe, but also how many of our customers are using open source. They might not realize it, but payment stacks, there’s many different areas of the payment stack, whether it’s the application layer, the UI, actual collection of the payment, there’s lots of open source packages, dependencies, and projects. There’s kind of two different areas. We’ve open-sourced several projects. Sorbet, it’s for having strongly typed support for Ruby, that was the big project we launched about a year and a half ago. We’ve got several projects in the works that we’re focusing on open sourcing for next year. So part of our team, we’re a small team, the open source team at Stripe, and we’re focusing on making sure internally there’s great candidates for things to open source. I think a lot of our effort actually has been on finding and identifying developers in the community who have been building excellent plugins or extensions or any type of libraries that help customers do more with Stripe, and just making sure, first off, we’re reviewing a lot of them, we’re dogfooding them. What I’ve been excited about is a lot of our engineers have been making contributions to popular Stripe plugins and frameworks. It’s a big focus for us, honestly. The other thing we’re super proud of is we launched a book, Stripe Press, it’s like our book publishing arm, and there was a book by Nadia Eghbal, she wrote “Working in Public,” and it’s all about the open source sponsorship model, open source just generally, and a little bit about the history of GitHub. That book has definitely inspired us. There’s also a ton of new sponsorship players out there, you know, Tidelift, GitHub Sponsors, Open Collective.

Oh, you got the book, awesome.

Yeah, that’s it. I love it, it’s actually a pretty beautiful book. But we love that there’s all these companies and marketplaces launching around helping developers have sustainable open source projects, and that’s definitely top of mind for us often in our world.

Yeah, that’s a great book. I like the way she tells the story. GitHub is a great foundation for a lot of how we think about open source, or at least the evolution of open source. We went from Linus and Linux to like now it’s a more social, more human thing. From what you described, it’s much more community driven now, it’s much smaller, micro, it’s plugins, and it’s even content and blueprints and tutorials. We see that with Postman collections, people building interesting workflows between multiple APIs and then open sourcing that script or that orchestration, that automation around that. So open source is definitely going into kind of a third generation, I’m hoping, as far as it being more community driven. What are some ways, you mentioned that some people don’t even see open source or know that they’re using it, what are ways that you recommend people can better notice and then maybe support those projects?

I think on the onset, one thing that keeps coming up with our developer advocate team is very often developers have inherited a payments integration. I’ll talk about payments in open source, I guess, to start, because I’m obviously biased, I care a lot about payments and folks having great integrations. In the payments world very often a developer inherited a payments integration. There’s obviously multiple gateways, we’re not the only one, we know that, and we also know that a lot of customers need multiple payment solutions depending on the use case. So Stripe is always used within the context of a broader app, and so often you inherit a payment integration. One thing that keeps popping up often is whoever is the head, or at least responsible for the payment integration, might not necessarily even be able to whiteboard out how payments are working at their company. They might say, oh yeah, it’s set up through Laravel and something puts in the form field and then it goes to our Stripe account. So one thing that comes up often with open source is, do you even know all the different pieces of code and plugins and libraries that are between you and your customer and revenue? Just doing that inventory I think is really important. And then the second part, to bring it back to these open source maintainers, is just the empathy we have for these maintainers who often maintain or built it because they had a problem they needed to build a certain library or plugin for, a very specific niche CMS or some type of framework that wasn’t out there. If you read the “Working in Public” book, a lot of these maintainers didn’t sign up to do support for thousands of users that stumbled across their GitHub repo. One thing that’s top of mind for us is, how often are these startups, SMBs, and enterprises just using some project not thinking once about the health of that project, who’s building it, the long-term viability of using a product. So the thing we’ve really been focused on is encouraging customers and developers, if you are going to use open source projects, know who’s building it, definitely offer to help with code contributions. Updating open source projects, especially if it’s something that stitches to other APIs, takes work, and so often these developers are looking for support, even helping triage and tag issues, that’s a big one. For a lot of companies, the call is, if you’re using third-party code to collect revenue, one, know how that code works, do a full review of it, but also what’s the responsibility companies have to also consider sponsoring these developers who are building really important projects that they need. We’re often thinking about that. We’re noticing a lot of companies starting to figure out how they’re going to give back to either specific open source maintainers, or even open sourcing projects that they’ve been running internally and haven’t even thought that a lot of other developers could benefit from this.

It’s so important, making sure that these projects are seen, make sure they’re supported, they’re secure, all vulnerabilities are dealt with. You should just know your dependencies and understand how they work. You should have the inventory of these. If you’re a developer that implemented that library, if you as a manager can carve out some time for that developer, give them 10, 20 percent time to go to the repo for that library, spend time triaging, maybe even just clean up, even if they’re not contributing code, help clean up the docs. There’s so many things that they could do for that library to make it more usable, more sustainable, as well as give money. I think money is an important one. The more we support these, at least in the Postman ecosystem, the more we support these, I would say we have a direct line for talent acquisition in some of these. I speak from a vantage point of, I’ve acquired a couple open source projects and brought them under our circus tent of Postman Open Technologies, and it’s because we want to support and sustain that open source project, but also because there were some really driven, passionate folks behind those projects that we wanted to actually work with closer. I don’t think a lot of companies see these projects and see them as potential talent acquisition, people who are smart and can come in and help you do things. Not that you should acquire them and bring them internally, but find ways you can work closer with them. I think that’s super important.

Yeah, it’s an interesting tension. Some of the best projects we find, developers are fiercely independent, but they would love and appreciate code contributions, they would appreciate us recommending their project if we think it’s going to be great for users. It has been interesting, some of the most successful open source partnerships we’ve had are developers that are super proud of the framework, they know every in and out of a specific framework, let’s say Vue or Angular or something, they really care about that, their full-time job is adjacent to that work, or they do freelance or contract, or they are monetizing their expertise being the world expert in payments for a framework. So often it is a dance of making sure they feel supported but also recommending great projects from the community. Another thing that’s top of mind I’d love to chat with you about is actually Postman related. I know this is not a Postman-focused podcast, but just the importance of cutting down tech debt by keeping the versions of these libraries or SDKs you’re using up to date. I think that is the dirty secret of the payments world, folks don’t update their stuff out of fear of breaking changes.

Yes, man, you just hit on it. You brought up Postman, which, this is not a Postman show, we don’t focus too heavily on, but then you managed to say breaking changes too, so I kind of weave that in.

No, but seriously, imagine, as a developer advocate at Stripe I have one of the best shops in the world. I get to meet all these different startups and companies building incredible products that are making revenue. We’re only working with folks that are charging for a good or service and rendering some value to a customer. I’m learning a ton about what revenue models work, which ones don’t, which ones have buzz but actually, and these understated companies that you’ve never heard of, they’re not on Hacker News, but they’re making hand over fist revenue because they started off on day one charging for their product in a reasonable way. I love the job because I get to meet all these different companies. What’s been really interesting, as I hinted at, is the biggest brands in the world. I’ll talk to their payments lead or the head dev who’s building or improving their integration, and a lot of them kind of in confidence will tell me, oh my gosh, we haven’t updated our API version in five years, in four years. The previous CTO integrated it. The ones that are really honest are like, I don’t want to be the person that breaks our payment flow, we’re making money, I don’t want it to break. So what I’m realizing is, I know that’s probably not a surprise for you, Kin, but just generally a lot of developers have not developed good hygiene around just regular incremental updating and upgrading of their tech stack, so that they don’t go years on end not upgrading both their API versions and the versions of their SDKs. It kind of surprises me.

It doesn’t surprise me. People fear change. Change is scary and people fear it, and like you said people don’t want to be the one to break it. But for me, breaking changes aren’t bad. The only time breaking changes are bad is when they’re not communicated and not planned for. I would say Stripe has some amazing approaches for managing versioning and communicating versioning. But why would you say these people, are they not aware of your new versions, are they not comfortable or confident updating their code, what’s the biggest friction point for them moving forward?

I think it depends on the individual, but I know for some examples, payments, it is tempting, especially with Stripe, we’re in the news a lot, there’s a lot of buzz around the business, it is tempting to forget that we are just one piece of your bigger web stack or your payment stack or your mobile. We serve one place, and there’s a lot of other services you probably use to support your customers. The reason I say that is because it is one in a bigger checklist of things the developer has to worry about. Very often a CTO is also on the hook for payments, that CTO is trying to make sure all the latest builds go out to iOS and Android app stores, they want to make sure top-priority customer issues are getting dealt with. While we care a lot about API reliability, yes we’re proud that an API version from six years ago will still work because we want to make sure nothing breaks in your payment flow, but you’re kind of leaving a lot of literal money on the table, and you are building up tech debt if you’re not incrementally improving your stack including payments. Sometimes it’s just, oh someone built that a long time ago, it works, we don’t want to break it, and we get a lot of other fish to fry. Another one is just a general culture, especially in the startup world, of celebrating ships, celebrating new releases, and kind of de-prioritizing or not celebrating as much keeping-the-lights-on work and just having a really good testing and upgrading plan. It’s often that you’re like, ah, we’ll deal with that later. I guess the last point I’ll make is where it’s extremely painful is, while we will keep API versions working as long as humanly possible, you need to opt into upgrades for Stripe. You need to say, I’m ready to use the latest version of the API, or on a per-API-call basis you can tell us what version of the API you want back from us. Where it gets really challenging is when a country or a suite of countries or some regulatory authority is like, hey, so Face ID or thumbprint fingerprint recognition is required starting September, and it’s happening and you got to deal with it. That’s where it’s like, when you look for a new job, it’s better to look for a new job when you already got a job. Same with API upgrades, it’s great to upgrade and have a plan for testing before you’re told you have to by this date update or payments will stop working. That’s the worst-case scenario, I think, for devs, oh my gosh, we haven’t touched this in forever.

Well, you guys have done so much of the work in moving forward with versions and reducing the friction for people, so that it’s not as painful to go from even major to major, because you guys have done a lot of the thinking and reduced that. Teams need to be more agile and nimble when it comes to addressing change, so that they’re not caught off guard when these regulatory things come into play and they have to also just jump and make a change. They need to be thinking about this in an ongoing way. Getting leadership to approve that and prioritize that, but I like what you touched on as far as you’re literally leaving money on the table. That’s the message I would leave for leadership, to carve out space for the teams to invest in change and evolution. There’s all of this new types of payments, new ways of making payments, micro payments, different ways of doing it that your newer APIs are enabling, and if you’re not upgrading your version, those things are out of reach and you’re not able to remain competitive, stay agile, nimble when it comes to your industry.

I’ll add to that. It’s also tempting for companies to just clump everything around payments into a set of functions or one area of problems to solve. The reality is, if you break up payments, your customer onboarding flow is something you can upgrade in and of itself by itself. You might have a one-time payment and recurring payment offerings. Whenever I go into an app in the app store and I look at all the different in-app purchase options, you often can see a history of all the different payment tiers they’ve created. The point being, if you break them all out, it’s like any complex project, if you break them all out and decide what are the things we need to fix now, what other things can wait, it’s less overwhelming than, oh my gosh, we need to fix our payments, which is such an amorphous challenge to face. The success stories I love hearing are, okay, we needed to upgrade our integration and we actually removed like 10,000 lines of code because we realized we were manually running a recurring billing system and we could just cut it and go with your billing offering. I’m saying this so this is applicable for any payment gateway, not just to make it about us, but very often if you built some application or function five years ago, there’s probably better ways to do it now. Things are not set in time. For our own, I was looking up the numbers for this call, we handle this year alone, I think it’s about 5,000 requests every second for our API, this year we’ve deployed over 3,300 times, and about every weekday it’s about 13 to 14 versions of our API we cut a day. So the point is, imagine six years of that. Yes, it’s going to work, it’s going to function, but oh my gosh, become an expert in payments so you make sure every single drop of what your customer wants is available for them and also for your setup.

That’s, I mean, you guys have embraced change. That’s one thing, in the people I’m interviewing for the show, the companies that are leading the API conversation are releasing often and they have processes in place to allow for that, to deliver more reliable APIs and then support, not just the producer needs but supporting the consumers is a super critical part of this. So when you’re the front line for that, what do you look for when you’re hiring team members or bringing people onto your team to support this perpetual march forward of the Stripe API?

For sure we’re looking for developers who really really really care. That first and foremost, when it comes to long-term health and upgrade of your APIs, when it comes to our developer tooling, making sure developers are feeling, all things developer relations, where it’s not only getting news out from the company to the community, but it’s also, I think one of the most important things is driving empathy for developers from the community internally. I love my relationship with our product teams, they really care about developer feedback. We have a champions program where we take our most ardent, most avid developers and they have a direct relationship with our product teams. You’d be surprised how much on Twitter our engineers, our PMs are answering or asking questions. So developer feedback’s super important for us. Another, for new candidates and also folks that join our team, we really cherish this thing called the friction log. We try to dogfood as much as possible, and I’m talking every team, product, engineering, marketing, support, and what that means is just opening up a new doc, and if we’ve released a new feature, or existing features, or trying to use two or more of our products all together, just writing out the experience of getting up and running with it, what worked, what didn’t, what could be better. That’s definitely an internal form of currency. The folks that are just genuinely curious, they’re down to try out new products we’re releasing even if they’re not on that team, it goes a long way, because I really appreciate when we’ve released something, we just released our new Postman collection, we just released, my team built and released the new React Native SDK, I really appreciate when folks internally but also externally help keep me honest, make sure that it’s working great, and I can’t tackle all the bugs. So feedback is definitely a gift. I’ll make one other plug, I’ve been getting super hooked on this, there’s a community site, it’s also a series of books too, it’s called APIs You Won’t Hate. There’s Phil Sturgeon, Mike Bifulco, Matt and Phil. That book, “Surviving Other People’s APIs,” I absolutely have been loving the content and the podcast, not to plug another podcast, but there is a finite amount of us who care deeply about API both resiliency, functionality, the long-term health of an API. I wish we were an epidemic so we could all just get together and chat, but for sure we’re trying to learn a ton from lessons learned from other companies in API platforms.

Yeah, those lessons, I’ve been on the podcast and I’m a big fan of what the energy they put out over there, because they’re very human and community oriented and about doing this well and reducing the pain and friction. And then Phil’s whole environmental, the bike riding, I love it, it adds a whole other dimension, it’s a good vibe. So yeah, I would say the empathy piece is the most critical piece. That’s the next generation developer, the old days when you would hire developers and they were anti-social and you kept them in the basement and slid pizza under the door, those days seem to be gone. We don’t want those types of anti-social developers, we need you to actually be interested, have passion, have a fire under your imagination when it comes to this and want to be playing with things and understanding things. I think that’s why, back to the talent acquisition that I mentioned in the ecosystem, externally these are the developers that shine and show up on our radar, they become Postman supernovas as we call them, and they’re people we end up hiring and investing in if they’re doing open source. So the message out there for everybody listening is, if you just do what you do, be passionate about it and demonstrate why what you’re doing and what you’re interested in matters, people will take notice in the ecosystem. But also API providers, if you have a team that empathizes with your community and empathizes with the challenges your customers face, it’s just going to go so much further and have so much more impact. How do you guys look around the world? You mentioned you hire a lot around the globe, but your team is pretty geographically dispersed around the world these days.

Yes, especially, we’ve always been pretty spread out, we’ve had regional offices, but as of this year we’re at least in over 50 cities worldwide, and so we can hire in many different countries. I think at least 25 percent of our engineers are remote, that’s about three times more than before the pandemic. One thing that is really important for us is building the best payments experience requires developers and your engineers to be in region. It’s so often that as a western-hemisphere-based developer we all think the world revolves around cards. I know I mentioned that earlier, but it’s only until you’re actually watching how you do payments or remittances in Japan, or you watch how in Mexico you go up to an Oxxo gas station and you literally can do your payment flow for larger purchases, until you see that whole payment flow you realize, oh my gosh, the rest of the world is actually way ahead of us. We still are focused on this piece of plastic where the rest of the world is using their super-expensive mobile phone to do biometric Face ID, and then you start thinking the risk gets shifted. I could geek out forever, but basically the biggest thing is if you use a plastic card it takes, there’s a couple weeks you got to wait to make sure it clears, or a couple days at least to make sure it clears. The rest of the world is on really advanced payment methods where the payments can sometimes be instant for the merchant because it’s an authenticated payment where the customer is known, and it’s reducing your fraud risk. We’re really focused on our engineers being in region but also supporting our payment methods. Right now I think it’s like we’re available to at least over 44 countries but I’m pretty sure we can accept card payments from customers across like 195 countries, so we’re trying to be everywhere where someone’s trying to get payments done.

I’m guessing the people not upgrading their apps and their API version feeds into some of what you just said, as far as leaving money on the table. They’re not able to enable smartphone payments, and that’s why things are so slow here, because we’re so risk averse, or the leadership just doesn’t see the business value of investing and making the switch to more of a full digital world. I think that’s what everyone’s being faced with right now, or at least what we’re seeing is the API reality is catching up to every company in every industry and they’re going to have to start paying attention to it. I’m hoping COVID’s going to speed this up, because the need for more contactless payments, more digital delivery, all different types of things are going to speed that up. How’s COVID shifted the way you guys are seeing things and working? Has it changed how your team, you guys were remote somewhat before, but has it changed how you guys operate?

For sure, it has definitely changed how we operate. I know at least for my developer advocacy team, we’re spread across over eight time zones, and so really putting an emphasis on asynchronous moments of connection. We have folks across Asia, across North America, South America, Europe, we have a lot of developers in the community that are everywhere from Johannesburg to Australia, all over. The reason I’m saying that is, trying to get points across while you cannot get everyone in the room at the same time is challenging, and also building trust both with external developers but also your own team is challenging. You can imagine we’ve been heavily using, whatever chat platform you use, a lot of them are starting to release things like asynchronous video clips which is a mixture of screen sharing and video. We do a lot of video, not just Zoom calls but actual, hey, I wanted to show you this, have a look at this. If you use Slack it’s Slack clips, some other teams use apps like Marco Polo or any type of video app to build, over time, trust and connection by seeing each other but also working through stuff. Some of my closest friends from my old days at Evernote and from Roku and all these places I’ve been at, it’s the folks that we kind of went through some tough challenges and we worked stuff out, we built stuff together through adversity on behalf of the developers, and that requires a lot of connection and communication. It’s hard to do if you’re only doing text chat. So that’s one. The other one is we’re trying to be very flexible about meeting times. We split up EMEA versus Southeast Asia versus the US, and when we have meetings and we all can’t be there, writing up the top points, putting them in our channels. Now we have product teams leading different aspects of our product in all our different hubs. We have two co-hubs, the Dublin office and the San Francisco office, but then also we’ve got folks all across Europe, the payment method teams are in all the different regions because they have to build that product in region. So I make sure I do my solid work, I do turn notifications off, and I do emphasize I’m flexible with my time, but really the more we can do asynchronous the better. But yes, post-COVID I cannot wait to actually meet more team members. I miss it so much.

Yeah, I miss the in-person, the relationships that were built over the last decade. You’re an old dog who’s been in the space doing this for a while, so I know that in-person conference meetups and just the restaurant, the food, the drinks, all that that surrounds all of that, people coming together. So what else are you doing to not burn out, because that sounds like a lot? What do you do to keep yourself passionate and motivated after so long in the industry?

I’m trying to learn a couple things. I’ve really fallen down the rabbit hole of video streaming and just really getting the whole team thinking about video first. As you mentioned, I’ve been doing dev relations for, I think about 10 years ago I became a developer advocate at Evernote, moved to California from Boston. One thing that has been eye-opening is just the importance of video, and I really did not understand how important YouTube is as the second most popular search engine on earth. Whether it’s the weekend and I’m not working at all, just trying to fix something on my car or do something with my kids, I’m trying to use YouTube a ton more as a way of visually learning different concepts, whether it’s coding, something around the house, or I’m trying to improve a skill or public speaking. So that’s one, just watching more videos than just recorded series and TV stuff. The other one is I try very often to get lunch or coffees, COVID-safe obviously. I live in Austin, Texas now, so I moved from San Francisco to Austin, the exodus along with a ton of other folks, and there is just a ton of developers based in Austin building great products, and I am trying to get out and get coffee. I get so inspired when I hear developer stories about payments and what they’re trying to build or the frameworks they’re looking at, so I am using the local city as a way to get inspired. And I think it’s trying to cut off on the weekends, just trying to remind myself it’s all going to be here tomorrow, and half the time the emergencies are because of a lack of planning, so really trying to plan out month to month what’s the thing I have to get done or the team has to get done and really focusing on that. Every single day I do the Pareto principle, like twenty percent of the effort for eighty percent of the results, and just staying focused. My time is not my own anymore, so trying to work on all this to not get burned out.

Yeah, and we are so much our own worst enemies, and everything you just said, not taking away the weekend, not planning the process properly, all good advice. Well, I look forward to when the world somewhat gets back to normal and I can come to Austin again. I love Austin, I love walking around downtown down there, and not just for the big events, just coming and hanging out, there’s a great vibe down there, so a little bit jealous. I’m in the Bay Area, so still loving, still holding down the fort while you all just left town.

I mean, technically I moved in 2016, I joined this tiny YC startup and we all moved out to Austin, so I guess I’m like an old-timer Austin now. One of my favorite things, so random, but for developer meetups, we have a ton, San Francisco has them too, but we have a ton of these like half coffee shop, half bars, and what I like is meeting up with developers and there’s no pressure to drink. I just want to have a cup of coffee, because very often back in the day with developer relations events there’s kind of this pressure when you’re at some evening event. So I’ve just been loving, I’ll get a decaf coffee and then I’m not a wreck afterwards in terms of feeling full, and I’m also able to focus on the conversation. So I kind of love these half coffee shop, half bar situations.

Well, I think that’s an important life hack as we get older. That’s a good old-timer rule, water with the lime, please.

Yes, exactly.

I can point out in 2014, 2016, where I burnt out pretty heavily, and it was pretty much due to me drinking beer, so that’s good advice. The one other thing I’ll add, I know that’s not the focus for this session, but in terms of dev relations and dev advocacy, I’ve written a little bit about it, I wrote this post on the golden age of developer advocacy. One thing, if we compare life pre-COVID as a developer advocate to now, in the past, just to talk about video first, in the past I’d speak at some event and maybe there’s a couple thousand folks in the room, I hope to god maybe 500 people are interested, and I really hope that evening or the next day they actually try out the code or the sample I talked about. Now that everything’s video first, even if we are at an in-person thing and we’re recording and cutting it for our channel, it’s just wild the amount of metrics developer advocacy teams have at their disposal that we didn’t have before. When one of our advocates or myself presents on a topic, I know how many folks dropped off, how many folks were interested, and then it also lets us know what next batch of content should we make. I just have all this data I never had. So COVID has been miserable for many reasons, but one upside in our field is just how much we can improve our offering to the community because we just have a whole suite of data we never had before, when we were only flying around to events and stuff. So it’s been pretty wild.

Yeah, I feel more effective too, so I agree. We’ll see what the future holds. With that said, we just rolled over an hour and I almost didn’t notice, because I could just keep talking with you all day. So with that said, we should probably let folks go. I appreciate you joining me today, Chris, this has been great. Look forward to many more conversations. We’re planning season two, so I’ll be pinging you about what maybe we could talk about next season.

I love it, Kin. Thank you so much for having me, and I’m a huge fan of the show, much appreciated.

All right, well thank you, and enjoy the rest of your week, and we’ll be talking soon.

Thanks, you too.