Best of 2024: Top Insights on Developer Tools, APIs, SDKs, and Creating Exceptional DevX

[00:00:00] Welcome to the Convergence Podcast. I'm your host, Ashok Sivanand.

[00:00:05] Ashok Sivanand Building developer tools and infrastructure is really like PLG. There's no other way in the beginning. You have to go out there and lead with the value and really integrate the product if they cannot do it themselves.

[00:00:19] On this show, we'll deconstruct the best practices, principles, and the underlying philosophies behind the most engaged product teams who ship the most successful products.

[00:00:36] This is what teams are made of.

[00:00:40] Hey, folks. Thanks for following along in 2024 and listening to the Convergence Podcast.

[00:00:47] We're closing 2024 out with some of the most relevant and valuable advice, insights, and stories from our guests.

[00:00:56] Today, we've got a compilation that's especially important for products and companies whose customers are software developers.

[00:01:03] We're going to talk about developer tools and building delightful developer experiences.

[00:01:10] At Integral, we got to work on a couple of really sophisticated connected vehicle platforms for major automotive OEMs.

[00:01:20] And I found myself extremely interested in the space of developer experience there.

[00:01:25] It sits at the intersection, I believe, of human-centered design and software infrastructure or platform architecture.

[00:01:34] Companies like Amazon Web Services and Amazon, Microsoft, and Stripe have all been extremely successful because of how valuable and usable they were to the developers who built applications on top of their platforms or their infrastructure.

[00:01:49] And I have a hunch that in the next wave of computing that's rooted in generative AI, we'll continue to lean heavily on enabling software developers through APIs, SDKs, for AI models and other pieces of the AI-enabled tech stack.

[00:02:08] Now, if your business or product or part of your product is consumed by software developers at your customers, whether they're APIs, SDKs, or other building blocks, it's really important that you empathize with those customer developers using techniques like human-centered design and that you apply intentionality in your experimentation and prioritizing your roadmap.

[00:02:31] So your customer developers are really excited about your existence and that you're going to be able to do that.

[00:02:36] So your customer developers are really delighted about your existence and that they keep coming back to use your APIs, SDKs, and other tools a lot more.

[00:02:40] Subscribe to the podcast to get future episodes as soon as they're published.

[00:02:44] If you find this helpful, give the podcast a five-star rating on your podcast app or hit that like button on YouTube.

[00:02:56] A lot of our guests in 2024 have been very intentional about crafting their delightful developer experiences for their customers.

[00:03:05] And we've compiled some of our favorite segments about developer tools and developer experience.

[00:03:12] Now, we'll have links in the show notes to all these segments if you're interested in hearing the full episode with any of these guests.

[00:03:23] First, we have Kenneth Alchenberg.

[00:03:25] Kenneth is an investor and advisor to numerous developer tooling startups.

[00:03:30] And his experience spans companies like Stripe and Microsoft with Visual Studio or VS Code.

[00:03:38] Kenneth shares why an amazing developer experience is important to your product success.

[00:03:44] If your customers are developers, whether you're in infrastructure or you're in platform,

[00:03:50] DevEx, DevRel, definitely high priorities, right?

[00:03:53] Yeah, like 100%, like developer experience is nothing like revolutionary.

[00:03:59] It's literally like it's the UX of what you provide to developers, right?

[00:04:04] Similar to like if you were like doing B2B software, B2B or B2C software,

[00:04:08] you want to make sure that you have a surprisingly great user experience and the crafted experience, great onboarding, etc.

[00:04:15] Developer experience is applying a lot of the same user experience principles to what it means to be building with what you're providing to developers.

[00:04:23] And that can be everything from like SDKs, high level abstractions to core APIs and to programmer languages and compilers is really about like you being intentional about the experience you're providing to developers.

[00:04:38] And developer experience is somewhat a niche discipline because there's not that many companies that are truly great at it.

[00:04:45] But it's also incredibly important when you work with an audience like developers, I would say the developer customer segment is probably one of the most discerning segments you can work with.

[00:04:58] It's that developers have a very, very high bar for, I would say like have a high, really like well calibrated bullshit filter.

[00:05:07] Is that for them, it's really about like, is this making me more productive? Is this enabling me to move faster? Am I going to save money?

[00:05:16] I don't have time to listen to like a big marketing spiel, etc. Like show me the value.

[00:05:21] And that's really like the core thing about developer experience is that it's like show don't tell and you really lead with the value and the product experience.

[00:05:35] Next, we have Summer Abbas, who's the co-founder and CEO of Temporal.

[00:05:40] Summer, like Kenneth, also worked on Visual Studio at Microsoft as well as on Azure.

[00:05:46] He also worked at AWS and at Uber.

[00:05:48] And he's here to share his opinions on a different mindset that we bring when we develop applications for developers compared to when we're developing for end users or consumers.

[00:05:58] And I'm curious if there's any things that really jumped out to you as to differences between building for developers versus building for end users.

[00:06:07] Yes, there are lots of differences there.

[00:06:10] Like so for instance, like for developers, you are going after a very technical persona.

[00:06:14] So you are building a application for a technical user as opposed to for like end user applications.

[00:06:23] You are generally going after a general audience with varying technical abilities.

[00:06:26] So that kind of translates into a bunch of different differences.

[00:06:32] For instance, developers cares a lot about flexibility and extensibility.

[00:06:37] So when you are building a developer platform, it's all about how you can provide capabilities into it for people to extend and which allows them to solve complex problems.

[00:06:49] As opposed to when you are building end user applications.

[00:06:52] Typically, it's intentionally kept simple from a UI, UX perspective.

[00:06:58] And to keep it simple, to keep it more intuitive because you are solving a very targeted problem essentially.

[00:07:08] Another key thing is the bar for documentation is very, very high when it comes to building platforms for developers.

[00:07:17] Like it's needs to be very extensively documented tutorials and code samples.

[00:07:26] So there is a lot of thought goes into how someone can get ramped up on learning that platform to be able to kind of utilize that for solving their own needs.

[00:07:37] As opposed to like end user applications.

[00:07:40] Typically, you are looking targeting very simpler user persona to keep it simple, provide user guides to get people get going and maybe troubleshooting.

[00:07:50] And that's it.

[00:07:52] Another key area for is testing is for especially around developer platforms.

[00:07:59] They needs a very different bar of quality around unit testing, skill testing, performance testing, integration testing.

[00:08:07] And then there is a lot of rigor that goes on because people will be using your platform as primitive, which they can play Lego with.

[00:08:17] So you need to test in each and every part of that as opposed to end user applications typically are more targeted towards usability testing, functional testing, and just making sure you can create a bug free experience for end users to be using that application.

[00:08:35] So Kenneth Auchenberg is back and he's here to differentiate between two commonly interused terms, DevEx and DevRel or developer experience and developer relations.

[00:08:55] Kenneth now talks about how he ideally measures what the ROI on investing in a developer experience is and how you keep track of progress.

[00:09:04] Kenneth Auchenberg Let's maybe also stay at the fundamentals a little bit and then we'll go from there.

[00:09:10] Talking about developer experience or DevEx.

[00:09:13] Tell us what's the difference between DevEx and DevRel for you?

[00:09:18] Kenneth Auchenberg I think to me, developer experience is all about the product experience you're providing for developers.

[00:09:24] And I see a lot of conflation between like doing developer relations and developer marketing and community building and conflating that with developer experience.

[00:09:33] Kenneth Auchenberg Let's say, I think those things go hand in hand.

[00:09:37] Kenneth Auchenberg Let's say, I think doing 2021 SERP, we definitely saw a trend that all developer relations teams around the world is suddenly got renamed to be the developer experience teams.

[00:09:48] But but to me, a great developer experience really starts with the product experience.

[00:09:57] Kenneth Auchenberg Let's say, you have the product value and what you're building.

[00:10:01] Kenneth Auchenberg Let's say, you can talk about that value in your community, et cetera.

[00:10:06] Kenneth Auchenberg Let's say, you could do events around it, et cetera.

[00:10:09] Kenneth Auchenberg Let's say, that's really like a way to say that in any kind of modern developer experience organization team that is focused on developer experience, you have more experience.

[00:10:22] Kenneth Auchenberg Let's say, you have outbound focus roles that are focused on the community marketing, et cetera.

[00:10:25] Kenneth Auchenberg Let's say, and you also have internally faced roles focused on actually building the product experience.

[00:10:31] Kenneth Auchenberg Let's say, a modern kind of like developer experience team is a combination of both.

[00:10:41] Kenneth Auchenberg Next, we have Brian Vallelunga, the CEO and founder of Doppler.

[00:10:46] Kenneth Auchenberg Doppler makes developer secrets a lot easier for your software team.

[00:10:51] Kenneth Auchenberg Brian, who was at Uber before founding Doppler, talks about three approaches to the software.

[00:10:59] Kenneth Auchenberg These include techniques like interviewing their power users, researching amongst developers who haven't used their product yet, and setting up landing pages with hyper relevant keywords to gauge interest.

[00:11:14] Kenneth Auchenberg My framework I am using is really like, I think you can boil down product metrics into three different buckets.

[00:11:21] Kenneth Auchenberg You can look at adoption satisfaction revenue.

[00:11:24] Kenneth Auchenberg And I think everything else is kind of a proxy of that.

[00:11:27] Kenneth Auchenberg I think it's very common in product management that you invent a lot of proxy metrics.

[00:11:32] Kenneth Auchenberg You invent a lot of like, how do we measure successful for this feature we're releasing.

[00:11:37] Kenneth Auchenberg But ultimately, everything you do to me really comes down to am I moving the needle on adoption?

[00:11:42] Kenneth Auchenberg Am I moving the needle on satisfaction?

[00:11:45] Kenneth Auchenberg I'm doing this to kind of increase my revenue.

[00:11:47] Kenneth Auchenberg So let's talk about those three.

[00:11:49] Kenneth Auchenberg So adoption, I noticed the thing that I found someone sent me was because I was talking about the meantime to Hello World, that we were helping one of our automotive clients with building and someone saw that in a tweet or a blog and that's how I came across you actually.

[00:12:06] Kenneth Auchenberg So that's probably one on the adoption side.

[00:12:08] Kenneth Auchenberg So tell me maybe some more examples.

[00:12:10] Kenneth Auchenberg Obviously not a one size fits all.

[00:12:13] Kenneth Auchenberg Bolling it down in terms of like, I think that's an element of like, adoption is really like your time to integrate how many developers do we have, but also how long does it take on average for developer to integrate with your platform.

[00:12:25] Kenneth Auchenberg And here there's an element of like, developer experience in the context of a company like Stripe is really about integration experience.

[00:12:36] Kenneth Auchenberg In the sense that you make an integration with a company like Stripe, you integrate with the API.

[00:12:43] Kenneth Auchenberg And then you move money.

[00:12:44] Kenneth Auchenberg And then we kind of let the developers experience kind of fades away because you're busy running your business.

[00:12:49] Kenneth Auchenberg That's the same if I'm building integrating with an email provider, etc.

[00:12:53] Kenneth Auchenberg Once it works, I am kind of moving on with my life.

[00:12:56] Kenneth Auchenberg So integration experience in this kind of perspective is really about like, how can you manage to how can you provide an experience that enables developers to have the fastest possible

[00:13:05] Kenneth Auchenberg To integrate in the most satisfied way while we are managing the expectations where we can exceed the expectations.

[00:13:14] Kenneth Auchenberg And to me that that's really what it comes down to.

[00:13:16] Kenneth Auchenberg So we spend a lot of time measuring integration experience and into measure.

[00:13:20] Kenneth Auchenberg So here like looking at just time to integration is not really the right metric here is really about like, are we also managing the expectations that when a user starts signing up using this product and that we actually manage the expectation of this product and it's probably going to take a

[00:13:36] Kenneth Auchenberg To integrate with all these other things and the coding bit is just going to be like these two hours here.

[00:13:42] Kenneth Auchenberg Are we setting the right expectations with the user and having the overall experience being exceeding the expectations.

[00:13:49] Kenneth Auchenberg And then there's the satisfaction piece of once I'm actually integrating and I'm banging my head towards the goddamn API and it doesn't work.

[00:13:57] Kenneth Auchenberg Are we holding the developer in the hand to give them the right guidance, the right level of abstraction, the right level of integration into whatever tech stack they use.

[00:14:05] Kenneth Auchenberg Are we using them up using a framework.

[00:14:07] Kenneth Auchenberg They might be using another system.

[00:14:09] Kenneth Auchenberg Are we providing really fit into that or do they have to work around them.

[00:14:15] Kenneth Auchenberg And that's really where you can measure like traditional things like CSAT and NPS about like satisfaction.

[00:14:20] Kenneth Auchenberg But I think to me measuring developer experience is a combination of those three aspects.

[00:14:28] Kenneth Auchenberg And naturally there's a lot of other other things when you think about the full in trend journey for for developer and going through like,

[00:14:35] Kenneth Auchenberg The communities, docs, like the code itself, the API, like what it means to have great developer support, etc.

[00:14:44] Kenneth Auchenberg But when I think about like the core platform user experience, it's those three aspects.

[00:14:54] Kenneth Auchenberg Kenneth is back.

[00:14:55] Kenneth Auchenberg And he's here to share techniques that Stripe uses to conduct customer research to prioritize what features find their way into their roadmap at Stripe.

[00:15:05] Kenneth Auchenberg Tell us about how you gain confidence that your developer tools are super delightful and are integrating well into the workflows of what would delight your developer customers.

[00:15:16] Kenneth Auchenberg Well, I think the first part is where we take a very customer centric approach.

[00:15:20] Kenneth Auchenberg We are extremely detail oriented like our fundamental process and Doppler is not to ship that many things a year, but the things that we ship have extremely high impact.

[00:15:28] Kenneth Auchenberg And so we do an immense amount of customer research across the board from individual developers, all the way up to the very large enterprises that we work with on a day to day basis.

[00:15:36] Kenneth Auchenberg And from that, you can just see it in the metrics.

[00:15:39] Kenneth Auchenberg We can see that there's high usage across the board and a lot of different areas that we care about.

[00:15:49] Kenneth Auchenberg And so it's a combination for us of really listening very intently to feedback and acting on it, paired with looking at that data that we're seeing from our analytics tool.

[00:16:04] Kenneth Auchenberg And this is, you mentioned that you do a lot of research, so I want to double click over there a little bit.

[00:16:10] Kenneth Auchenberg Auchenberg Auchenberg Auchenberg Auchenberg Auchenberg Auchenberg Auchenberg Auchenberg Auchenberg Auchenberg Auchenberg.

[00:16:11] Kenneth Auchenberg Auchenberg And so we can see that a question that our folks at INEGRA would get asked a lot or a friction point for executives that we had to convince, especially at larger companies to do this research was,

[00:16:20] Kenneth Auchenberg While getting the folks to research is going to be really hard, and it's going to slow us down, and I don't know how to do it.

[00:16:27] Kenneth Auchenberg And we would oftentimes go in there and help work through making sure that the right folks are the ones who are researching and take a lot of the pain off their hands.

[00:16:34] Kenneth Auchenberg Both in terms of getting the work done, but also helping strategize and not be inefficient

[00:16:40] in terms of how that work is deployed.

[00:16:42] How's it done at Doppler?

[00:16:44] And how do you maintain a discipline around it?

[00:16:46] Because it's still a minority of the industry

[00:16:49] that's putting in that level of customer research,

[00:16:51] especially on the DevTool side.

[00:16:53] The Seltzer side, we've identified a set of customers

[00:16:56] that are really active Doppler advocates.

[00:16:59] And we just have a database of them

[00:17:01] and we reach out to them and we're like,

[00:17:02] hey, we're going to be releasing this thing

[00:17:04] in a couple months.

[00:17:05] Or we're thinking about solving this problem.

[00:17:08] Does this resonate as a problem to you?

[00:17:10] Does it feel deep in a priority problem?

[00:17:11] Or is this more like not a problem that you don't care about

[00:17:13] and if it got solved or didn't,

[00:17:14] it will move the needle for you.

[00:17:15] And we have those sets of conversations.

[00:17:17] And the enterprise side, we have the exact same thing.

[00:17:20] We have a database of like really strong champions

[00:17:22] that are actively engaged and invested

[00:17:24] in their success through Doppler.

[00:17:27] And so they are very willing to shout out to us.

[00:17:29] And so anytime that we're thinking about spinning up

[00:17:32] a new feature or part of the product,

[00:17:36] we first ask ourselves,

[00:17:37] what is the deep problem that we're solving

[00:17:39] and how can we deliver outsized value against it?

[00:17:43] And so we will reach out to that strong advocacy base.

[00:17:46] The other big area that we look at is

[00:17:48] we have a lot of customers because they're advocates.

[00:17:51] They reach out to support a lot

[00:17:52] and they're like, I want this feature.

[00:17:54] And so it is very well known to us

[00:17:56] the features that are heavily demanded.

[00:17:58] They very much surface themselves through support

[00:18:03] and solutions engineering.

[00:18:05] And then the other part that we started to do a little bit more recently is

[00:18:09] I would say more like blind feedback in a way of like,

[00:18:12] there's like systems like user testing that you can say,

[00:18:16] I want to talk to people that work at these types of companies with these roles.

[00:18:21] And you'll pay them like 50 bucks to attend.

[00:18:23] And you get a talk with like four or five of these people that you've never met before

[00:18:26] that are not customers that are coming in completely fresh.

[00:18:29] And you can ask them a set of questions and be like,

[00:18:31] okay, what are your most pressing problems?

[00:18:32] And they have no incentive to lie to you because they're never going to see you again.

[00:18:35] They're not a customer to your product.

[00:18:36] And so you get really high quality data out of that in my opinion.

[00:18:40] And so we've done a fair amount of that.

[00:18:43] And then the last thing we do is we'll pop up in landing pages

[00:18:46] and we'll be like, okay, let's put these landing pages up

[00:18:49] that we think may solve some sets of problems.

[00:18:53] We're going to make sure that it tells a story well enough

[00:18:55] that it would convince someone to put in their email address to talk to us.

[00:18:57] And then we're going to run some ads against it on keywords

[00:19:00] or put on our website.

[00:19:01] And we're, it's easily discoverable

[00:19:04] and we'll see how much traffic we get and people sign up.

[00:19:06] And if it does, that's also another big signal for us

[00:19:08] that we have something there.

[00:19:10] So that's, we do it in a number of different ways.

[00:19:13] And we're kind of like taking all that data from different places

[00:19:15] to build a complete picture of like, what should we be building?

[00:19:17] What should we be building and why?

[00:19:19] And what's our unique differentiator there?

[00:19:21] Like we always try to say, what's the Doppler way of doing this?

[00:19:28] Fostering an engaged product organization

[00:19:31] and aligning them with the principles around lean,

[00:19:34] human-centered design and agile

[00:19:36] will more than likely lead to successful business outcomes

[00:19:40] for your organization.

[00:19:41] But getting started or getting unblocked can be hard.

[00:19:44] This podcast is brought to you by the player coaches over at Integral.

[00:19:48] They help ambitious companies like you

[00:19:51] build amazing product teams

[00:19:53] and ship products in artificial intelligence,

[00:19:56] cloud, web, and mobile.

[00:19:59] Listeners to the podcast can head on over

[00:20:01] to integral.io slash convergence

[00:20:05] and get a free product success lab.

[00:20:08] During this session,

[00:20:10] the Integral team will facilitate

[00:20:11] a problem-solving exercise

[00:20:13] that gives you clarity and confidence

[00:20:15] to solve a product design or engineering problem.

[00:20:19] That's integral.io slash convergence.

[00:20:24] Now, back to the show.

[00:20:25] Something that I find most successful platform

[00:20:31] and infrastructure companies tend to do

[00:20:33] is having their internal developers

[00:20:36] also use the same platform

[00:20:38] when they do their development.

[00:20:40] There's an often repeated rumor

[00:20:42] that Jeff Bezos mandated

[00:20:44] that all Amazon's developers

[00:20:46] would communicate only via service interfaces

[00:20:49] and is believed that was a turning point

[00:20:52] back in 2002

[00:20:53] in transforming Amazon's architecture

[00:20:56] into a service-oriented architecture

[00:20:58] and ultimately paved the way

[00:21:00] for what became Amazon Web Services,

[00:21:02] which accounts for a majority of Amazon's profits.

[00:21:06] Kenneth is back to talk about

[00:21:07] the importance of dogfooding

[00:21:09] or using your own platform

[00:21:10] amongst both your internal teams

[00:21:12] and external teams

[00:21:14] rather than having separate systems and tools

[00:21:16] for your internal developers

[00:21:18] and your external customer developers.

[00:21:20] Rolling out an internal platform

[00:21:22] requires care to be done correctly

[00:21:24] at any company.

[00:21:25] And adoption should be a function

[00:21:28] of the product being really good

[00:21:29] rather than a leadership mandate.

[00:21:31] Here I mentioned a lot of like

[00:21:33] quantitative kind of things.

[00:21:35] A big part of this

[00:21:36] is also more qualitative kind of aspects.

[00:21:39] It's user testing.

[00:21:40] It is doing what we describe

[00:21:42] called friction locking

[00:21:43] that is really about having a developer

[00:21:47] write down all the friction they encounter

[00:21:50] when they start trying to use your product.

[00:21:53] So it's really like a simple kind of recipe

[00:21:55] as like you have a Google Doc

[00:21:57] with a template

[00:21:58] and you write down all the friction

[00:22:00] or surprisingly great moments you have

[00:22:03] and you give it a rating

[00:22:04] and really providing that feedback

[00:22:06] in a kind of concise format

[00:22:09] and sharing that with the team.

[00:22:11] Internally at Stripe,

[00:22:12] we would do that internally.

[00:22:14] I would be trying my sister team's product

[00:22:16] and I'd be writing a friction log to them

[00:22:18] documenting all the friction.

[00:22:20] And this is really just the mindset

[00:22:21] if you're tying it back

[00:22:22] to the mindset of craft and culture

[00:22:24] is that this is really about like product quality

[00:22:28] and enabling product quality at scale

[00:22:29] and enabling taste,

[00:22:31] product taste and product sense at scale.

[00:22:33] So we'd be spending a lot of time

[00:22:35] really enabling positive feedback loops

[00:22:38] when we are building things,

[00:22:40] whether it would be with internal teams,

[00:22:42] colleagues, really early design partners

[00:22:44] and getting them to kick the tires,

[00:22:47] provide feedback,

[00:22:48] write a friction log,

[00:22:49] yell at us that it doesn't work, etc.

[00:22:51] And really enable that product development loop.

[00:22:53] And I think that's probably where like a lot of,

[00:22:57] it's a very common failure mode

[00:22:58] for teams of any size

[00:23:00] to really get disconnected

[00:23:02] from that product feedback loop

[00:23:03] and build things in a vacuum.

[00:23:07] And if you end up building things

[00:23:08] in a vacuum for a while,

[00:23:09] usually that means you will steer off track

[00:23:12] because you're kind of in your own echo chamber.

[00:23:15] So everything we were building for developers

[00:23:18] has always been built

[00:23:20] with design partners in mind,

[00:23:23] working directly with customers,

[00:23:24] getting feedback,

[00:23:26] tying it to like really like discerning developers

[00:23:29] that can provide us candid feedback

[00:23:30] and saying this doesn't work

[00:23:31] or this is awesome.

[00:23:34] And, you know, there's probably enough,

[00:23:37] like Stripe's got hundreds of thousands of developers

[00:23:40] and so internally and as well externally.

[00:23:44] And so there's a lot of access to folks now

[00:23:48] that you can get the feedback

[00:23:50] and testing and validation.

[00:23:52] Now, what about if you're a startup

[00:23:54] or you don't have as much access

[00:23:56] internally or adjacently?

[00:23:59] What are some approaches you've seen

[00:24:01] or you've done to get in front of the right folks?

[00:24:04] And then is there like a favorite type

[00:24:07] of test or experiment or approach

[00:24:09] that you have to gain confidence or validation?

[00:24:12] Yeah, like I really think like

[00:24:13] when you're in the early stages

[00:24:14] of you building your product,

[00:24:17] it's really about you going out there

[00:24:19] and recruiting customers.

[00:24:20] And some of the early stage companies

[00:24:22] I'm now working with,

[00:24:23] it's really about like the founder

[00:24:25] being loud on Twitter.

[00:24:26] Is you going through your communities

[00:24:29] that you're part of to identify your customers

[00:24:31] and really identify those early customers?

[00:24:35] It's like it's always great to like be attending

[00:24:38] and speaking at events to kind of go out there

[00:24:40] and recruit your customers,

[00:24:41] build your following on various social media, etc.

[00:24:45] But also just like,

[00:24:47] I think there's an element of like,

[00:24:50] you don't like a very common failure mode

[00:24:53] is that you end up building something

[00:24:55] and you think your customers will come.

[00:24:57] Usually that's not how it works.

[00:24:58] It has to be the synergy, right?

[00:25:00] So you really need to know

[00:25:02] who you're building for.

[00:25:04] Usually the reason for why

[00:25:05] you end up building something

[00:25:06] is that you start with a problem.

[00:25:07] That problem is because

[00:25:08] you're hurting from a customer

[00:25:10] and you really want to work

[00:25:11] with that customer very closely.

[00:25:15] A key part of like the early days of Stripe

[00:25:17] that was before my time

[00:25:18] and really like the story you're hearing

[00:25:20] about John and Patrick

[00:25:21] is that they will literally be out there pitching

[00:25:25] and saying we can help you with your payments

[00:25:26] and if you want to use it,

[00:25:29] users will come to your office

[00:25:30] and we'll spend an afternoon

[00:25:32] integrating Stripe for you.

[00:25:34] We'll rip out your whole payments integration

[00:25:35] and I personally,

[00:25:37] I will integrate Stripe with you

[00:25:38] and make sure that you're great.

[00:25:40] I think that strategy is very, very viable

[00:25:42] even in 2024

[00:25:44] is that you have to go out there

[00:25:45] and really demonstrate the value of your product.

[00:25:47] And if you happen to be based in a major city

[00:25:50] like SF or New York,

[00:25:53] you have a lot of your customers here.

[00:25:54] So it's really about like you coming out

[00:25:56] and doing like essentially founder-led sales.

[00:25:59] You want to like go all P.O.G. about it.

[00:26:02] Like building developer tools

[00:26:03] and infrastructure is really like P.O.G.

[00:26:06] There's no other way in the beginning

[00:26:07] is that you have to go out there

[00:26:08] and lead with the value

[00:26:09] and really like just integrate the product

[00:26:12] if they cannot do it for,

[00:26:14] if they kind of do it themselves.

[00:26:21] To share expert advice on this topic,

[00:26:23] we have Wes Berry.

[00:26:24] He's a finding engineer at anchor.dev

[00:26:27] who provide encryption as a service

[00:26:29] for your development teams.

[00:26:30] Wes also worked at Heroku,

[00:26:32] an extremely developer-friendly platform

[00:26:35] directly for their chief of staff.

[00:26:40] Consistency is a topic that comes up frequently

[00:26:42] when developers talk about

[00:26:44] what differentiates

[00:26:45] the really delightful developer experiences

[00:26:48] from the super frustrating ones.

[00:26:50] I've seen this kind of be a risky slippery slope

[00:26:53] where something that starts out

[00:26:56] with the intent of being an enabler

[00:26:57] can then become a gatekeeper.

[00:27:01] And believe it or not,

[00:27:01] I've seen it at enterprises

[00:27:03] where it's easier to believe,

[00:27:04] but also at smaller companies

[00:27:05] that are trying to be intentional.

[00:27:07] And I'm curious if there's like

[00:27:09] an underlying advice that you have

[00:27:12] for delivery leaders or engineering leaders

[00:27:14] around having enablers continue to be enablers

[00:27:17] and mitigating that risk of them

[00:27:19] slipping into becoming gatekeepers

[00:27:20] that actually slow us down in the long term.

[00:27:22] I think one of the things that makes that breakdown

[00:27:25] in companies that I've seen

[00:27:26] is that an internal solution is developed

[00:27:29] and then mandated.

[00:27:30] It's not a,

[00:27:31] oh yeah, of course I'm going to use

[00:27:33] the internal developer environment

[00:27:37] as a service thing

[00:27:38] because it's so much easier

[00:27:39] and it gives me exactly what I want.

[00:27:40] Like why would I possibly roll my own?

[00:27:42] If that's the situation,

[00:27:43] I think you're much more likely

[00:27:44] in the situation where

[00:27:46] it will probably end up being pretty good

[00:27:48] because like they live or die

[00:27:50] on whether or not there's internal adoption, right?

[00:27:52] Like if that's the way you set it up

[00:27:54] and you basically say like

[00:27:54] your job is to try to productize

[00:27:57] and make this a thing

[00:27:58] that our internal developers care about

[00:27:59] and want to use.

[00:28:00] If you can't do that,

[00:28:02] then we'll just spin down the team.

[00:28:04] We'll say that we didn't succeed.

[00:28:05] We'll move on.

[00:28:05] But instead, yeah,

[00:28:06] a lot of times it's sort of like,

[00:28:07] well, we rolled this thing out

[00:28:08] and now we're just going to mandate it.

[00:28:10] And whether you intend to or not,

[00:28:11] you end up in the situation

[00:28:12] where it's like, well, it's kind of shitty,

[00:28:14] but we don't really have to fix it

[00:28:16] because everybody has to use it.

[00:28:18] Like, you know,

[00:28:19] like they were told

[00:28:19] that they have to use it.

[00:28:20] So like I don't have to necessarily

[00:28:22] go to the trouble

[00:28:23] of making it a great experience.

[00:28:25] I don't have to necessarily compare it

[00:28:27] to what came before.

[00:28:28] Like they have to use it.

[00:28:29] So they have to use it.

[00:28:30] So you get to this sort of like MVP

[00:28:33] that is not a great experience,

[00:28:34] but technically works.

[00:28:35] And then you, you know,

[00:28:38] clean your hands of it

[00:28:38] and you walk away

[00:28:39] and you go back over

[00:28:40] to whatever else you were doing.

[00:28:41] Right.

[00:28:41] Versus the goal really

[00:28:43] is to have this be something

[00:28:43] that people want to use.

[00:28:45] If they want to use it,

[00:28:46] then adoption and whatever else

[00:28:48] and like enablement,

[00:28:49] like we're done.

[00:28:50] Like, you know,

[00:28:51] people have been enabled

[00:28:51] because they want to use it.

[00:28:52] It's giving them what they want.

[00:28:53] Right.

[00:28:54] I think that's,

[00:28:55] that feels like

[00:28:55] where that disconnect often happens.

[00:28:57] Yeah.

[00:28:58] Adoption is really easy to drive up

[00:28:59] if you mandate it.

[00:29:01] Right.

[00:29:01] Where.

[00:29:01] Yeah.

[00:29:02] Yeah.

[00:29:02] Where you're going to get yelled at

[00:29:03] by your boss

[00:29:04] if you don't do it.

[00:29:05] And so there's a few things

[00:29:07] that I think that maybe

[00:29:10] aren't given enough credit.

[00:29:11] One of them is

[00:29:12] a clearly stated goal

[00:29:13] or problem that's being solved.

[00:29:15] The second one is like

[00:29:17] one person

[00:29:18] or a really small team

[00:29:19] that gets to make the decisions

[00:29:20] around how we're going to go out

[00:29:22] and achieve that goal

[00:29:23] and solve that problem.

[00:29:24] And then I think the third one,

[00:29:26] which is maybe even the hardest

[00:29:27] to apply or adopt

[00:29:29] is then we'll spin down the team

[00:29:31] if it doesn't work out.

[00:29:32] Because I think

[00:29:33] a lot of the reason

[00:29:34] that folks kind of

[00:29:35] continue on this way

[00:29:36] and double down

[00:29:37] is because of maybe

[00:29:38] a sub-cost fallacy

[00:29:39] or a cultural reason

[00:29:41] where spinning down a team

[00:29:42] is not quite that fluid

[00:29:44] and that ends up being

[00:29:45] for folks with the best intentions

[00:29:47] around being agile and nimble

[00:29:50] leading to

[00:29:52] sticking with things

[00:29:53] that they maybe

[00:29:54] all kind of sense

[00:29:55] doesn't make sense anymore

[00:29:57] but we're kind of

[00:29:57] pressuring through.

[00:30:04] And Kenneth is back

[00:30:05] to talk about a concept

[00:30:07] called abstraction ladders

[00:30:08] as well as the importance

[00:30:10] of having discipline

[00:30:11] and consistency

[00:30:12] when it comes

[00:30:13] to your abstraction ladders.

[00:30:14] You mentioned abstraction in there

[00:30:16] and I think

[00:30:18] when you think about

[00:30:18] going back to what

[00:30:19] you were talking about

[00:30:20] really being intentional

[00:30:21] about the product

[00:30:23] abstraction

[00:30:23] in that common language

[00:30:25] is something

[00:30:25] you want to be intentional around

[00:30:26] where your customer developers

[00:30:28] and your own developers

[00:30:29] are thinking about the same way

[00:30:30] and I know

[00:30:31] you've got this concept

[00:30:32] around abstraction ladders

[00:30:33] that maybe helps with that

[00:30:34] so talk to me a little bit

[00:30:35] about that.

[00:30:36] Yeah, like

[00:30:36] we think about like

[00:30:38] first of all

[00:30:39] what is an abstraction

[00:30:40] what are you providing

[00:30:41] to like

[00:30:42] generally what you do

[00:30:43] is that you're trying

[00:30:44] to abstract away complexity

[00:30:46] you're trying to make

[00:30:47] something

[00:30:48] like simpler to use

[00:30:49] by providing

[00:30:50] a need of abstraction

[00:30:51] and a need of packaging

[00:30:52] around it

[00:30:53] and I really think

[00:30:54] like

[00:30:55] some of the greatest

[00:30:56] platforms in the world

[00:30:58] have this really great concept

[00:31:00] of abstraction ladders

[00:31:02] is that

[00:31:03] you can go from

[00:31:04] one level of abstraction

[00:31:06] to another

[00:31:06] you can always have

[00:31:08] like slight visibility

[00:31:09] in terms of understanding

[00:31:10] what is happening

[00:31:11] behind the surface

[00:31:12] but it's also a matter

[00:31:14] of like

[00:31:16] abstraction ladders

[00:31:17] is really about like

[00:31:18] power versus complexity

[00:31:19] if you think about

[00:31:20] this as a biogram

[00:31:22] is that

[00:31:22] as you kind of go up

[00:31:24] in the abstraction ladder

[00:31:25] you kind of get

[00:31:27] get further further away

[00:31:28] from like

[00:31:29] the lower levels

[00:31:30] but it's really about

[00:31:32] like enabling you

[00:31:33] to either be

[00:31:33] more powerful

[00:31:35] that means you go down

[00:31:36] the ladder

[00:31:36] or like

[00:31:38] you kind of shield

[00:31:39] away more complexity

[00:31:40] so it's kind of like

[00:31:41] this nice relationship

[00:31:43] of like

[00:31:43] usually you want

[00:31:44] when you start

[00:31:45] consuming a platform

[00:31:46] you want to be

[00:31:46] very high level

[00:31:48] you want to like

[00:31:49] do a very specific task

[00:31:50] but you can kind of

[00:31:51] like take another layer

[00:31:52] of the onion

[00:31:53] and you go down

[00:31:54] and you will real

[00:31:54] more complex

[00:31:55] like you expose

[00:31:57] more complexity

[00:31:58] but you reveal

[00:31:59] more power

[00:32:00] and you can continue

[00:32:01] to go down

[00:32:02] that abstraction ladder

[00:32:03] and suddenly

[00:32:03] you are down

[00:32:04] at like the very low level

[00:32:05] where you have

[00:32:06] a lot of power

[00:32:07] but it's also

[00:32:08] very very very

[00:32:09] complicated

[00:32:09] and complex to use

[00:32:10] so there's definitely

[00:32:11] like a lot of art

[00:32:12] in designing

[00:32:13] those experiences

[00:32:14] and designing

[00:32:14] those abstraction ladders

[00:32:16] and platform builders

[00:32:17] are spending

[00:32:19] years agonizing

[00:32:20] over the right details

[00:32:21] and think about

[00:32:21] those

[00:32:23] relationships

[00:32:23] relationships

[00:32:23] if you could

[00:32:25] maybe give us

[00:32:26] an example

[00:32:26] maybe from stripe

[00:32:27] or somewhere else

[00:32:28] that our folks

[00:32:29] can relate to

[00:32:29] a little bit

[00:32:30] around what

[00:32:30] are some things

[00:32:31] on the different

[00:32:32] layers of

[00:32:33] that ladder

[00:32:34] and how that

[00:32:36] power and complexity

[00:32:37] kind of interact

[00:32:37] yeah like

[00:32:39] like a high level

[00:32:40] kind of concept

[00:32:41] would be that

[00:32:42] think about

[00:32:43] a company

[00:32:44] that is providing

[00:32:45] a authentication

[00:32:46] page

[00:32:48] and they have

[00:32:49] like a few

[00:32:50] different flavors

[00:32:51] of enabling

[00:32:52] you to do

[00:32:53] authentication

[00:32:53] and having

[00:32:54] a nice

[00:32:55] login screen

[00:32:55] where you can

[00:32:55] sign in with

[00:32:56] Google

[00:32:56] there one flavor

[00:32:57] that is

[00:32:58] we're going to

[00:32:59] do all the

[00:32:59] hosted page

[00:33:00] for you

[00:33:01] all we're going

[00:33:01] to give you

[00:33:02] is a link

[00:33:02] you can give

[00:33:03] that to your

[00:33:03] customers

[00:33:04] and they can

[00:33:04] log in

[00:33:04] the next

[00:33:06] kind of offering

[00:33:07] they have

[00:33:07] is like

[00:33:08] we give you

[00:33:09] like a UI

[00:33:09] library

[00:33:10] that you can

[00:33:11] embed inside

[00:33:11] your own

[00:33:12] website

[00:33:12] and the

[00:33:13] next

[00:33:14] abstraction

[00:33:14] might be

[00:33:15] we give

[00:33:16] you like

[00:33:16] a low

[00:33:17] level

[00:33:17] JavaScript

[00:33:19] library

[00:33:19] that you

[00:33:19] can call

[00:33:20] and build

[00:33:20] kind of

[00:33:20] your own

[00:33:21] UI

[00:33:21] and the

[00:33:22] next

[00:33:22] abstraction

[00:33:23] would be

[00:33:24] like

[00:33:24] we give

[00:33:24] you just

[00:33:24] an API

[00:33:25] you can

[00:33:26] call

[00:33:26] with

[00:33:26] curl

[00:33:27] and then

[00:33:27] you can

[00:33:27] log in

[00:33:28] users

[00:33:29] and

[00:33:29] those

[00:33:30] are

[00:33:30] essentially

[00:33:31] the same

[00:33:31] experience

[00:33:32] we're

[00:33:32] providing

[00:33:32] a way

[00:33:32] users

[00:33:33] can

[00:33:33] log in

[00:33:33] but

[00:33:34] there's

[00:33:34] different

[00:33:36] abstractions

[00:33:37] into

[00:33:37] the complexity

[00:33:38] that's

[00:33:38] being

[00:33:38] hidden

[00:33:42] but

[00:33:43] each

[00:33:43] option

[00:33:44] has

[00:33:44] different

[00:33:44] kind

[00:33:45] of

[00:33:45] a

[00:33:45] combination

[00:33:46] of

[00:33:47] power

[00:33:47] and

[00:33:47] complexities

[00:33:48] that

[00:33:48] the

[00:33:48] low

[00:33:49] level

[00:33:49] API

[00:33:50] that

[00:33:50] is

[00:33:51] has

[00:33:51] a lot

[00:33:52] of

[00:33:52] power

[00:33:52] but

[00:33:53] also

[00:33:53] means

[00:33:54] that

[00:33:55] developer

[00:33:55] have

[00:33:55] to

[00:33:56] absorb

[00:33:57] a lot

[00:33:57] of

[00:33:57] that

[00:33:57] complexity

[00:33:58] themselves

[00:33:58] and

[00:33:59] build

[00:33:59] a lot

[00:33:59] of

[00:33:59] experience

[00:34:00] and

[00:34:01] some

[00:34:01] of

[00:34:01] the

[00:34:02] best

[00:34:02] platforms

[00:34:02] that

[00:34:03] have

[00:34:03] multiple

[00:34:04] flavors

[00:34:05] of

[00:34:05] such

[00:34:06] a

[00:34:06] product

[00:34:06] offering

[00:34:07] are

[00:34:08] actually

[00:34:08] enabling

[00:34:08] a

[00:34:09] linear

[00:34:09] path

[00:34:10] through

[00:34:10] those

[00:34:11] experiences

[00:34:11] so

[00:34:11] that

[00:34:11] means

[00:34:12] if

[00:34:12] you

[00:34:12] go

[00:34:12] back

[00:34:13] to

[00:34:13] this

[00:34:14] hosted

[00:34:15] page

[00:34:15] the

[00:34:15] hosted

[00:34:15] page

[00:34:16] is

[00:34:16] actually

[00:34:16] using

[00:34:17] the

[00:34:18] UI

[00:34:18] components

[00:34:19] the

[00:34:19] UI

[00:34:20] components

[00:34:20] is

[00:34:21] actually

[00:34:21] using

[00:34:21] the

[00:34:21] SDK

[00:34:22] the

[00:34:22] SDK

[00:34:23] is

[00:34:23] actually

[00:34:23] calling

[00:34:23] the

[00:34:24] same

[00:34:24] API

[00:34:24] and

[00:34:25] there's

[00:34:25] kind

[00:34:41] the

[00:34:41] world

[00:34:41] enabling

[00:34:42] that

[00:34:43] careful

[00:34:43] reveal

[00:34:44] over

[00:34:44] time

[00:34:44] but

[00:34:45] they

[00:34:45] also

[00:34:45] enable

[00:34:47] a

[00:34:48] user

[00:34:48] to

[00:34:48] kind

[00:34:48] of

[00:34:48] press

[00:34:49] the

[00:34:49] eject

[00:34:49] button

[00:34:49] that

[00:34:50] they

[00:34:50] can

[00:34:50] always

[00:34:50] go

[00:34:51] one

[00:34:51] level

[00:34:51] further

[00:34:52] down

[00:34:53] that

[00:34:53] abstraction

[00:34:53] ladder

[00:34:54] so

[00:34:54] let's

[00:34:55] say

[00:34:55] if you're

[00:34:55] going

[00:34:55] for

[00:34:56] the

[00:34:56] hosted

[00:34:56] page

[00:34:56] you

[00:34:56] can

[00:35:11] way

[00:35:11] down

[00:35:11] when we

[00:35:11] think

[00:35:12] about

[00:35:12] programming

[00:35:12] I can

[00:35:13] go

[00:35:13] from

[00:35:13] one

[00:35:13] programming

[00:35:14] language

[00:35:14] I can

[00:35:14] go

[00:35:14] to

[00:35:15] byte

[00:35:15] code

[00:35:15] I can

[00:35:15] go

[00:35:16] to

[00:35:16] assembly

[00:35:17] etc.

[00:35:23] Wes

[00:35:24] from

[00:35:24] Anchor

[00:35:25] is back

[00:35:25] and he

[00:35:26] talks about

[00:35:27] his time

[00:35:27] at Heroku

[00:35:28] where they

[00:35:29] drove

[00:35:29] consistency

[00:35:30] on their

[00:35:31] CLI

[00:35:31] or command

[00:35:32] line

[00:35:32] interface

[00:35:32] and then

[00:35:33] adopted

[00:35:34] the same

[00:35:34] approach

[00:35:35] to their

[00:35:35] API

[00:35:36] team

[00:35:36] to make

[00:35:37] the platform

[00:35:38] way more

[00:35:38] intuitive

[00:35:39] to Heroku's

[00:35:40] developer

[00:35:40] customers

[00:35:41] I think

[00:35:41] the CLI

[00:35:42] for them

[00:35:43] was pretty

[00:35:43] well known

[00:35:44] for being

[00:35:44] a good

[00:35:45] developer

[00:35:46] experience

[00:35:46] overall

[00:35:47] but

[00:35:48] being

[00:35:49] as

[00:35:50] into the

[00:35:51] weeds

[00:35:51] and some

[00:35:51] of the

[00:35:52] other

[00:35:52] things

[00:35:52] we were

[00:35:52] talking

[00:35:52] about

[00:35:53] before

[00:35:54] it

[00:35:54] bugged

[00:35:54] me

[00:35:54] that

[00:35:55] there

[00:35:55] were

[00:35:55] inconsistencies

[00:35:56] and

[00:35:56] some

[00:35:56] other

[00:35:56] things

[00:35:57] that

[00:35:57] just

[00:35:57] felt

[00:35:57] like

[00:35:57] they

[00:35:57] could

[00:35:57] be

[00:35:58] better

[00:35:59] and

[00:35:59] some

[00:36:00] of

[00:36:00] that

[00:36:00] comes

[00:36:00] from

[00:36:00] the

[00:36:00] nature

[00:36:01] of

[00:36:02] small

[00:36:03] startups

[00:36:03] and

[00:36:04] shared

[00:36:04] ownership

[00:36:04] and

[00:36:05] other

[00:36:05] things

[00:36:05] I

[00:36:05] mean

[00:36:05] it's

[00:36:06] the

[00:36:06] same

[00:36:06] issue

[00:36:07] that

[00:36:15] they

[00:36:15] came

[00:36:16] in

[00:36:16] and

[00:36:16] added

[00:36:16] a

[00:36:16] feature

[00:36:17] but

[00:36:18] it

[00:36:18] may

[00:36:18] or

[00:36:19] may

[00:36:19] not

[00:36:19] have

[00:36:19] been

[00:36:19] totally

[00:36:19] consistent

[00:36:20] with

[00:36:20] what

[00:36:20] was

[00:36:20] there

[00:36:21] before

[00:36:21] because

[00:36:21] they

[00:36:22] were

[00:36:22] pretty

[00:36:22] focused

[00:36:23] on

[00:36:23] getting

[00:36:23] done

[00:36:23] what

[00:36:24] they

[00:36:24] needed

[00:36:24] to get

[00:36:24] done

[00:36:24] and

[00:36:25] it's

[00:36:25] hard

[00:36:25] to keep

[00:36:25] track

[00:36:25] of

[00:36:26] the

[00:36:26] broad

[00:36:26] scope

[00:36:27] of

[00:36:27] history

[00:36:28] and

[00:36:28] whatever

[00:36:28] else

[00:36:28] so

[00:36:29] a lot

[00:36:30] of

[00:36:30] commands

[00:36:30] that sat

[00:36:31] right

[00:36:31] next

[00:36:31] to

[00:36:31] each

[00:36:45] create

[00:36:46] as

[00:36:47] the

[00:36:47] thing

[00:36:47] to

[00:36:47] generate

[00:36:48] a

[00:36:48] new

[00:36:48] object

[00:36:48] and

[00:36:49] in

[00:36:49] some

[00:36:49] places

[00:36:49] you

[00:36:49] would

[00:36:49] say

[00:36:50] add

[00:36:50] and

[00:36:51] you

[00:36:51] know

[00:36:51] like

[00:36:51] that's

[00:36:52] just

[00:36:52] a

[00:36:52] small

[00:36:52] one

[00:36:52] for

[00:36:52] me

[00:36:52] where

[00:36:53] it's

[00:36:53] sort

[00:36:53] of

[00:36:53] like

[00:36:53] okay

[00:36:54] like

[00:36:54] we

[00:36:55] don't

[00:36:55] need

[00:36:55] two

[00:36:55] different

[00:36:56] verbs

[00:36:56] unless

[00:36:57] they're

[00:36:58] two

[00:36:58] distinct

[00:36:58] concepts

[00:36:59] like

[00:36:59] if

[00:37:00] these

[00:37:00] should

[00:37:00] be

[00:37:01] something

[00:37:01] that

[00:37:02] we

[00:37:02] want

[00:37:02] the

[00:37:02] user

[00:37:03] to

[00:37:03] think

[00:37:03] about

[00:37:03] in

[00:37:03] the

[00:37:03] same

[00:37:04] way

[00:37:04] like

[00:37:04] let's

[00:37:04] just

[00:37:04] use

[00:37:05] the

[00:37:05] same

[00:37:05] word

[00:37:05] we

[00:37:06] actually

[00:37:06] wrote

[00:37:06] a

[00:37:06] style

[00:37:07] guide

[00:37:07] for

[00:37:07] the

[00:37:07] CLI

[00:37:07] so

[00:37:08] people

[00:37:09] I

[00:37:09] think

[00:37:09] mostly

[00:37:10] think

[00:37:10] about

[00:37:10] style

[00:37:11] guides

[00:37:11] in

[00:37:11] terms

[00:37:11] of

[00:37:11] a

[00:37:12] magazine

[00:37:12] or

[00:37:12] newspaper

[00:37:14] website

[00:37:14] right

[00:37:15] this

[00:37:15] is

[00:37:15] how

[00:37:15] things

[00:37:16] should

[00:37:16] be

[00:37:16] styled

[00:37:16] this

[00:37:17] is

[00:37:17] what

[00:37:17] titles

[00:37:17] should

[00:37:18] look

[00:37:18] like

[00:37:19] this

[00:37:19] is

[00:37:19] what

[00:37:19] a

[00:37:19] quote

[00:37:20] should

[00:37:29] look

[00:37:29] like

[00:37:29] this

[00:37:30] so

[00:37:30] if

[00:37:30] it's

[00:37:30] outputting

[00:37:31] this

[00:37:31] sort

[00:37:31] of

[00:37:31] thing

[00:37:32] this

[00:37:32] is

[00:37:32] what

[00:37:32] we

[00:37:32] would

[00:37:33] expect

[00:37:33] and

[00:37:33] so

[00:37:33] again

[00:37:34] just

[00:37:34] trying

[00:37:35] to

[00:37:35] provide

[00:37:35] a

[00:37:37] template

[00:37:37] that

[00:37:37] people

[00:37:38] could

[00:37:38] look

[00:37:38] at

[00:37:38] and

[00:37:38] follow

[00:37:39] along

[00:37:39] so

[00:37:39] that

[00:37:39] even

[00:37:40] if

[00:37:40] it

[00:37:40] was

[00:37:40] getting

[00:37:41] back

[00:37:41] to

[00:37:41] the

[00:37:41] world

[00:37:41] of

[00:37:42] so

[00:37:42] and

[00:37:42] so

[00:37:42] came

[00:37:43] in

[00:37:43] and

[00:37:43] implemented

[00:37:43] this

[00:37:43] because

[00:37:44] they

[00:37:44] needed

[00:37:44] for

[00:37:44] a

[00:37:44] feature

[00:37:45] it

[00:37:46] would

[00:37:46] be

[00:37:46] less

[00:37:46] likely

[00:37:46] to

[00:37:47] way

[00:37:47] out

[00:37:48] there

[00:37:48] it

[00:37:49] would

[00:37:49] be

[00:37:49] more

[00:37:49] likely

[00:37:49] to

[00:37:49] be

[00:37:49] more

[00:37:50] similar

[00:37:50] to

[00:37:50] what

[00:37:50] we

[00:37:51] were

[00:37:51] doing

[00:37:51] elsewhere

[00:37:52] I

[00:37:53] ended

[00:37:53] up

[00:37:53] after

[00:37:53] that

[00:37:54] moving

[00:37:54] on

[00:37:54] to

[00:37:54] the

[00:37:54] API

[00:37:54] team

[00:37:55] where

[00:37:55] we

[00:37:56] had

[00:37:56] the

[00:37:56] same

[00:37:56] problem

[00:37:56] the

[00:37:57] API

[00:37:57] hadn't

[00:37:58] really

[00:37:58] been

[00:37:58] owned

[00:37:58] by

[00:37:59] anyone

[00:37:59] per

[00:37:59] se

[00:38:00] it

[00:38:00] was

[00:38:00] intended

[00:38:01] for

[00:38:01] internal

[00:38:01] use

[00:38:02] and

[00:38:02] almost

[00:38:02] all

[00:38:02] of

[00:38:02] it

[00:38:03] had

[00:38:03] been

[00:38:03] developed

[00:38:03] actually

[00:38:03] to

[00:38:04] support

[00:38:04] the

[00:38:04] CLI

[00:38:04] so

[00:38:06] just

[00:38:06] like

[00:38:07] people

[00:38:07] came

[00:38:07] in

[00:38:07] to

[00:38:07] add

[00:38:08] something

[00:38:08] to

[00:38:08] CLI

[00:38:09] because

[00:38:09] they

[00:38:09] needed

[00:38:09] a

[00:38:09] feature

[00:38:19] was

[00:38:19] their

[00:38:20] primary

[00:38:20] responsibility

[00:38:20] and

[00:38:22] hodgepodge

[00:38:23] of

[00:38:23] different

[00:38:23] styles

[00:38:23] and

[00:38:24] different

[00:38:24] preferences

[00:38:25] and

[00:38:25] opinions

[00:38:25] and

[00:38:26] other

[00:38:26] things

[00:38:26] and

[00:38:26] so

[00:38:27] a lot

[00:38:27] of

[00:38:27] the

[00:38:28] work

[00:38:28] of

[00:38:28] bringing

[00:38:29] the

[00:38:30] Heroku

[00:38:30] API

[00:38:30] to

[00:38:31] the

[00:38:31] public

[00:38:31] what

[00:38:31] we

[00:38:32] call

[00:38:32] the

[00:38:32] V3

[00:38:32] API

[00:38:32] was

[00:38:33] how

[00:38:34] do

[00:38:34] we

[00:38:34] sort

[00:38:34] of

[00:38:34] reconcile

[00:38:35] that

[00:38:35] and

[00:38:35] try

[00:38:36] to

[00:38:36] smooth

[00:38:36] off

[00:38:37] the

[00:38:37] edges

[00:38:37] and

[00:38:37] make

[00:38:37] it

[00:38:37] more

[00:38:38] consistent

[00:38:38] from

[00:38:38] one

[00:38:38] resource

[00:38:39] to

[00:38:39] another

[00:38:39] so

[00:38:39] that

[00:38:39] people

[00:38:40] can

[00:38:40] have

[00:38:41] an

[00:38:41] easier

[00:38:41] time

[00:38:41] knowing

[00:38:41] what

[00:38:57] the

[00:39:03] last

[00:39:03] segment

[00:39:03] for

[00:39:03] today

[00:39:04] Kenneth

[00:39:05] is

[00:39:05] back

[00:39:05] to

[00:39:06] share

[00:39:06] his

[00:39:06] takeaways

[00:39:07] about

[00:39:07] the

[00:39:08] culture

[00:39:08] at

[00:39:08] Stripe

[00:39:09] and

[00:39:09] what

[00:39:10] he

[00:39:10] believed

[00:39:10] leads

[00:39:11] to

[00:39:11] building

[00:39:11] surprisingly

[00:39:12] great

[00:39:13] experiences

[00:39:13] giving

[00:39:14] a

[00:39:15] damn

[00:39:15] at

[00:39:16] the

[00:39:16] scale

[00:39:16] that

[00:39:16] Stripe

[00:39:17] plays

[00:39:17] at

[00:39:17] and

[00:39:18] the

[00:39:19] importance

[00:39:19] of

[00:39:19] catering

[00:39:20] to

[00:39:20] early

[00:39:20] adopters

[00:39:21] on

[00:39:22] the

[00:39:22] journey

[00:39:22] of

[00:39:22] gaining

[00:39:23] market

[00:39:23] adoption

[00:39:23] for

[00:39:24] your

[00:39:24] developer

[00:39:25] tools

[00:39:25] so

[00:39:26] what

[00:39:26] do

[00:39:26] you

[00:39:26] think

[00:39:27] it

[00:39:27] is

[00:39:27] about

[00:39:28] the

[00:39:28] culture

[00:39:28] there

[00:39:28] what

[00:39:29] are

[00:39:29] some

[00:39:29] things

[00:39:29] that

[00:39:29] you

[00:39:30] learned

[00:39:30] from

[00:39:31] your

[00:39:31] time

[00:39:31] at

[00:39:31] Stripe

[00:39:32] that

[00:39:32] you

[00:39:32] provide

[00:39:33] as

[00:39:33] advice

[00:39:33] to

[00:39:34] startups

[00:39:34] or

[00:39:35] other

[00:39:35] folks

[00:39:35] in

[00:39:35] the

[00:39:35] space

[00:39:37] I

[00:39:37] definitely

[00:39:38] think

[00:39:38] the

[00:39:39] original

[00:39:40] Stripe

[00:39:40] culture

[00:39:41] and the

[00:39:41] culture

[00:39:42] I had

[00:39:42] the

[00:39:44] luxury

[00:39:45] to

[00:39:45] experience

[00:39:46] and being

[00:39:47] a part

[00:39:47] of

[00:39:47] for quite

[00:39:48] a few

[00:39:48] years

[00:39:48] is

[00:39:49] really

[00:39:49] about

[00:39:50] like

[00:39:50] a

[00:39:50] culture

[00:39:50] of

[00:39:51] craftsmanship

[00:39:51] and

[00:39:59] co-founders

[00:39:59] I

[00:39:59] think

[00:40:00] Patrick

[00:40:00] has

[00:40:00] a lot

[00:40:01] of

[00:40:01] great

[00:40:01] essays

[00:40:01] and

[00:40:02] talks

[00:40:02] he's

[00:40:02] been

[00:40:02] giving

[00:40:03] over

[00:40:05] the

[00:40:05] years

[00:40:05] but

[00:40:06] to

[00:40:06] me

[00:40:07] it's

[00:40:07] really

[00:40:07] about

[00:40:07] giving

[00:40:08] a

[00:40:08] damn

[00:40:08] at

[00:40:08] scale

[00:40:09] and

[00:40:09] Stripe

[00:40:10] is

[00:40:10] one

[00:40:29] products

[00:40:30] with

[00:40:30] a

[00:40:30] surprisingly

[00:40:31] great

[00:40:31] experience

[00:40:32] and

[00:40:32] that

[00:40:33] element

[00:40:33] of

[00:40:34] like

[00:40:35] surprisingly

[00:40:35] great

[00:40:36] like

[00:40:36] what

[00:40:36] does

[00:40:37] that

[00:40:37] mean

[00:40:37] it

[00:40:37] means

[00:40:37] that

[00:40:38] when

[00:40:38] you're

[00:40:39] integrating

[00:40:39] with

[00:40:39] the

[00:40:39] API

[00:40:40] and

[00:40:41] you

[00:40:42] make

[00:40:42] a

[00:40:42] typo

[00:40:42] naturally

[00:40:43] you

[00:40:43] should

[00:40:43] have

[00:40:43] spell

[00:40:44] checking

[00:40:44] we will

[00:40:45] spell

[00:40:45] check

[00:40:45] it

[00:40:45] for

[00:40:45] you

[00:40:46] or

[00:40:46] when

[00:40:47] you

[00:40:47] get

[00:40:47] like

[00:40:47] a

[00:40:48] API

[00:40:48] request

[00:40:48] and

[00:40:49] there's

[00:40:49] an

[00:40:49] error

[00:40:49] we'll

[00:40:49] actually

[00:40:50] give

[00:40:50] you

[00:40:50] a

[00:40:50] meaningful

[00:40:51] error

[00:40:51] message

[00:40:51] with

[00:40:52] the

[00:40:52] documentation

[00:40:53] something

[00:40:53] you

[00:40:54] didn't

[00:40:54] expect

[00:40:54] that

[00:40:59] so

[00:41:00] really

[00:41:00] that

[00:41:00] has

[00:41:00] kind

[00:41:00] of

[00:41:00] been

[00:41:01] a

[00:41:01] mantra

[00:41:02] of

[00:41:02] building

[00:41:02] surprisingly

[00:41:03] great

[00:41:03] experiences

[00:41:04] and

[00:41:05] really

[00:41:05] we

[00:41:05] think

[00:41:05] about

[00:41:05] the

[00:41:07] persona

[00:41:08] we

[00:41:08] have

[00:41:09] always

[00:41:09] been

[00:41:10] building

[00:41:10] for

[00:41:10] at

[00:41:11] Stripe

[00:41:12] has

[00:41:12] really

[00:41:12] been

[00:41:13] the

[00:41:13] discerning

[00:41:14] developer

[00:41:14] the

[00:41:15] startup

[00:41:15] founder

[00:41:16] the

[00:41:16] developer

[00:41:16] that

[00:41:18] really

[00:41:18] have

[00:41:20] the

[00:41:20] discerning

[00:41:20] perspective

[00:41:21] on

[00:41:21] quality

[00:41:22] etc

[00:41:22] how can

[00:41:23] we

[00:41:23] make

[00:41:23] them

[00:41:23] more

[00:41:23] happy

[00:41:26] etc

[00:41:26] and

[00:41:27] really

[00:41:27] continue

[00:41:27] to

[00:41:29] my

[00:41:30] philosophy

[00:41:30] has

[00:41:30] always

[00:41:30] been

[00:41:31] like

[00:41:31] if

[00:41:31] you

[00:41:31] build

[00:41:31] for

[00:41:32] the

[00:41:32] tastemakers

[00:41:33] of

[00:41:34] the

[00:41:34] world

[00:41:34] usually

[00:41:35] that

[00:41:35] also

[00:41:35] means

[00:41:36] that

[00:41:36] you're

[00:41:36] eventually

[00:41:36] making

[00:41:37] what

[00:41:37] I

[00:41:37] call

[00:41:38] the

[00:41:38] gray

[00:41:38] matter

[00:41:39] developers

[00:41:40] also

[00:41:40] happy

[00:41:40] that

[00:41:41] the

[00:41:41] most

[00:41:41] developers

[00:41:42] in the

[00:41:42] world

[00:41:42] they're

[00:41:43] the

[00:41:43] gray

[00:41:43] matter

[00:41:43] developers

[00:41:44] building

[00:41:45] the

[00:41:45] critical

[00:41:46] apps

[00:41:46] of

[00:42:03] out

[00:42:03] in

[00:42:03] archives

[00:42:04] and

[00:42:05] also

[00:42:05] stay

[00:42:06] tuned

[00:42:06] as

[00:42:06] we

[00:42:06] roll

[00:42:06] out

[00:42:07] more

[00:42:07] of

[00:42:07] our

[00:42:08] best

[00:42:08] of

[00:42:08] 2024

[00:42:08] episodes

[00:42:09] compiling

[00:42:10] insights

[00:42:11] and

[00:42:11] stories

[00:42:11] about

[00:42:12] OKRs

[00:42:13] product

[00:42:13] roadmapping

[00:42:14] and

[00:42:14] prioritization

[00:42:15] leadership

[00:42:16] and culture

[00:42:16] and product

[00:42:17] organizations

[00:42:18] and a lot

[00:42:19] more

[00:42:19] hit that

[00:42:20] subscribe

[00:42:21] button

[00:42:21] to get

[00:42:22] notified

[00:42:22] when

[00:42:23] those

[00:42:23] episodes

[00:42:24] launch

[00:42:24] in the

[00:42:25] meantime

[00:42:25] I hope

[00:42:26] you all

[00:42:26] have

[00:42:27] a wonderful

[00:42:27] week

[00:42:27] we will

[00:42:28] be back

[00:42:29] next

[00:42:29] Tuesday

[00:42:29] with our

[00:42:30] next

[00:42:31] episode

[00:42:37] thank you

[00:42:37] for joining

[00:42:38] me on

[00:42:38] the

[00:42:38] convergence

[00:42:39] podcast

[00:42:39] today

[00:42:40] subscribe

[00:42:41] to the

[00:42:41] convergence

[00:42:42] podcast

[00:42:42] on

[00:42:43] apple

[00:42:43] podcast

[00:42:44] spotify

[00:42:45] youtube

[00:42:46] or wherever

[00:42:47] you get

[00:42:47] your content

[00:42:48] if you're

[00:42:49] listening

[00:42:50] and found

[00:42:50] this helpful

[00:42:50] please give

[00:42:51] us a five

[00:42:52] star review

[00:42:52] and if

[00:42:53] you're

[00:42:53] watching

[00:42:54] hit that

[00:42:55] like

[00:42:55] button

[00:42:55] and tell

[00:42:56] me what

[00:42:56] you think

[00:42:56] about what

[00:42:57] you heard

[00:42:57] today