Developer Experience Infrastructure (DXI)

Kenneth, welcome to Ship It.

Thank you so much for having me. It’s a pleasure.

So in August you wrote this blog post that caught my attention. The title was “Developer experience infrastructure.” And it wasn’t the infrastructure part that caught my attention. It resonated with me at a deeper level, since I think for the majority of the last decade my work was for other developers, or at least that’s what I think. What is developer experience infrastructure? What does it mean?

So a worked on that blog post, and it was really more an internal process for me to kind of put my reflections into a blog post. Because I’d been looking at our industry more broadly, and saying - we’ve been talking about developer platforms, developer experience, but I’ve really been trying to put a label on some of the observations I’ve seen in the industry. Developer experience infrastructure is what I describe as this new emerging infrastructure company, that really enables anyone, regardless whether you are a small company or a large company, to really provide industry-leading developer experience, and develop offerings to your customers. So in a sense, it’s really this new emerging layer, with all the table stakes things you need today to provide a great developer experience, and really all the packaging that you need to serve developers.

Okay. So is this just a very nice word for products, where developers are the end users?

You could say that, but … Taking a step back, we can look at like - I’m building an SDK, and I’m building a CLI; that’s for developers. Is that developer experience infrastructure? I would say it’s not, but it’s part of the recipe. Really, this is a similar perspective you can apply on cloud infrastructure, in the sense that we went from being 00 in our own data centers, we all had to buy the hardware and operate things, and now we’ve moved to a cloud-native world.

What I see around developer experience in our industry is that I’m kind of seeing the same, is that it has become so complicated - I wanna say complicated, but the market demands for you providing a great developer experience has become really… the bar has been set so high that you as a small company, or even a medium-sized company, cannot build those pieces anymore. So this is really a part of like the materialization of the market, that instead of you building everything in-house, now we reached that maturity point in the market where there’s actually a lot of table stakes solutions you can go buy off the shelf, and you can use to provide a part of your developer experience to your customers.

So in the sense that if I’m building – let’s say I have a weather company, and I want to have an API that provides weather data. Should you go out and build your own infrastructure, documentation, SDKs, all the aspects? In 2022, or 2023, as we look into the future, would you go out and buy some of those solutions from companies that’ve been specializing in that?

Are there companies that focus solely on developer experience infrastructure? Can you think of a few examples, just to make it clear?

[06:00] Yeah, there’s actually quite a few. As a part of my blog post, I kind of was working on putting together what I call the developer experience infrastructure market map, by trying to break out the market into different players. And I see a lot of broad categories. A category around documentation, and SDKs, and now you have – I think [unintelligible 00:06:20.15] readme.com. If you go to a lot of documentation pages for smaller companies, you basically see them using Readme. And there’s APIMatic, Stoplight, Redocly. There’s a lot of players out there that are providing various aspects. Even when you look at the API infrastructure, I would say that there’s players Speakeasy API, Kong is probably a more established player, Optic… There’s quite a few of these companies that are providing elements of what I described as developer experience infrastructure.

But to answer your question, there’s no “company” that is providing the full end-to-end solution. There’s no kind of like AWS of developer experience. It’s more these sub-components that you stitch together yourself to kind of build your developer experience.

Because that’s exactly what I was thinking… These are typically the things that you would maybe go to AWS for, and AWS with all its services, you get all the infrastructure that you need to build great developer experience without having to reinvent every single component.

The cloud-native landscape is a little bit that, but maybe that’s too technical, because I know that you have something else in mind… So would you say that AWS is developer experience infrastructure, where you go and you pick, mix and match services, and you build a great developer experience?

I’d probably look at it through a different lens. You can go to one of the big cloud providers, like AWS, Azure, GCP, and they kind of provide your cloud infrastructure layer, your compute, your storage, your auth… Those pieces. But the reality is that you can use those services – let’s say I spin up a new API, use an API gateway, some lambdas, and then I have my API. But developer experience infrastructure is really going from the 80% that AWS gave you, to the 100%. It’s the documentation, it’s the SDKs, it’s the community building, it’s the API reference, it’s the developer portal, it’s all those pieces that current cloud providers are not providing today. And my hypothesis and my argument I’m making in my DXI blog post is that I believe this is a new, emergent infrastructure category, where we have roughly a billion dollars invested in emerging startups that are starting to kind of fill the gaps that in the past has been developed in-house; I think all of us, in particular you, you have been in the industry for so long… We all have been in-house, just rolling in-house solutions, but now we’re seeing each individual components starting to be complicated, advanced etc, that you cannot build them in-house anymore, and now some of these startups, or even medium-sized companies are starting to lift some of that responsibility.

Yeah. I think I was thinking more around the tooling, the internal tooling that maybe developers were using, for example, a PaaS. So I was working for a couple of years on a PaaS called Cloud Foundry, which developers would use to build, you know – basically, to run their applications. And with building, it would be doing a couple of things.

The other one was Rabbit MQ, but that was very specific to queues and queuing, and I think that was more like a developer tool, in a way; a building block, if you wish.

Dagger, my current role - I think that’s more in-line, because that’s how I even reached out to you, because we talk a lot about DX… What is the DX that you want a tool to have, so that others can build pipelines really easily? It’s more like a primitive that works across any system that you have. I think that that’s where my interest was piqued, when I heard you talk about the DXI, because Solomon talks a lot about DX. So what is the difference between DX, developer experience, and developer experience infrastructure?

[10:08] Got it. Before answering that question, I just want to continue the riff here, because I think I have an important point. When we think about developer experience, we can think about it, I would say, in two broad categories. We have internal developer experience, which I probably would categorize the same as what in the past we’ve been calling developer productivity. And then we kind of have external developer experience in the sense that “What are the experiences, like API-first or developer-first companies are providing, and how they’re offering those products to their users.”

And I think when we say “developer experience” and “developer experience infrastructure”, I think there’s two sides to the equation. If you are a company that is developer-first, you care about your internal developer experience and how you’re building your own products, but you also care about the external element. But for many companies, developer experience is just an internal developer experience, because they’re not having a developer angle, or maybe something else.

So I think - what is the difference? Let’s start with some definitions. The way I’ve been framing developer experience - because that’s also part of a… If you think about our industry, everything is suddenly developer experience, right? Developer advocacy is now developer experience; developer productivity is now developer experience. And the way I’ve kind of been coining it for myself is that to me, developer experience is that holistic experience that is offered to developers throughout that lifecycle it means to interact with your product. Developer experience is not just the SDK or the API, but it’s much broader than that; it’s kind of the journey that we take developers through. And what we’re trying to do as companies in our industry is we’re trying to make that experience as good as possible, as smooth as possible. So really, that’s what DX is to me.

Okay. So that’s DX. And what about DXI? We have the two acronyms - the DX, and the DXI. So we have the DX explanation… What about the DXI?

Right. So if we think about it, DX is kind of that holistic experience. To me, DXI - that’s the infrastructure piece, that’s the products and services that kind of fits into that holistic experience. So they’re the infrastructure layer that enables the holistic developer experience, whether it is that I am providing an internal developer experience, and I’m using services, libraries, abstractions to help with that experience… I’m focused on I’m running an API-first company, and I need to provide the services to enable that external developer experience. So this is all infrastructure pieces that you were using and stitching together to provide that holistic developer experience.

Got it. Got it. Got it. Okay. So why is it important? Why is the developer experience and the developer experience infrastructure - why are they important?

For a lot of different reasons. You can apply a lot of different aspects to “Hey, why does it matter, the experience we’re providing to developers?”, in the same realm as “Why is it important for you to have a well-designed product for your end users?”

You could argue that if you were building a product targeting developers, or you have a developer-faced offering parallel to your consumer, your B2B offerings - it’s like, your DX, that’s kind of like your UX is your bread and butter in terms of that journey that you’re providing to developers. So it’s really, really important for you that you have as optimized an experience to make your developers happy. If you have an API and it doesn’t have a great developer experience, you’re probably not going to see a lot of adoption, you’re not gonna see a lot of satisfaction; you’re gonna see a heck of a lot of developers probably being forced to make this integration with your system, but it’s not going to be a great experience.

[13:56] I also think you can apply another angle in this, and that’s really more like a financial/economic perspective. And this is really like - developer productivity is really, really expensive. In my original blog post I kind of referenced a report that Stripe did back in 2018. When we’re looking at developer productivity, the average workweek for developers is around, say, 40 hours. But developers actually spend a significant portion of their time dealing with bad code, technical debt… And with the investments we’re making into our engineering teams, that’s really, really expensive. And what we strive to really quantify is that over a 10-year period, we see that as a trillion-dollar opportunity in GDP growth to optimize the developer experience and make it easier and better for developers, because we can make building solutions more productive.

Yeah. So I’m looking at this pie chart right now… It says “Average developer workweek - 41.1 total hours.” We could round it down to 40. That’s a good one. Out of that, 13.5, so more than a third, is technical debt. Interesting. About a third is technical debt. There is the developer coefficient - this was September 2018 - 3.8 hours is bad code. So I wouldn’t say half, but almost half of the average developer workweek is spent on technical debt and bad code. How has this changed over time? So since 2018, has there been another study?

So I don’t have additional data points from Stripe’s perspectives as of what we have collected. But I think we as an industry, just anecdotally, I think about our industry, I think we have seen a massive investment into developer experience and developer productivity in broad terms. And I think, as we kind of have gone through the on-prem kind of era, to now cloud-native world, I do think we have seen a significant investment and a lot of paradigm shifts into how we’re building software.

So my hypothesis here would be that I definitely think we’ve gotten into a better spot, but just based on how I see engineering teams operate, etc. I still think we have a very long way to go. And if we think about our industry in broad terms, we are somewhat still a new industry that is learning how to build software, and I think a lot of the processes and how we are working are still somewhat new. And we as an industry are collectively learning every single day how we actually build this thing called software.

So I also think there’s an element to just the maturity cycle in terms of what we do as an industry, and then how we can actually, as an industry, move the needle, make ourselves more productive through the abstractions, developer tools, and such we provide.

Yeah, okay. Okay. I can definitely see that. So for someone that’s wondering, “What are the components of DX?” What goes into developer experience? So not just the code. It’s not just the documentation; there’s a lot more. What are the components, in your mind, for DX?

I kind of see it as a lifecycle and a journey, so to say. If you think about – I’m looking for a payments API. Hey, I’m biased, because I work for a company called Stripe, right? There’s definitely the element of content, blog posts, how do I discover content? And there’s the documentation aspect - hey, how do I get educated about the product that I want to use? And then there’s the whole product aspect, the APIs, SDKs, the tools, the abstractions, the error messages, all those pieces. And then there’s also the community element, in terms of “How do I interact with the product teams? How do I get a sense of the community I’m a part of? How do I engage with the teams? …all those other pieces.

So I think in broad terms, I can kind of look at this as a lifecycle, and that’s really also, to my previous point about this is a holistic experience - when you interact with a developer-facing product… If you have an amazing developer community, but your product experience is not great, it’s not a great holistic developer experience. It really has to all come together for you to having that industry-leading developer experience.

[18:11] I have to say I’ve definitely seen it with Stripe. It’s one of the products and one of the components that we get to use, many of us get to use, that works really well from so many perspectives. The code itself, the error messages, the documentation, even the community - there’s a lot of… Not to mention examples, content. There’s so much content, so much Stripe content, whether you want to integrate with it, whether you need help with it… There’s just so much out there. And I can see this as an example of good DX, and I want to believe that you had something to do with it…

I would definitely say that I have a tiny part in terms of the developer experience we provide at Stripe. So just to do more like a formal introduction… These days I’m a product manager at Stripe. So I joined Stripe to look after pieces of our developer experience; I was really focused on our product developer experience, on the developer tools, the CLIs, the SDKs, our dashboard, all of that. These days, I’m leading a team building Stripe apps. That is really the application layer we launched earlier this year on top of Stripe to really enable developers to kind of truly build new experiences and integrations on top of us.

I think a good parallel would be that – think of your iPhone. Before we launched Stripe apps, all the experiences you had in Stripe, they were pre-installed and built by Stripe. Now we’ve kind of enabled an app ecosystem on top of us to kind of build this new set of experiences.

But even before my time at Stripe, I also happened to spend a few years at Microsoft building developer tools. I worked on Visual Studio Code and a few other JavaScript tools. And then way back when, when I did engineering, I spent roughly a decade in and out of startups in Europe, mainly doing frontend engineering. So that’s kind of the short pitch of myself. But at Stripe, we have multiple teams thinking about our developer experience. So that is covering our docs teams, our docs product teams. So think about docs as a product. We have our developer experience teams, our API teams etc. So it’s definitely a larger team of us that are really thinking about that holistic developer experience.

As a part of my blog post, some of the observations I’ve been putting down and sharing as to like what I’m considering industry-leading developer experience - it’s definitely biased from my time at Stripe and some of the observations I’ve seen in terms of what does it actually take to provide the developer experience Stripe is providing today.

I see. So you’ve been at Stripe for a few years now, right? I’m looking at your blog post; that was joining Stripe 2019, I believe…?

Yeah, time flies. This is almost the end of 2022 now, yeah.

Yeah. 2020 - I don’t know what happened. 2021 again, it was like a weird one. 2022 is only when everything came rushing, right? Because there were two years on pause. So what was it for you to be part of Stripe for the last three years? What was it like to work there?

Stripe is a pretty amazing place, in the sense that when I joined back in 2019 - time flies - we were a much smaller company in terms of where we are now. But I would say I’ve never seen a set of founders and a set of people that are so passionate about long-term thinking, and thinking infrastructure. And I’m really, really grateful to be a part of these teams that are really thinking with rigorous attention to detail I’ve never seen anywhere before.

[21:59] I came from Microsoft, and I think we did a pretty good job in terms of building developer tools etc. Just the level of thinking and the caliber of people that have been working on a lot of different things - it’s definitely been a big eye-opener to me.

And then during the peak of the pandemic, I remember when the pandemic started and we all had to go remote. We were experiencing massive adoption, because suddenly the whole world went online, right?

Yeah.

So it’s been a really, really interesting journey, in particular working on payments, which I’d never worked on in the past, because my bread and butter is developers. So it’s been a really interesting journey to also kind of go up – I would say up a different abstraction ladder. In the past, I worked on foundational developer tools like VS Code, and TypeScript, working on cloud infrastructure… And then going kind of up that abstraction ladder and working on payments infrastructure, that is kind of a vertical on top of the more foundational [unintelligible 00:22:58.07]

So it’s been a really, really fun, fun learning journey. And I do think – when I think about Stripe as a platform, kind of the irony is when I joined in ‘19, it’s like, it’s still early… And I do think Stripe has a lot of interesting things that we can do with the platform going forward.

Okay, okay.

So from a DX and DXI perspective, since that is the context of this discussion, can you give us some specifics at Stripe from the last three years that helped shape some of your thinking?

Yeah, I think a very tangible example is that when you run an API-first company, you tend to think a lot about my documentation, or my API reference, and thinking that - hey, that’s where most of your developers are going to figure out how to consume your API. But the key insight is that developers actually don’t care that much about your API, but they care a lot more about your SDKs, and the native kind of experience you are providing in the programming languages that you are using… Which - I think it’s a fallacy to kind of think, “Oh, I’ll just have a great API ref, and then these SDKs, people can just do some curl commands.” That actually means that you don’t care about that kind of product experience you’re providing to developers. And finally, the SDKs you’re providing when you’re having an infrastructure company - that’s probably the most changeable thing developers will get from you as a company. Because the API is just transport. So what is the shape and the design of those SDKs, and also how much thinking there goes into how do you actually ensure that you have a consistent experience across all the different languages, and where do you intentionally want to carve out an area and saying, “What do we need to do different for Java versus Go?”

[25:49] So really thinking about those pieces as an intentional product, with a strategy, and where you want to invest - I think that has been a key insight. But also - and this kind of ties me back to my old days of Microsoft, but it’s very easy when we talk about developer experience, and we talk about the bleeding edge, that we always think about the newest hip thing, but really what truly matters is the long tail. It’s what I think some people are calling the gray matter developers; the PHP people of the world that are not using any fancy development stack, but they still represent – I’m now making up a number, somebody please correct me out there… They’re 42% of the internet. They’re still a large proportion of how the internet is put together.

So how do you strike that balance between you making sure that you are relevant in the Denos of the world, and being hip, but also that you actually enable the bread and butter of your business, and help people that just want to build a product and move them forward too with the tools you provide?

So for you to think about the bread and butter developers, it requires - it at least required me personally - to work at a certain scale, like Stripe or Microsoft, for you to kind of see the dynamics play. If you’re just a small startup and you’re just trying to get to market with your product, your usual audience is not that kind of segment, but you see that as you scale.

That’s interesting. Now, I know that the infrastructure has many different meanings. And when I think of infrastructure, the default [unintelligible 00:27:25.19] that I go to is the hardware, right? All the hardware that runs things. But I think that when you think of infrastructure, you have a completely different image in mind.

That’s interesting, in terms of like - I probably think about infrastructure in a different way, but I want to play it back to you to really understand like what do you mean by infrastructure, and how do you make the connection between infrastructure and hardware?

Yeah. So infrastructure is all the things that you rely on to run your code. So you wrote some code - what are the components that need to be in place for that code to provide value to end users? In this case, to me, that would be servers, or let’s say we have serverless, it doesn’t matter; there’s some APIs that I integrate with to get my code out there. It would be all the pipelines, it would be everything that ensures that my code, which is locally, makes it in front of end users. All of that I think of as infrastructure. To narrow it down, it could be a PaaS, it could be maybe some Kubernetes there, but it’s not the only thing, because there’s layers and layers of things that help run the code, right? I don’t think about network switches most of the time, or routers, but I know they’re there… I don’t think about Ethernet cables, and all those things, or fiber optics, hopefully, but I know they’re there. DNS, right? It’s always DNS. There’s so many layers and layers of infrastructure that deliver whatever I’m building to end users. It makes basically the connection.

But I’m mostly thinking from hardware perspective, systems perspective - I know that many people, when they hear infrastructure, they think about something reliable, something that they can build on top of. And it doesn’t have to be of a certain type. It just means something I can trust to get the job done. And the job varies, and the thing that they trust varies based on the job… So how do you think of infrastructure?

I actually think of infrastructure in the same ways, in terms of it being like pieces of components that you can leverage to kind of build the experience that you want to provide. But I probably don’t have a tight connection between infrastructure and hardware, in the sense that I see that as an abstraction ladder. Like, let’s say that I want to build a PaaS today. You will probably rely on another computing abstraction that you’re using, that is so far away from hardware anyway, that you have a virtual machine of some sort, and you have another runtime. So even as you kind of compose kind of like a new kind of computing abstractions as infrastructure, hardware for you anyway is abstracted away.

[30:12] So when I think about infrastructure in a DX or in a software context, is that we think about how I’m composing a modern, let’s say software as a service business, I probably need some sort of compute layer; I probably need like a Vercel, or a Netlify, or AWS Lambda, how I’m putting my stack together. But at the same time, I probably need an authentication piece. That is not a hardware piece, but it’s a set of services I’m using to provide auth, right? Or maybe even I’m using a combined provider that does all that for me, like Firebase.

So what I mean by that is that to me, infrastructure is the business components that you’re leveraging to kind of put your product together. And the argument I’m making for DXI as a category is that we have reached this maturity point where if you have to provide all the aspects of a great modern developer experience covering your product, docs, content, community, you cannot build it in-house anymore. You have to rely on these new infrastructure pieces that are emerging from this new market landscape of companies that are saying, “I want to be the best in providing SDKs. I want to be the best in providing documentation infrastructure. I want to be the best in doing community management.” And then I as the founder, I as the C-level at a company, instead of sitting with my budget and saying “Should I allocate 100 engineers to build internal developer experience?” No, I would rather use a different part of my budget, and use a vendor for these kinds of things.” So it’s through that lens that I’m seeing infrastructure.

That’s a good one, that’s a good one. Yeah, that ties a lot of things together. So going back to Stripe and the work that you do, what does infrastructure mean in the context of Stripe for you?

So in a sense, tying it to what we provide at Stripe is we provide payments infrastructure. So overall, as a company, we are providing the platform primitives and the experiences around payments for you to operate a modern business, whether that is you’re coming to Stripe to do just payments, because I need to accept credit cards, or some payment method in the world, or I’m doing banking, or I’m doing capital [unintelligible 00:32:22.11] I want to do a lending product, or I want to run a marketplace, a two-sided marketplace, and Stripe has various product offerings that we are providing as platform primitives that you can kind of plug into your product. So you don’t have to worry about all the financial complexity, we kind of abstract that away.

In particular, in terms of what I do, these days I’m really hyper-focused on thinking in platform primitives and extensibility, in terms of like, through the products we offer at Stripe, what are the pieces and the primitives we can provide so you can build the next kind of generation product on top of our platform, and really about opening up our platforms so all the primitives we have available internally, how can I make them available to you externally, so you can consume them and stitch kind of new product experiences together? …whether that is I install an app that is synchronizing data between some accounting system and Stripe, or I want to build a whole new kind of experience that runs natively on Stripe. So those are the things that I’m really obsessed with.

I do think that we need to think more broadly about what some of the teams here at Stripe are providing, and that’s our developer experience, it’s our SDKs, it’s our API abstractions, it’s the design patterns that our product is built upon. It is the supporting tools like the Stripe CLI, or it’s the integration of Stripe in editors like Visual Studio Code. So we have a bunch of different teams that cares about different parts of the developer experience, that when combined, is known as the Stripe developer experience and what we offer to developers as our product.

[34:07] So I would say that today, that’s just one element of Stripe, because the reality is that for a large platform like ours, developers are just one segment today. We also have many users that are just using Stripe to run their business. I’m a founder of a company somewhere in the world; what do I do? I open the Stripe app on my phone and I can get an overview of the payments. I go to dashboard.stripe.com to run my business.

So I think it really also depends, and through that lens of who your audiences etc. We at Stripe are definitely a developer-first a company, that cares deeply about developers, but at the same time, we also care about more kinds of people than just developers.

Yeah. Okay. I really this holistic approach. It’s not just a certain type of persona, and it’s definitely not just a certain perspective on a word, whether it’s infrastructure, whether it’s experience… We do say “developer experience”, but we are thinking about the experience in the broader sense, and that is, I think, important to underline.

You reference another very good blog post by Shawn “swyx” Wang, “The radiating circles of DX architecture.” And he – there’s a few sentences which caught my attention, but this was the first one. “Most companies will ship the developer experience of their org charts.” That’s a very interesting one. It’s like Conway’s law applied to developer experience. What do you think about that?

I think that’s probably true. And thinking broadly about our developer experience, there’s probably a lot of companies that are not truly developer-first, in the sense that they run a traditional product, and then they kind of bolt on this platform on the side, and they have a little team put together developers.company.com, and then they have a developer platform.

So I definitely think in the sense that for a lot of companies, you running a developed part of your product - that’s kind of an afterthought. And I do think that’s part of a broader symptom in terms of… As we know, the most successful products or platforms are also the ones that are used internally, and you really have a strong feedback loop. So I do think in the sense that - why it’s so rare to see truly exceptional developer-first companies is because it’s kind of an afterthought. It’s kind of like an easy way to kind of open up for some integrations etc.

So shipping the org chart - yeah, I definitely think that’s true. Also, there’s an element of this in terms of like, if you don’t have product teams that really understand developers, and really focuses on developers as they’re the main segment they care about, then you end up with an engineering team that’s like “No, no, I want an API for this”, and then they ship it. And then the rest of the product team is hyper-focused on the typical customer segment they care about. So you end up seeing various factions of the company in the org chart shipping components, and you don’t have that holistic perspective, and “What does it actually take for us to be successful to go after this developer, and this size company, in this market?”, that kind of thing.

Yeah, it’s nobody’s job. That’s the problem. Developer experience is nobody’s job. And then, you know, whether you’re an engineer, whether you’re a product manager, whether you’re the salesperson, whatever your role is, it’s niche. It’s just a small part of what really matters.

So coming back to the things that matter, Shawn has this really interesting representation, and it just helped me understand the relationship between product, docs, content and community. So there’s the outer shell, the community. How do you think of the community that you have, the Stripe community?

[38:00] I think about our developer community - we do a lot of different things, and I’m just paraphrasing in terms of what our wonderful developer advocates and our folks that are focused on that are doing; but if we think about the community we have today, we have advisory boards, where we have a community of developers, we are running things like support for Discord… Stripe has been known for quite a while and I think we had one of the longest-running IRC channels, where everyone would be on Freenode, people could join in and answer questions. We do meetups, we speak at conferences… We have a very active YouTube community, where we have product teams, some of my teams, where we do monthly broadcasts and we’re like “Hey, we’re working on this feature”, getting feedback, etc.

So what we’re really trying to do broadly is trying to have an interactive community where it’s a two-way feedback channel, like - I want to learn about some of the needs of my customers, and I want to build the right set of things. And we want to engage on multiple fronts. I think that’s probably an element where a lot of companies are thinking developer community and developer advocacy mainly as like a marketing channel… And to me it’s also a very basic customer development channel, is my community of people that are using my product; I want to solve their problems, I wanna enable the right set of things etc. So to me, community is kind of both ways - it’s a way that we can enable our product teams, our engineers to talk to customers, and the other way around.

Yeah. I also think that’s super-important. That is your interface, if you wish, to the users. And it’s not the products. Most people think it’s the products. Sure, to some extent, of course, because they have to interact with it. Otherwise… You know, that’s where everything starts. But it’s people talking to other people. People that are maybe not Stripe employees. People that have a good experience, have a bad experience. All they come together, and what do they do? How do they help each other? Or not? What is the content that they find? By the way, that’s the second layer. There’s the community, there’s the content, and that’s what they interact with, right? Because each of these people, they create lots of content, whether it’s questions, whether it’s answers, whether it’s YouTube videos… Whatever it is, they create a lot of content. Applications maybe even… Because, going back to Stripe apps - how to use them… So on and so forth. Blog posts like this one… And then there’s docs, right? And Docs is very close to the product. Now, would you say that not having docs is an option? There’s an API, it’s self-documenting, that’s okay, go with that… Do you think that’s enough?

No, not at all. And also the way I go about building docs for my product is that they’re part of the product. Every time you ship a new feature, you also write the docs. When you build great products, you actually start with the documentation. I’m personally a big believer in writing the docs first, doing it like Amazon-style [unintelligible 00:41:05.08] You write the press release, what you want to be true when this product is successful, and then you work backwards from that. And a lot of times – I can kind of draw on previous experience here, but when I was at Microsoft and we were building VS Code, the way we would be building VS Code is that we did monthly iterations. An iteration would end up being three weeks of product development, so engineering, design, etc. and one week of polishing. And in that week, we as a collective team would be writing the documentation, writing the blog posts, fixing all the issues, and then after that we collectively - when we were ready, we’d be putting the release notes together and then we’d press the button. And it would be me as a product manager, I would be writing the documentation together with everyone on the team, regardless of whether you are designer, engineer, engineering manager; we’d all be writing that documentation together. We would have a wonderful technical writer to make sure that the tone, and all these things… And he would basically just do a draft and polish of it, but it’d be written by the team. So the very engineer that worked on a particular feature would also write the documentation. And they would also do the animated GIF we would use on Twitter. If I were to provide, as a product manager, a perspective of why we’re doing this, I would draft a blog post that week, and then we would press the button.

[42:21] So to me, this is really about docs, and also you engaging with the community. That’s a part of you building a product. And that’s also why I think… The way I look at developer experience - and that’s also something I’m touching upon in my blog post, is that - right now I’m seeing this industry movement of developer relations teams being relabeled as developer experience teams. And I don’t think that’s the right way to think about developer experience, because developer experience is a holistic experience, that goes across docs, content, product, community. You have to think about what that holistic journey is, and how you’re empowering your team, your DX team to solve those pieces.

Typically, a developer relations team is mainly focused on content writing, community, speaking at conferences, etc. They are not incentivized and they don’t have, I would say, the right leverage to really change product, too. So that’s why dev rel and your product team is kind of ying and yang. You’re gonna have great content when you have a great product, and the other way around. So it’s really about thinking about all the pieces that comes together to provide that great developer experience.

Yeah. The way I understand it is that dev rel is a slice of all the layers. You can’t say, “I’m just community and content.” No, no. There’s the docs, and there’s the product. And if you don’t operate across all those layers, then you could be doing better, you could be improving.

Yeah, absolutely. I see it like you providing the best possible product experience you can is a team sport; it takes a lot of different disciplines. And usually, when you think about organizations, if you’re a larger company, you probably have a product team that is building the core product itself. You have a different team focused more on the outboundy kind of activities. But it’s a team sport; everyone has to come together to provide the best possible experience. And to me, this is a feedback loop. A typical product team is sitting in the virtual office, writing code, doing PoDs, doing designs… They are informed by talking to customers, informed by talking to the community, and your outbound dev rel function - that’s really your eyes and ears out there in the community, so you can get all the feedback to build the right things. And when you have a product, then your typical outbound-shaped dev rel team can then also go out and evangelize that push, it to the community, get the feedback etc. But it’s a collaborative nature.

I think, at least traditionally, how I’ve seen a lot of dev rel teams being organized, I think that’s changing now. People think it’s also the dev rel team building the product, but that’s usually not the case. And usually, dev rel teams don’t have the right influence and incentive to actually make the necessary product changes that can provide the feedback. So I also think that that’s kind of like a structural change that we’re seeing now… To your point about a modern dev rel team is a slice of everything, and they can also do more than just samples; they can actually go and get the API updated.

Okay. Coming back to DX, since that was our starting point… You have a nice list of table stakes for DX in 2022. Which are the items that you would to shout out? They’re all important, but if you were to focus on, let’s say, three of those, which would be the top three?

So I would start by playing a bit back, in terms of that it depends on what kind of product you’re building. I think if you’re building an API-first external offered product, like say “I’m building a weather API, I’m building a payments API.” I think you internalizing that, providing documentation is a part of the product you’re building; it cannot be an afterthought.

[46:07] You providing, having an element of what we call “surprisingly great”, in the sense that you have a rigorous attention to detail about how your product is put together… So that means when there’s an error message, it’s actually a helpful error message. It’s not a random internal error code. Really having that level of attention to detail, and you’ve been putting yourself in the shoe of the developer, because you’ve been dogfooding, integrating your own product - I’m considering that table stakes. And then we can kind of add a lot of layers on top of that.

I think the other thing is the SDK experience. Given that the majority of your developers that are consuming your API, they will not sit and do raw curl requests, or raw requests with a web library. No. They will expect to consume an SDK that provides a native experience in the framework, in the programming language they use, and it’s considered table stakes in 2022 that you have that broad support, but also that you are more than just the baseline.

Let’s say if I’m providing an SDK for Node.js - what if the majority of your developers are sitting in Next.js? What is that first-class experience you provide? Or Python and Django, that kind of thing, right? So that you really have that really tight integration to truly meet developers where they are. And I think that’s probably the meta narrative here, is that you need to meet developers where they are in the stack they use, in the framework, and the abstractions, and on the platform.

The reality is that the gray matter developer, or the 99% developer - they could probably be sitting on a Windows box and not sitting on a $3,000 MacBook. You probably also have a large proportion of your customer base that are sitting on Linux boxes etc. So you really have to truly meet developers where they are; you have to do a range of different things for a lot of different platforms and abstractions.

What did you find most surprising in your DX journey? Something that you weren’t expecting, and was like “Wow, I didn’t realize this was that important.”

This is a good question. When you say “My DX journey”, I’m kind of putting on this product hat, thinking about developer experience and building that out. To the point I now brought up a few times - it took me to work at a large scale to really internalize that the majority of developers are not sitting at the bleeding edge. And that’s probably my own personal bias, coming from a background of working in startups, being hyper-obsessed about what’s on Hacker News, always scouting through Hacker News and GitHub, looking at TechCrunch, and always chasing the new shiny thing. And then when you launch a product, and then you realize “Oh, God dammit, I forgot about PHP. I forgot about C# and Asp.net when we sold into this enterprise customer.”

So really looking beyond just what’s new and hip, and really truly understand who are your customers and what kind of tech stack are they on, as you’re kind of providing a platform, whether that is a platform that’s exposed via APIs, or it’s a platform that you’re providing, where you’re truly enabling people to build on top of you… That I’m super-focused right now with apps, and building a foundational extensibility platform… Or it is that I am providing a code editor like VS Code, that actually needs to run on a lot of different platforms. And I think - yeah, that has probably been the most surprising element, that in hindsight is like “Yeah, naturally… Why didn’t you think of that?” But you just don’t see that if you are focused on a very narrow, specific niche. You only see that truly as you go at scale.

[50:28] Okay. That’s an interesting one, for sure. It’s interesting that the infrastructure is supposed to be reliable, it’s supposed to be boring, because that’s what makes it reliable. It’s supposed to be a known element; you would not put the latest shiny, the latest exciting at the core of your business, would you? I mean, that would not be very wise. Brave maybe, but not very wise. I mean, maybe if you have… Like the blast radius, if you have that under control, and you understand risk mitigation, and you’re doing experiments - sure, to some extent.

But that’s interesting… How do you do experiments at Stripe? How do you introduce new and exciting things, while limiting the blast radius when things go wrong? Because they will, right? It’s an unproven new tech. I mean, do you even do that? I don’t know.

Yeah, I actually think our CTO, David, he gave a really good keynote, I think it was last year or the year before; you’re gonna probably dig it up, you can put it in the show notes … It’s on YouTube, about how we run product development, how we do experimentation. You’re about us being a payments infrastructure company; we’re kind of the definition of “Build boring things, and do it well.” And we as a company are much more conservative in terms of how we run experiments, how we roll out things, etc.

What I talk about is not necessarily the infrastructure we operate, but it’s the integration of our infrastructure tools to other platforms, in the sense that it’s very easy for you to build a “Hey, I want to build authentication as a service”, and then you only focus on the new kind of really interesting, loud segment on Hacker News, but the reality is most of your customer audience and your business opportunity is in a different world. Your job is to really help them move forward in the technology landscape, and that’s your opportunity; it is not to kind of help the bleeding edge… Because they will probably roll their own, right?

So it’s really on you to understand that opportunity in the market and what role you play. Maybe your job is with the tool that you provide, whether I’m building a new, local developer tool, I’m building a new infrastructure service that is truly your audience, and you have a unique opportunity. But for most infrastructure companies, even developer companies, your opportunity is the long tail and bringing that forward.

So I have two follow-up questions. First of all, how do you find out about that majority that you need to bring forward? And then how do you bring them forward?

That depends. I can look at this through the lens of a company like Stripe, that is providing payments infrastructure; what Stripe is doing is we’re kind of building a new abstraction layer to the financial system, and we’re helping traditional businesses that are not online, they’re not digital-native, to kind of go forward in this world. We do that by working with the businesses and really enabling them and saying, “Hey, are you doing retail payments? Maybe you can do that online”, etc. So that’s the element of business development, is what you can do here and what the tangible opportunity is, and how you can help them bring them into the digital world. And you can look at it through the lens of productivity, as in “Hey, you’re doing IT verifications the old-school, manual way. We have a product that can do that for you”, that kind of thing.

[53:53] When it comes to developers and what kind of tools and abstractions they use, I probably see it as an incremental step change, in the sense that you can start up by providing one surface area; you can help this PHP developer to offload some of their needs from their database needs. They can go from a self-hosted database to use something like Planet Scale. And then you kind of stitch together and slowly kind of move them forward, to where they might end up in a world and say, “Hey, maybe I shouldn’t be running with the PHP stack, but maybe I should run PHP in a serverless context, on Vercel, or something that.” So I probably see it as that eventual progression, so how you can add value. And I think it’s typically a fallacy to think about - what we do with our technology is that just because it’s new technology, that it’s valuable. No, that’s probably not the case. There are trade-offs constantly.

What challenges do you see ahead for DX and DXI? There must be many. I mean, things are improving, for sure… But there must be some big, big obstacles; things that maybe the majority needs to understand or accept before the new big step can be taken, or the next big step can be taken.

There’s an element – I think the first thing that comes to mind… And I’ll probably think about more things as I’m kind of talking out loud here… I think the main thing that is very top of mind for me is the balkanization of the internet, in the sense that the world we’re moving towards is that as we kind of like – you could argue that we are at the end of globalism, and we are now moving into a more balkanized world, where we’re moving towards a world where we have the European internet, we have the American internet, we have the Indian internet, we have the Chinese internet, that are probably gonna more operate as isolated islands, with their own set of infrastructure needs, with their own set of compliance and regulation about privacy, how data is moving, etc.

What does that mean when we think about providing internet services, when we think about providing developer-focused services? Because if we think about what has happened in the past decade or so, we’ve gone from “I’m running my own data center in Denmark, or Mumbai, and I have full control of it”, we kind of offload that responsibility to cloud infrastructure providers, and kind of abstracted that way. So we don’t think about the routers anymore, but we think in these high-level abstractions. But what does that mean, when I’m, let’s say, operating - I want to start a new shop tomorrow, and I’m doing a pure API play. What does that mean that I’m now using this infrastructure providers in between, and now I have to navigate the complexities of how data is moving, different regulation, etc? So I think there’s a lot of unanswered questions as kind of like the internet and our industry is going from being somewhat the Wild West to a more regulated world. I think that will have a profound impact on how we ship software, and what kind of infrastructure and developer experience abstractions we’re using.

I think the first question that popped up in my mind here is that in five years from now, would I sign up for an infrastructure provider that provides me service A, or would I rather have a deployment model where they’re not hosting it for me, but I’m buying the software, then I’m getting a Docker container, and then I’m running my own Kubernetes cluster, and I am responsible for running it in the five different zones of the internet?

So I think there’s really interesting challenges that we haven’t figured out yet, and what does it actually mean in terms of data privacy, and how do we figure these things out? So that’s probably the first thing that pops up as a really big, profound change. You just can’t spin up a service on Amazon. Well, maybe Amazon will figure it out for us, but you as a company need to understand this new kind of world you’re operating in.

[57:53] Yeah. I think from an infrastructure perspective how we used to design systems, or how we still design systems for resiliency - we have regions, we have zones - we try to avoid zones talking amongst themselves; sorry, regions, talking among themselves. Even zones, for egress costs, networking costs, bandwidth, costs, things that. I think there’s going to be some challenges around the data. And also, it’s not just for resiliency purposes, but also for regulation purposes. So in a way, that can make things more resilient, but it will be a challenge to roll all those things, to upgrade, around the upgrades, or keep things separate, but at the same time have that holistic view of how everything integrates… Because you don’t want that fragmentation, because it’s just not great. Imagine - and maybe even today that’s the case - Stripe in India must be very different to Stripe in the US, right? Because of various reasons. Some of it is regulation. Europe as well, which was not the case until maybe several years back. And I see this fragmentation - balkanization, as you put it - being both a challenge and an opportunity. The opportunity being how do you design the developer experience that can be fragmented, but at the same time is holistic? It feels it’s the same thing. It doesn’t feel it’s two different companies, or two different products. So that is definitely challenging. Okay.

Yeah. And I think you’re spot on in that regard; like you said, opportunity in the sense that we will kind of see new services emerge from cloud infrastructure that solves these needs. It’s kind of a moment in time where we are kind of pulling back, in a sense that we are actually reverting back to a more self-host model, or we are reverting to a model that instead of software we buys as infrastructure, what we buy is hosted by default. We have a kind of different deployment model where you bring the data plane of your offering behind your firewall, but you have a centralized control plane that that’s kind of like what you purchase.

I think there are some really interesting questions, and I think there’s this company called Replicated, that is enabling any kind of SaaS company to provide a self-hosted version by wrapping up your service in a Docker image, and then you can sell it. So you can kind of sell GitHub Enterprise, and then what a product in Enterprise Edition.

I think there’s some interesting things that we haven’t figured out… And also, you can kind of tie it back to the developer experience and internal developer productivity is that we spent the first decade moving our servers and our production environments to the cloud. What’s happening now with internal developer productivity is that we are now moving our local development boxes to a cloud-hosted development box. And now we’re kind of moving some of production services from the central cloud to the edge. So you can kind of see the dev box kind of tailing a bit behind, also because the local development environments become so complicated or complex, they have so many dependencies that it’s no longer feasible to run them locally anymore. So it’s just an interesting progression, and I’m wondering if this is a point in time where we have to stop and really rewire how we do in a lot of these things.

[01:01:16.06] If we don’t move the development environments from where they are, we keep them local, they’re already on the edge, so… [laughs] If you think about it, just don’t move them. By the time production moves to the edge, we are already on the edge, so it’s okay. Alright, tongue-in-cheek. Just a joke. To get to a more important matter, as we are preparing to wrap up, what would you say is the most important takeaway for the listeners that stuck with us all the way to the end?

Well, first of all, thank you for sticking along for so long. I’m glad you’re still here. If you’re listening, I think the most important takeaway when we think about developer experience and developer experience infrastructure is that for you to provide an industry-leading developer experience, covering all the different aspects in the full lifecycle, the reality is that you as a founder of a company today, you cannot build it in-house anymore. You have to go out and pick some of these products that exist, because otherwise you will be needing a significant internal investment that is spanning hundreds of engineers for you to be successful. And this will take time and focus away from you building your core product, that might be an API, or something else.

So I really think we’re seeing this point in time where the off-the-shelf offerings for all these different companies providing documentation, SDKs, and so on - they’re good enough that you can go and pick them off the shelf and you can use it. And my hypothesis is that I think this will kind of be the new default. If you’re starting a company two years from now, you will use one of these products that are providing aspects of your developer experience for you; you will not roll it yourself, because you cannot build it yourself anymore. And you shouldn’t. Much similar to how today we kind of take it for given that you will not go and build your own datacenter; you will not manage your own hardware. You sign up on Amazon, or whatever cloud provider you provide.

I think the default and the mindset, how we think about that kind of outer layer of the developer experience - that is changing. You should be focused on building the cake, but the icing and all the stuff on top that makes your service really easy, consumable, etc. you probably shouldn’t be building that anymore.

In other words, the value line has moved. Double-check where you thought it was, versus where it is right now, and act accordingly… Because who wants to waste time? Who wants to feel like they’re doing redundant work? Work that other teams have done much better. And if you think that you can do it better - well, unless it’s your business, don’t. Because it’s a waste of time, most likely.

Indeed, indeed. Well put. Well put.

Thank you, Kenneth. It’s been a pleasure having you on Ship It. I’m looking forward to next time. Thank you very much for the wonderful blog post. I’m looking forward to what you will do next.

Well, thank you so much for having me. This was fun, and I hope we can find another opportunity that I can be back.

For sure.