Laura Tacho: Jesse is in the thick of a platform consolidation. He’s unifying tech stacks across multiple billion dollar acquisitions, including Segment and SunGrid, while managing migrations across 1800 services. Today we’re going to talk about platform adoption, migration, and questioning whether Kubernetes is worth the promised ROI. Jesse, welcome to the show. Great to have you.
Jesse: Thank you. Yeah, it’s awesome to be here. I appreciate it.
Laura: I want to just start with a big question about how you came to Twilio in the first place. Can you tell me a little bit about how you even got there?
Jesse: Sure, yeah. I like to even think about my journey as being kind of zig-zaggy. My degree is in management information systems, which I feel like has left some colleges. It still sticks around but even the college I went to, it is not there anymore because it is like an underappreciated degree. It falls in the college of business and most people want to be in the computer science category and stuff, but it was this great cross of business and technology. And so, the core curriculum for me was databases, relational databases. And it still gets me to this day, the amount of people you can actually get through a CS degree, maybe databases are an elective and it kills me. Where it’s like, I feel like everybody should just have to be experts in them, but.
Laura: Databases and Git, I feel like you don’t need to have any understanding of that to graduate with a CS degree in most.
Jesse: Yeah, and so there was something about it, maybe the relational nature or what, but I loved it. I feel like my brain still works kind of in relational database ways. And so I was preparing for graduation and was like, man, if I could just write SQL all day long, how great would that be? And so I ended up getting a job at the time, it was Experian. And so the product I was working on was kind of like Google Analytics for car sales. And so lots of data every month and we were plumbing all that data and I was writing SQL. I was writing T-SQL, so it was on the Microsoft stack. And so that was my first job.
So then I went to a company to do cloud engineering, which turned into site reliability engineering. And it was at that point where I restarted my career into management, and so led that team for a while. And so that was my, I feel like there’s always the two experiences as a leader. You maybe start managing a team you were previously on, so you’re managing people that were your peers a week before. And then I went for the other experience coming to Twilio where, hey, I’m coming in as a manager and starting with a fresh team.
So, I’ve been here a little over four and a half years and originally started on just a tooling team, so tooling team for Segment at the time. So Segment was acquired by Twilio back then, and there was a team of three or four people that I came in to lead, and then we went through a big hiring spree in 2021 like a lot of companies. We grew the tooling team and a few others to an infrastructure team of about 50 for Segment, and then just recently joined in with the larger Twilio platform team of about 200. And so, that’s where we are today.
Laura: Yeah. I feel like what’s really interesting, first of all, that you want to spend all day writing SQL, I think you might be the only person I know-
Jesse: It’s great.
Laura: … who wants to do that. I mean, it is. It’s like, if your brain can think in structures like that, I mean, what a gift to have, Jesse. I also think know SRE, I really love being on call. I love SRE stuff. It’s like the pressure, it’s like a murder mystery. What’s it going to be this time? I feel like no one really starts their career as an SRE, and maybe no one really ends their career as an SRE either, but it’s a really good, intensive training ground for people to build resilience.
Jesse: Absolutely.
Laura: Learn really what’s important when it comes to building it and running it and owning it from start to finish.
Jesse: Yeah, I couldn’t agree more, and especially again, timing wise in the industry, we were in a place where the team I was leading was the only team that was on call so we were on call for everybody. Much smaller companies, but still, almost maybe 100 engineers and you had a team of, I think six or eight SREs that were just on call for the whole thing. And so, that was as DevOps was getting more popular and we had to do a lot of that education and stuff.
But yeah, I’ve certainly been at the conference table in an office with 10 people around me and I’m the one hitting the keys of, all right, how do you bring the whole stack back up? And I think that was such valuable experience because even today, I use it. Now it’s used metaphorically with people, but there is a weight, a literal physical weight that you feel as a person when you’re in an incident. And building that resiliency, learning how to do that is absolutely a learned skill. You can’t go to school for it or be taught it it in a presentation.
Laura: Yeah, and resiliency is so important for individual contributors, leaders. The process of becoming more resilient is not a very fun one, but a very important one.
Jesse: Absolutely.
Laura: Great. So you came to Twilio through the Segment acquisition, and Twilio has had some kind of big headline acquisitions, SendGrid being one of them, Segment being the other one. And I mean, integrating products like Segment, I was a happy Segment customer, and Segment has its own brand identity.
SendGrid had its own brand identity. Twilio had its own brand identity as kind of the core platform. Integrating all these tools is a lot more than just giving it common color scheme and a single login button.
Jesse: Yeah, absolutely.
Laura: Can you talk a little bit, I know right now you’re in this multi-year journey to bring together some of this fragmentation. Can you just talk a little bit about where you’re starting from?
Jesse: I think the first thing to center on that can be hard for folks is just the fact that it’s multi-year, it always is. When you’re at the start, it’s really, really hard to see the path to the end. You’ve got to make the hindsight adjustments as you go and just weave the path as it works.
In our case, four and a half years ago or so when I arrived, there were a lot of commonalities. We all used the same CI system, we all were entertaining moving to Kubernetes and things like that, but it’s the subtle nuances that make it non-obvious to get real efficiencies out of that. So we all use the same CI system, but the underlying agents that we were running were all deployed differently. And so it wasn’t just, cool, everybody go on this instance. Right?
With containers, Twilio having already had an internal platform, was moving from more of an AMI baking style of platform to container, so a net new migration, whereas Segment was containers from day one. And so whatever migration we would do subsequently from ECS to EKS in our example, that was a lot less of a lift than moving to containers, learning containers from scratch, and then modernizing the apps and things like that.
So yeah, like I said, just knowing that it’s going to be a multi-year and it’s going to be a bit zig-zaggy, that’s the most critical thing because folks inherently, they want to know what to go build and how to do it. But I think you’ve got to be iterative, you’ve got to get the feedback from users, that’s one of the most important things, and just iterate as you go.
Laura: Yeah, and how are you figuring out what to do first, or how did you decide where to start on an area that is so vast?
Jesse: Yeah, it’s not any one place, for sure, and I think that makes it inherently difficult too. Right? By the time you have, in the case of an enterprise company, you probably have tens if not hundreds of folks working on this stuff so they all have their individual domains or capabilities. And it’s non-linear, right? You can’t just start in one place and then the next, and then the next, so you’ve got to coordinate the different folks and what they’re building into the cohesive story. Right?
So in Segment’s case, when we were building that platform, we knew we wanted to move to EKS. Actually, the first thing we knew is that we didn’t want to manage two platforms. So we had ECS already in the US, we were moving to the EU for data residency and we wanted EKS, but we didn’t want to run two. Right? And so we created a path where we would put EKS in the EU first and then loop back to the US and do that migration, and so that was a strategy. And so that gave us the iterative approach, okay, what do we need to make that possible? Okay, we need different deploy tooling because the deploy tooling we had was very specific for ECS. And so you just work through that process of, what do you need to make the thing true?
The hard part that I think we’ll probably talk about more is that loop back, that migration, because you’ve got ECS running in our case and it’s fine. Right? It’s totally, the developers think there’s nothing wrong with it, and they’re right. And so you either have to build high, high, high ROI for them to go through that migration, or you’ve got to facilitate more of it for them. And that’s always, I think the classic push and pull for platform.
Laura: Yeah. If we were to look at all the different use cases and all the different things that developers need to do, are you kind of taking the approach of, take one thing, for example, like image creation and registry as a subset of things, and totally going all in and fixing that until it’s great and consolidating it. Everyone’s on the same registry, everyone has the same backup registry, whatever. Or are you thinking about it more from let’s take these three different services and really reinvent their platform experience. Doing it from start to finish for a subset of people, or are you thinking about cross-cutting things that touch every single developer? What’s the strategy there? It’s kind of like the snowball versus avalanche kind of approach, if you know what I mean.
Jesse: Yeah, and as I’m going to say it’s like I don’t know if it’s the best strategy, but it’s the one we’re picking right now and we’ll see how it works out, but a little of both. So again, we’ve got the teams of folks that produce their capabilities. Right? So in my case, leading developer platform, I’ve got folks focused on secure supply chain as one kind of domain, which is like CI and everything around the image registries and things like that that you mentioned. I’ve got folks focused on deployment orchestration and another team focused on developer experience.
And so, the secure supply chain team is a great example where today we have as many CI pipelines as we do repositories. There’s been a lot of copy and pasting, they’re all bespoke, and so we don’t have that leverage as a platform of having the few golden path CI pipelines. And so where I say it’s a little of both is yes, we’ve got to figure out how to take all the bespoke pipelines and eventually kind of migrate or merge them into standards, but we also have kind of a corner where there are new services being built. And we’re starting with those folks to say okay, let’s say Java HTTP services, what’s the pipeline? Where as we carve out new, they just get started with the new golden pipeline and they’re not copy pasting.
So that’s that little of both. Strategically, it serves as a great kind of feedback loop. We’re doing this kind of green field with developers and we can get their user feedback and things like that, but you’ve got to come back to the, I don’t know how widely this is used, but brownfield remediation, where you’ve got to come back and-
Laura: Yeah, I use that term. Don’t worry.
Jesse: Yeah, and still go get user input and it’s shaped different. Like I said, those are the folks where they’re like, “Well, my CI is fine. Right? Why do I need to redo a pipeline?” And things like that, and so you’ve just got to explore both cases
Laura: Yeah. On that point, you, in previous conversations talked about this migration and adoption is just as much a human project as it is a technical project. Success of this is really depending on a lot of advocacy education showing real value early. Like you said, the thing they have is working fine and so it’s costing effort, time, and money for them to switch. So I mean, this is really, it’s a hard lesson to learn. I wonder if you wouldn’t mind sharing, how did you learn this lesson the hard way the first time?
Jesse: Yeah, I feel like I’ve had two. I mentioned earlier the SRE team that I led once upon a time and being the team on call. That was probably my first one, where it was like, hey, we want to get all of engineering on call, here’s why. And that’s a big lift, that’s a big ask, right? It’s working fine, the platform’s up and running, the whole company relies on you guys, keep doing it. And they weren’t wrong, but there’s a better way. And so that was a lot of advocacy and training and education and alignment with small companies. So it was all the way up to the CEO. That was right around the time of Accelerate, so I had the CEO read the book, things like that, but you have to go through that alignment.
And eventually we saw it take shape, and even once it was taking shape, it was still methodical. We weren’t like, okay, good, everybody agrees, boom. We started with a team and then another team, and then eventually there was a day where we had an all hands and we were like, okay, by the end of today, all of engineering is on call. So, that was my first one along these lines.
The current migration story, so to speak, or consolidation that we’re going through is definitely my second, where it’s just way bigger scale. Right? There’s multiple businesses generating millions of dollars of revenue that are on these platforms. And so to mess with them, so to speak, to consolidate them, to change them is a risky, risky business. But we know for a lot of reasons that it’s the right thing to do for developer toil, for developer efficiency, for reliability. Not that just migrating will make it more reliable, but by having less will make things more reliable. More of a leverage effect from platform. The leverage effect, which is essentially why platform exists, right? We aren’t not providing value unless we’re making the rest of engineering more efficient and more effective. So not just going faster but having better outcomes and things like that. Right?
So today, the big learning lesson has been really again, aligning with the highest level architects, the highest level VPs, so that they’re able to tell our story. So they’re able to tell the same story as, hey, why do we want to do this? Why is it important to them, not why is it important to Jesse? Because what’s important to Jesse, it feels like a mandate if it’s just coming that way. And mandates, we’ve tried, I’m sure every company has, they vary in success. They can vary, they can succeed a lot in companies that just have a massive accountability culture where it’s like, hey, we all agreed to do this so we’re going to do that, period. And even where there is high accountability but just other factors, you’ve got to have more of an ROI and a carrot, rather than just a stick.
And so doing that alignment, focusing on the user feedback, making sure that you’re solving user problems, right? I think platform has been an interesting evolution because I think a lot of platform teams came from infrastructure teams, or at least this has been my observation. Right? They come from infrastructure teams where the infrastructure team really does know what’s best for this infrastructure, how to run it, etc, and a lot of that is behind the scenes. But as we’ve moved to platform, it’s felt like we assume we know what’s best in what we’re going to build for the user, but you’ve moved into this product engineering space whether you know it or not. And so it’s not, if we build it, they’ll come, because they won’t.
Laura: Yeah. I think we have kind of the same observations there because, and I’m saying this as an infrastructure person myself, so if I’m throwing anyone under the bus, it’s me. But I think part of the appeal of working on infrastructure was there is no UI, I’m not working with “end users” and I think it attracted a lot of folks who were into that flavor of engineering. I can just sit in my AWS console all day and solve really challenging technical problems without necessarily having to be on the product side. And it felt like in the course of five years, platform engineering kind of took shape and surprise, all of those engineers who had gotten into infrastructure engineering and who are now in a platform role found themselves in this platform as a product kind of world where actually, you do have end users. And guess what? Now you’re also a product manager. I think that more than any role, it really expanded. There’s a lot of responsibility on a platform engineering team.
And I think we’ve talked about platform as a product a couple times on the podcast already, and Jesse, you take it a step further and you think about developer experience as a product. Can you talk a little bit about that? How do you think about developer experience as a first-class product that your teams are responsible for?
Jesse: Yeah, absolutely. I mean, so from the core, I think it’s a shared responsibility, and that’s another kind of term that we’re using a lot lately, coined off what Amazon has provided with their shared responsibility model, for example. I think developer experience is also a shared responsibility where it’ll always be the platform. Again, if the platform has leverage, the platform can always do something in these areas, but it really is up to the individual teams too. And platform needs to educate them on how to do that and why to do that and how they have local leverage.
So the first thing we do is surveys. Maybe that’s no surprise to anybody listening to this podcast, but kind of measuring developer experience. How is the day-to-day? I believe strongly, our leaders believe strongly that people will be more efficient, more productive when their developer experience is high. And so measuring all of that, doing what we can as a platform. I think of all the places we survey, if there’s 10 or 12 of them, I think there’s generally three or four of the platforms always responsible for it from a leverage standpoint. We can generally help with incident management procedures and the observability platform for debugging and things like that, but then there’s always the, you want on documentation. It’s like, okay, that’s a shared responsibility. We can do things about standardizing it and putting it all in one place, but teams have to then know the importance of spending time there.
And so, it starts with the measuring and then communicating the why and the impact. With that comes NPS, and we use that to drive a lot of the, what are we building? How is it going? And then we turn those into subsequent surveys where it’s like, hey, with the NPS dips on that thing, how do we go get it higher? We do more of the interviews with folks, things like that.
I think it also starts again, I mentioned, if you build it, they’ll come. I think the culture of shifting to platform as product is assuming that’s not true and having to have kind of like a PDLC. Right? We have to have a full product development lifecycle for platform where we’ve kind of said to folks that, “Literally don’t build something new unless you have a team that you’re alpha-ing with, for example, they’re going to be your alpha customer. And if one quarter, you can’t find that team, focus on tech debt, focus on paying down our toil and things like that, but you have to find that team. You have to go find the customer to iterate with. Otherwise, it’s not worth building yet.”
Laura: Absolutely, if you can’t find that team, that’s the signal that you shouldn’t build it.
Jesse: Yeah, yeah, exactly.
Laura: And I think that’s really difficult for technologists who love technology because that goes against, we might look at something and see, but I know this is technically the better solution and having to not do it because business-wise it’s not viable. That’s a real challenge personally, I think personally and organizationally.
Jesse: Yeah, and we talked a little bit about the personas too, right? Again, from infrastructure engineering standpoint, you do know what’s best, get going, go build the new thing. And we still need those folks, especially the specific systems engineers that the platform engineering book for example, talks about of like, hey, we need the network experts, we need the storage experts. But we also need the software engineers now as part of platform, that they just love writing code, they love talking to users, and they have that product mindset where they get just as jived about writing a PRD as they do writing a new code base, right?
Laura:Yep. Every team needs a tank, a healer, a damage dealer.
Jesse: a tank, a healer, a damage dealer, and someone who knows IP tables. A platform engineering team needs to be well-rounded with breadth and depth, 100%.
Jesse: Absolutely.
Laura: And so, that’s great.
Jesse: Totally.
Laura: I love how you frame it of platform engineering absorbing some pain and absorbing toil, and one of the things you said was a platform engineering team should sort of offer change as a service, absorb that migration complexity rather than the product teams, and just kind of like centralizing the pain in one point. Can you talk a little bit about what this looks like actually in practice? What does it mean to offer change as a service?
Jesse: Yeah, yeah. Change as a service or centralizing the cost of change, I think is one way we’re talking about it as well, because truly, I think it’s really easy for us as humans to be like, oh, we need you to run this migration. It’ll just take… and then some number, however we quantify it, right?
Jesse: Whether it’s a couple hours or oh, it’s an afternoon, but we’ve all seen the graphs.
Laura: It’s a lot of money.
Jesse: Yeah, exactly. So it’s like you get interrupted and even if it’s an afternoon, it’s a day. Right? So let’s just do the basic math of, it’s a day. And most enterprise companies, they have over 1,000 services, maybe some have thousands, and so think about that actual cost of the change, where if every service has got to go do a thing, it’s money at the end of the day. Right? And we’re, more importantly from a platform values perspective, you’re not providing that true leverage that platform needs to be. You provide more leverage as you make that easier. So if the migration used to take a day but now it takes a few hours, okay, cool, that’s more leverage.
But I think a place for us to strive for, and I know this is hard and some people will say not possible, but a place to strive for that I’ve been communicating is if we show up with the pull request and some confidence metric with it, let’s get to a place where the pull request does the change and it’s 100% confident. Now, there’s a lot that has to be true for that to be true, right? And today, if we did that, admittedly in a lot of cases we’d show up with the PR and the confidence would be zero, but what has to be true to get that to 100, we need maybe standardized tests. We need them, the product engineers to use a standardized test framework. We have to have a standardized test framework. Things about the application need to be true where they can move between environments and we change their config through maybe 12 factor standards.
So, all sorts of stuff needs to be true, but it’s that journey, it’s that path to, imagine a world where we all agreed up front, hey, platform’s going to tackle this migration, we all agree it’s important. We show up with the change and a high confidence factor, and then imagine the world where the change doesn’t get merged. That’s such a wildly useful conversation, where it used to not get merged because it was just a stick and it’s like, I don’t want to deal with this right now, I got to go test it and stuff like that. I agree, that’s a lot of work. But if we show up and say, “We’ve already tested your tests, we’ve tested our tests, we’ve run the thing, we saw it work, your metrics are all lining up, blah, blah, blah.”
Laura: Here it is in an ephemeral preview environment.
Jesse: Yeah, and this accomplishes the thing that we already all agreed is super important, could you merge it? Or eventually, maybe if we get to the place where it’s 100% confident, we merge it, right? And then again, it’s assuming we can roll it back and all that stuff. So all the things are really great, but without that platform is just inherently not being leverage. Right? I think both here and at other companies, I’ve been in the place where we say, “Hey, we’re moving to Kubernetes,” and that kind of looks like, “Hey, here’s the latitude and longitude. We’ll see you there, get there.” But you’ve got to provide those on-ramps and the smoothest possible grease tracks that people are just riding on to get there, rather than just like, “Hey, meet me at a destination that you didn’t ask for.”
Laura: Yeah. I think on that second point that you didn’t ask for, I want to just talk a little bit about… I mean, adoption and mandates we spoke about before, and mandates leave a bad taste in people’s mouths.
Jesse: Yeah, absolutely.
Laura: And I think especially in Twilio’s context, you’re bringing together three or three plus really strong independent engineering cultures that existed before. It’s not like we’re just expanding the one engineering culture, we’re trying to consolidate and defrag some strong engineering cultures before, and so mandates are just not really effective there. I guess, what have you learned in your mandate-less world about creating an involuntary adoption? Not just saying, “Meet me there, and you’ve got to be there, otherwise stick, stick, stick,” but making it so that the carrots pave the path to that latitude and longitude.
Jesse: I think at the end of the day, good engineers want to be best in class, and then good engineers on teams become good teams, and those teams want to all do the right thing. It’s, is platform truly enabling them to do the right thing at the right time? And so, one idea that I think has gained some traction in the industry is scorecarding, or I just refer to them as checks kind of thing. That’s a way to go about this, where you provide the kind of contextual information to the right teams at the right times.
So, imagine they log into their dashboard or whatever and see, oh, the service quality here went down a little bit. How come? Oh, because the service quality bar raised. Okay, that’s interesting, onto my backlog, into our process, etc. So that’s kind of a future world where I think as people see those right things to do, whether it’s an immediate one where, oh, I’m actually not going to be able to deploy this afternoon because that thing has a critical vulnerability now and we don’t release those. Okay, let me fix that now, that’s an on-call task. Versus I don’t know, oh, there’s a new version of a library that’s 20% more efficient in CPU, something like that, right? That’s not a right now, but it’s like, oh, we should plan for that. The platform gave me that signal that I could get better, I could do something more efficient. So, that’s one way we want this to show up.
Now, it’s interesting because there still will be, what we want to do there is there’s lots of care, there’s lots of incentive to do the right thing. It’s easy to make the analogy like bronze, silver, gold, for example. Everybody wants a gold service, but there will also still be stick and I think that’s important because platform needs to also play this role of protecting the infrastructure, protecting the business, protecting the software that’s getting deployed safely. And so when some of those checks or those metrics are out of whack, maybe you don’t deploy, maybe you have to have certain levels of approval to deploy.
So it’s like, but it’s still inherently pushing, do the right thing at all the right times. Right? And so to me, that’s where it’s back to that partnership. Again, all of that doesn’t, what needs to be true for all that to take place, we’ve got to build the relationships with folks where there’s a high trust in platform, that we’re doing the right thing. We’re not just slowing them down to slow them down. We’re not saying, “Hey, you can’t deploy because we’re mean.” We’re saying, “Hey, you can’t deploy because the service has dipped in quality in these ways that are important to us, that protect our customers.” Things like that.
Laura: Yeah, that we’ve all agreed on, right?
Jesse: Yeah.
Jesse: And to me too, that’s super interesting leverage because that’s kind of this ongoing, we’re not building anything net new there. We might be adding checks over time or measuring different things, but you’re actually not even delivering new services continuously. You’re kind of just continuously improving how much is being informed to the user, the product developer. So, that area of kind of contextual information is super interesting to me to build over time.
Laura: Yeah. One thing that we find to be really effective in getting voluntary adoption is showing real value, and you mentioned that, showing real value early. And I’m wondering about, what are some of the ways that you are actually showing that value, aside from the experience being delightful, but are you sharing metrics? Are you sharing dashboards that are showing like, hey, look, no, really, this will make your life easier. It’s important to the business and we have the numbers to prove it?
Jesse: Yeah, yeah, absolutely. I mean, again, this is in a couple of different areas. So even the part I was just mentioning about, we want this information to show up at the most granular levels, either at the team or the service specifically, but we also have kind of an engineering reviews where those same metrics are aggregated up a bit more to, let’s say the VP. And that’s kind of our ability to talk about, again, a lot of what I said earlier where it’s like, hey, we agreed this thing is important, for example, to get from A to B. And VP, your name is next to this bar and we still have room to go, we still want to drive that migration on your team.
So we’re having those conversations on a fairly recurring basis of the team’s doing the work, but here’s how it’s going at the high level and how to get their top-down alignment. Again, it’s not us coming in sideways and being like, “Hey, teams, you have to go do this.” It’s working with the leaders so that the leaders say, “Hey, this is important to us,” and drive that kind of downward.
The same is true for back to how we measure developer experience. People aren’t taking the survey because Jesse said. People are taking the survey because their leader thinks it’s important, their leader is having the retrospective kind of triage discussion about, what are we going to improve this quarter? And so I’ve always said that really platform needs to come top-down in the respective organizations. We’ll build and drive that leverage but the adoption of it, I think going forward is an aligned drive.
Laura: So Jesse, one fun fact about the two of us is that we actually came up, sort of blossomed in our infrastructure career side by side each other, and we’ve been both really deep into the container ecosystem since day one, day two. And so, Kubernetes is a natural choice for a lot of companies operating at the scale of Twilio. You mentioned though, that getting people to get to that destination hasn’t been straightforward, and also the ROI on the business side hasn’t been what you would’ve hoped. And that might be a little bit controversial for people that are so deep into the container world, but you’re not the first person or even the fifth person to share organizationally, it’s just been a little bit more friction than you expected. I wonder if you could just share a little bit about what that journey has looked like for you.
Jesse: Yeah, absolutely. I always tell people being that early in the journey, I’ll never forget this blog post I came across at one point and at the top it had its hero image. And it was a tiny toy shipping container strapped to the back of an 18-wheeler flatbed. Right? And that always sticks in my head and honestly, I think even the blog post was essentially how to run your blog on Kubernetes, and it’s like that is a thing you could do.
Laura: Do we need that?
Jesse: Right.
Laura: That is a thing you could do.
Jesse: That’s a thing you could do, but it’s not that simple, right? And at the time, that’s where the industry was. The industry was talking about, hey, here’s how you run your really simple Ruby on Rails app, or here’s how you write your Django app and run it on Kubernetes, and we just didn’t need it, and it wasn’t the full story. Right? It wasn’t a, what about the observability? What about the patterns of building your application the right way? Things like that. And so, I essentially think we’ve rode the whole curve at this point. We’ve gone up and we’re coming back down. And in the case of Twilio’s business, it’s just like there are things that don’t fit the pattern. Right? We do telephony and there’s this SIP protocol, and can you do it? Yes. Is it a good experience? No.
Laura: No.
Jesse: And so it’s not the important thing. Again, if you build it, will they come? And that’s a path that I think we’ve learned where it’s like, hey, we’re going to get everything into containers. And then at one point we said, no, we’re not, and it’s just that simple. So now, it doesn’t mean that we’re not going to still modernize from where we were to where we want to go, those applications. A truth about Twilio is that we started right at the time where AWS was in its infancy and we have internal solutions for the fact that certain load balancers didn’t even exist in Amazon and so we built them ourselves. And so those are an example where we should modernize. We should get on things like auto-scaling groups for some applications and things like that, and so that’s the modernization we’re focused on, not just Kubernetes.
There’s still lots of advantages like we know, of containers. If containers are the artifact we produce, you could still run containers on EC2 with simpler networking and things like that. The important part for platform and the modernization and consolidation story becomes, what’s the consolidated user experience, right? Historically and especially bringing multiple platforms together in an enterprise scale, it’s likely that every platform has its own user experience. And honestly, coming from the infrastructure engineering space, what we find is it’s also likely that every team in a platform organization is delivering its own user experience. And so you don’t even have a platform user experience, you have as many teams as the platform team has. So, that’s the important thing.
And then the way we talk about it and that I think I would encourage most people to talk about it as, is you want that consolidated UX, and then where you deploy to is just an array of deploy targets. Right? So as consolidated as you can be, so just where’s the application going to run? But there’s just a lot of truth in, yeah, again, Kubernetes, as much as it provides, a lot of other technology provides that to whether it’s self-healing or auto restarts or whatever, but it’s just not the answer to every question. And so, yeah.
Laura: Yeah. And so, if you’re listening to this feeling pressure, Jesse gave you permission, you don’t need to [inaudible 00:43:20] Kubernetes.
Jesse: Honestly, I wish I would’ve given myself and a lot of other people permission way sooner, right? It’s a super valuable tool, but so are a lot of others, and so it’s just picking the right tool for the right job. And we as engineers know that too, and I still sometimes think we ignore that advice.
Laura: I think I really appreciate your pragmatism, and I also like how you highlight that we have to think at the right altitude level about where we want our standardization. Maybe Kubernetes isn’t the level that we want our standardization. It should just be that every service has a Dockerfile, and when that happens, when every service has a Dockerfile, you already unlock a lot of capability that feels standard enough. But maybe we don’t have to take it further, because as you said, there’s whole ecosystems of tools that existed, that have existed for before Kubernetes existed or before Kubernetes had extreme market share, that work just fine. As you said, coming back full circle to this business mindset platform as a product, we need to be solving real problems, and perhaps the right way, the most efficient way to solve it is not by mandating up one platform or one illustration or another.
Jesse: You touched on something there that I think we’re also thinking about this notion of kind of revealing complexity the further right in the process you go. So further left in the process, maybe in the developer platform space where it’s like, hey, everything up to building a container image, standard, one road, no off ramps, lots of leverage can come there by having all the security, compliance, attestation, etc. Here’s the road, period. But as you deploy, there’s probably a double-digit of percent, probably a majority double-digit of percentages that yeah, they could just provide you the Dockerfile.
Laura: That’s all.
Jesse: Contract written, go run it, right? This is why Heroku is great, for example. And then there’s a level up of complexity. Maybe you’re a tier zero kind of service, you’re internet facing, your scale’s a bit higher. You need the engineers also to know and understand that complexity, whereas something like an internal tool, it’s like, yeah, here’s my Docker file, go run it. But something internet facing, you’re going to need the engineers to go a little further, and so we unveil the complexity, they have more knobs to turn. So that’s another thing we’re thinking again from this product mindset where, what’s the majority use case? How do you solve for the 80%, right? And so that’s something we’ll be exploring over the next couple of years, for sure.
Laura: Yeah, I think running your blog on Kubernetes is definitely, as you said, it’s a choice.
Jesse: It’s a thing you can do.
Laura: It’s a thing you can do. When I think about the day-to-day experience of a software developer working on a product team, I don’t want them to have to care about whether Kubernetes is powering whatever production environment that they’re deploying to.
Jesse: Right, yep.
Laura: And so, I think that’s one thing that we’ve struggled with as an industry. I think everyone wants to work on cool, shiny, intricate stuff that’s difficult to understand. And I think now, we’re seeing resurgence of developer experience meaning, let’s hide complexity when we can, and as you said, give more knobs to turn when those knobs need to be turned, but I like that pragmatism.
I’m also curious, so you and I both lived through and probably contributed to a lot of the Kubernetes hype and guilty, 100%. I will totally own to that. And I mean, we’re in the middle of another hype cycle around AI, and I just want your take as being someone also of a certain vintage having lived through both the Kubernetes hype cycle and now this AI hype cycle. What feels the same to you, what feels really different to you?
Jesse: Yeah, it’s interesting. I really clearly remember in the Kubernetes hype cycle almost feeling oversubscribed. I would get all the newsletters and be reading all the blogs, and I knew at the time there was still this signal-to-noise ratio that you almost had to comb through it to find the signal, obviously. And maybe it was a, I don’t know, a one in 20 hit rate, where it’s like, okay, here’s the useful blog out of the 19 that weren’t. So for me, that hype cycle, I guess I was able to identify it in the moment.
I’m not there with AI, I feel under subscribed. And I think that’s because we’re even seeing with benchmarking data and things like that, capabilities are doubling every seven months or something like that with AI. And I think the way we’re going about it now is that we really need a group of folks that are focused on experimenting at all times with the latest work, and then crafting our own internal benchmarks and things like that to evaluate new tools. We’ve used Copilot for a long time and now we’re experimenting with Claude Code, and that took a while to build up to, but as we evaluate Claude Code, we have things to test it against. What were people doing with Copilot, etc, and is it going to be the right tool for us? And we don’t know yet. But yeah, that part of it does feel different.
I think culturally too, it maybe shows up a little different. With Kubernetes for example, it was a thing that we posed like, okay, everybody’s got to learn this, it’s going to be the new thing, you’re going to be interacting with it on the terminal. With AI, we’re not telling everybody to go build LLMs. Instead, they’re using the LLMs and it’s a little bit more of an art than a science. Right? And so this one’s interesting because not every engineer is effective with AI out of the gate. I actually, I think something you and Abi have said was enabling people with AI is not just handing them a Copilot license.
Laura: 100%.
Jesse: And that stuck with me. I brought that back to every meeting for the subsequent two weeks after hearing that because it’s so true that I think that’s a shape that it’s shown up as so far in the industry where it’s just like, well just use these tools and just go be good. And it’s like that’s not it.
It’s one thing to prompt engineer, it’s another thing to use it to write code and write actual applications and speed up your work. And so, this is another area where for us, platform has to have leverage. Platform has to play a role there in educating people, enabling people. Everything from what’s safe to use and how do you not disclose company IP, but also just the right ways to go about it. Again, it’s a bit more of an art, and so some of the more recent patterns are spending time writing the PRD, for example. And so A, new to some product engineers. And B, definitely new to a lot of platform engineers, but there’s really proven patterns lately of, well, if you just described the thing you’re trying to build in really good detail, then the AI will behave really well.
And then the last piece that I think we know and we’ve seen definitely show up in people’s sentiment is it moves a lot of the work to obviously reviewing code, rather than writing new code. And that’s maybe different muscles than people are used to or the volume of that review is certainly different than what they’re typically used to, and so it’s definitely going to change the way we work. But back to the hype cycle, it feels different, this one, maybe it’s, we’re not hindsight yet, but it feels different.
Laura: Yeah. One thing I do notice when I reflect on that sort of if you don’t move to Kubernetes, your business will be dead in six months, kind of looming over us. But I can’t remember, I don’t have a good example of any of us actually measuring how moving to Kubernetes was helping our business. It was more just like binary, you have to do this or you can’t, or you want people to operate in public cloud. I feel like the threat was so, so distinct and it was, as you said, it’s one tool and it was like, use it or don’t, and it’s just the sprawl of use cases and different ways to use AI, it’s so vast. It does feel looming and important, but I think we have a better sense of understanding productivity and performance these days now in 2025, then we did back in 20, what was it, 14? And so I think just the nature of how we’re designing the experiments to see where it works and where it doesn’t, I think we just have a lot more education in our thinking about it, more methodical. It could also be that I’m a decade further into my career. No,
Jesse: No, There’s definitely something there.
Laura: I think it’s also that, yeah.
Jesse: I feel like you’re touching on a non-obvious even developer experience lens there, where with Kubernetes, we weren’t necessarily upleveling the work that engineers were going to do, and I think that’s kind of the inherent promise we’re chasing with AI, right? Is like you’re going to do a lot less of the mundane and you’re going to do a lot higher level work. And with Kubernetes, it wasn’t that. It was much more of a lateral move of, you’re still going to infrastructure, you’re still going to have apps crashing and restarting, you’re still going to have to do all these things, it’s just a different way to do it. And so, maybe the APIs of Kubernetes, I’m thinking about using kubectl. It’s like it’s sure, it’s a lot more conversational than running a chef converge, but it didn’t have us doing higher level work. I don’t think. So that part of it’s definitely different from a developer experience standpoint.
Laura: Did we even have the words developer experience back in 2014? Not really.
Jesse: No, I think especially-
Laura: I think we were just thinking about this in a really different way.
Jesse: Yeah, I think back then, even I probably used to equate it, there just seemed to be this double equal sign with user experience. So people just immediately thought about UI and the color of buttons and web design, but I think people didn’t have the language to talk about, no, how do you go to work as a software engineer in your job be measurably more enjoyable than it was a quarter ago?
Laura: Yeah. I think one kind of the arc that we’re on is back in the '90s, all we had was manuals and docs, and then at some point we started working with good command line utilities. And the CLI design actually became part of the developer experience, and we realized, okay, maybe it’s not just docs. Maybe you have to actually design some of these things with the UX in mind. And now in the AI world, I think the way in which developers learn how to use your tool or even implement your tool, both of them, are drastically changed because now no one’s looking at a YouTube tutorial. We’re just going to Claude and saying, “Hey, I need to do whatever,” and we’re getting feedback from our AI tools to help us, and that’s part of the developer experience as well.
I wonder, to close off this AI discussion, how are you thinking about AI in terms of migration, in terms within your platform? How are you using it to accelerate some of these things that are obviously high priority but have such huge surface area for you?
Jesse: Yeah. I think it really culminates back on a lot of the areas I’ve touched on so far, where again so it’s, we’re not doing it for just old stuff or just new stuff. We’re doing it for both, in teams that are working on newer greenfield services, exploring kind of a new way to run their services, but we’re also exploring new ways to even do that on our side. Ironically, AI is really, really good at infrastructure engineering, because it’s just config based, right? There’s tons of APIs, here’s the API docs, write the YAML file, boom.
Jesse: I think AI will play a big role in centralizing the cost of change, like we talked about. Right? At the end of the day, there are millions of lines of code at an enterprise company that need to be modernized over time. And again, back to that cost where it’s like, even if we give people really clear just instruction back to the manual, that’s a high cost to go refactor that app that way to make it marginally more 12 factor or marginally more cloud native. And so, I want to be grounded in reality, I don’t want people to hear, oh, we’re just going to let Claude loose and it’s going to rewrite all of Twilio. That’s not the case.
Laura: Just vibe code.
Jesse:But I think with tools like open rewrite and things like that, AI will play a big part in enabling us to do the modernization we’ve been trying to do in the areas where it’s needed most. And in the areas where we’re innovating, it’ll enable us to go faster and further with better UX.
Laura: one thing that I think is interesting right now is like AI has a lot of curiosity. It’s like frontier kind of work and so we need experimentation. But then on the other side, we need some kind of standardization. And I’m wondering how you and Twilio kind of view both of those sides. Where are you keeping room open to experiment with AI?
Jesse: Yeah. So I think we might’ve touched in a previous conversation around you had this anecdote in one of the DX calls about handing people Copilot license isn’t enablement, right?
Laura: It’s not enough.
Jesse: It’s a piece of the puzzle, but it’s still a large way to go. And I think we see these … like you mentioned these pioneers where it’s people are truly interested in trying it on every single one of their tasks, perhaps. But some people aren’t, and that’s okay too. They need the space to learn and learning feels different and looks different for everybody who’s going through it.
So I think our approach is on the standardization versus experimentation that you mentioned. We’ve got a couple of different pieces in place. One, we’re an enterprise company, so for procuring new tools and things like that, we have architecture review boards. We do put things through some amount of scrutiny, especially if we’re going to go spend lots of money to enable all of R&D kind of thing. And so that’s proved kind of even more useful with the array of AI tools. Because they’re all very similar, they do roughly the same things, but who’s got the best model, etc. So we don’t want to go out and get Copilot and Cursor and Windsurf and Claude. We want to figure out what we’re using, how we’re using it, how we’re going to measure its success.
So those have been serving their purpose there. I actually chatted with a board yesterday about a tool I want, for example, and they’re like, “We’re already doing agentic stuff.” And I’m like, “No, no, this is slightly different. Here’s how.” And they’re like, “Yeah, we get it.” “Okay, cool. Let’s go forward.” So it’s super useful for that because there’s not a great way to subscribe to what every single person’s doing. And so you’ve got to have these pinch points.
The other thing in just day-to-day, I guess like innovation is where we have those pockets of innovation, so to speak, where people are building Greenfield. On some of those new projects we’re starting them off with, okay, here’s Claude Code. I know you haven’t used it before, but the engineering leader that’s leading that team is one of those pioneers. And so we’ve got him enabling that small group, working in a really tight loop. They’re able to share what’s working for them. Like, hey, literally look, I left the prompt open-ended and here’s how it responded. Or I wrote this PRD this way for the agent and it took it in. And so that kind of accelerates the lab, so to speak. And then from there we can share tips and tricks.
Laura: Do you think prompts … or are you checking prompts into source control?
Jesse: That’s a great question. Not yet, maybe, would be my answer. I think we’ve definitely talked about it, but I don’t think we’ve built up the muscle. We have this saying probably more recently this year as platform is starting a lot of the migrations and modernization that we talked about. Twilio has guilds. So we have a Java language guild because there’s a lot of Java and we have a Go language guild and things like that. But maybe a hot take that we said earlier this year was like, guilds exist because platform isn’t doing enough.
Laura: That is a hot take.
Jesse: And so in the future, do guilds go away? The nice version of go away because platform builds up the Java expertise, builds up the Go expertise. And so just recently somebody on my team started a DevEx AI guild. People want to be having this conversation, they want to be saying, why aren’t we using Claude? Or why are we comparing and having the conversations and sharing spicy news articles about 50% of code at Google being written in the AI or whatever it is… so now we’ve got this AI DevEx guild, and it took one name-drop out an all hands and 400 people join the channel. So the other guilds are healthy, 30, 40, maybe 50. And this one was all of a sudden hundreds. And so that’s another great example actually of … well, in the future, platforms should probably be doing more and this guild probably shouldn’t exist. But for now, it’s great, right?
Laura: Yeah. How do you see that in the future like platform standardizing, evangelizing AI use across the company? We’ve talked about platform being centralizing the cost for change and centralizing the cost for a lot of things. How does platform centralize knowledge, practice, standards for AI use?
Jesse: Yeah, I’ve got a couple of dreams in that space. I think for years now, I’ve been basing a lot of my vision and direction off of like a really solid taxonomy. I think this comes from backstage in the IDP space where if we can get the taxonomy right and maybe attach a little bit more metadata to things, especially getting the hierarchy of the organization in there as this pillar of taxonomy, there’s just so much you can do.
And we’ve experimented a few times with getting some of that information into the IDE. So imagine a Twilio VS code plugin that if we’re running a series of these migrations, for example, one of the biggest burdens to teams is, oh, they got to check their email. What migrations are going on? Does it apply to me? But what if contextually, we could only show you what applied to you? So you’re only ever kind of burdened with the information that you actually need. And it’s the opposite, which I think a lot of teams have now, especially kind in the remote world of, well, I need to find what information is relevant to me. How do I subscribe to all the information that’s out there?
Laura: Pull versus push.
Jesse: Yeah, exactly. And like I literally just want-
Laura: Hyperfocus.
Jesse: I want to subscribe to these topics kind of thing. And okay, here’s my newsfeed for my team or for this service or for this domain. So that’s one piece on the modernization, DevEx, kind of quality of life that I think we can achieve.
Somewhere in there too, if we can get all the way to the IDE. I mean a big focus on the inner loop, that’s not new to platform. Maybe this is a hot take. I don’t know a lot of platform teams that are spending a lot of time in the inner loop. I think they start once code leaves the laptop. And how much more could we do if things were more standard on the laptop and we spent more time developing for the IDE or developing things like Claude code? That’s such an interesting project that like look how leverageable and it’s a CLI at the end of … or a REPL at the end of the day. Yeah, I think all that, like moving further left, getting people contextually the information they need when they need it.
And then on standards, I think standards will continue to evolve, obviously. Back to my bit about the ARBs and stuff like that, we kind of control what we’re using. We do some interesting stuff now where even instead of using some of the LLMs directly, we go through AWS Bedrock, that makes us feel a lot safer. It gives us the ability to experiment with other LLMs through Bedrock and stuff like that. And so we’ve got that level of standardization, but we’re not doing like, oh, we mandate you to use AI in these ways, this amount, blah, blah, blah. That’s still progressing. And again goes back to the enablement we talked about earlier of we’ve got to enable folks before we have any kind of capital expectation.
Laura: I wonder if you would mind going back to something you said about like there’s just an explosion of tools. There’s so many of them and then some of them are becoming commoditized. It used to be a big deal about which model you were able to use. And now tools can use different models, and that’s just a normal part of it. But nonetheless, we still have Claude code and Cursor and Windsurf and Copilot and all of these tools. And Twilio is a big company that wants some kind of standardization, like vendor consolidation. Maybe not just one tool, but maybe at least a small handful and not a whole ocean full. What are some of the things that you look for when you’re doing an evaluation to see whether or not that tool is fit for purpose for Twilio and the use cases of your developers?
Jesse: That’s a great question. I think one thing … I think I’ve definitely seen this show up mostly at Twilio, and I think it’s because of our … in my career at least, and because of our scale. But I think it’s a general enough problem, as well, where we have issues when vendors get to a point where … or maybe we get to a point in the relationship with vendors where the cost is based on scale, when the cost is consumption based.
Because normally it’s honestly promoting wrong behaviors. If you’re going to charge me every time I apply Terraform or you’re going to charge me every time I enforce a policy or something like that, what I’m supposed to apply Terraform less often? It just doesn’t … it’s antithetical. We want to be going faster, we want to do more. I don’t want the size of my fleet limited by anybody. And there’s just a lot of pricing models that do that. Even monitoring platforms, they’ll charge you at some point by the number of metrics you have. And it’s like, okay, I’ll monitor less. So that’s probably our biggest that we look for. We’d rather build the partnership and do just a per seat and go deep on the features and the offerings and buy more of a platform than kind of be handcuffed by utilization.
Laura: Yeah, interesting.
Jesse: I think others, for us, there’s obviously a big, big reliability requirement that’s also not new for a lot of folks. But Twilio’s business is unique in that … or parts of Twilio’s business are unique. Of course, we’ve got Segment and SendGrid and those have their reliability challenges because of just massive scale. Like we mentioned the number of messages we send every year earlier. But if somebody gets an email five minutes late, that’s a different … that’s not really a big deal. If somebody … I mean, we don’t do this anymore. But the analogy, if you pick up a phone and there’s no dial tone, that’s Twilio’s business. And if there’s no dial tone, that’s a big deal. And so we say this often, dial tone, reliability. And so we’re infrastructure for other companies. And so anyone we rely on has to kind of be the same level of reliability, availability, etc.
Laura: Yeah, that’s like offering five nines when you’re cloud providers only offering three nines. It just can’t do that. It doesn’t work.
Jesse: Yeah, yeah. And of course, that’s a challenge we have in building for scale. And it’s not just three AZs sometimes, right? We have to build for that to compensate.
Laura: Are you using AI for any sort of predictive incident management or something … using it in some capacity to manage scale and prevent outages? Because I think that’s … I mean, you are in a business, as you said, dial tone availability, where it does matter. I think maybe this is an episode of Hot Takes, but a lot of my … one of my hot takes is for a lot of companies, as you said, if that email comes five seconds late or five minutes late, it’s not the end of the world. But you’ve got some pretty critical workloads running with Twilio, and so it really does matter. And so scaling, reliability, availability is, I think, an interesting domain area to apply AI. Has that been something you’re looking into?
Jesse: Yeah, I would say personally with my SRE hat back on, I’ve been historically pretty skeptical. All the vendors I’ve seen that are building an SRE agent or they’ve got the LLM solution to your incident where as soon as your paged, by the time you go to a computer, some bots already fixed it. I’m pretty skeptical in those areas, personally.
Laura: Rightfully so I think at this point, yeah.
Jesse: Yeah, I would say where we have applied it is things like anomaly detection and things like that for more stable metrics or metrics we would expect to be more stable. That might be more in the ML space. I’m not clear on the delineation here. But yeah, we’ve done stuff like that in the past. I wouldn’t say we’ve applied the latest kind of LLM patterns or RAG or anything like that yet.
Laura: I did vibe code something with Twilio the other week-
Jesse: Nice.
Laura: Because we have a text message, garbage pickup reminder. But only for our plastics, paper and regular garbage, but not for our organic garbage, and it’s really annoying. And so I was like, oh my God. I just was like, write me a little app that will send me a text message every time, a date on my account like trash pickup. It was great.
Jesse: That’s awesome.
Laura: I love it. Thank you.
Jesse: Yeah.
Laura: Thank you for that.
Jesse: I was just reading something about that the other day about how everything from burnt-out engineers to retired engineers or whatever, how they’re coming back because it’s just a new-
Laura: It’s joyful again.
Jesse: Yeah, it’s a new paradigm, yeah.
Laura: It’s fun, yeah. And you know what, if I get my organic trash pickup text message five minutes late, it’s not a big deal.
Jesse: Right. Yeah, exactly.
Laura: Certainly that’s not the majority of workloads on Twilio.
Jesse: Yeah, no, it’s been a really interesting, the reliability of Twilio has been an interesting … it’s a cultural thing, as well. Obviously we’ve thousands of engineers and they all have different backgrounds. And I’ve used this analogy with my peers or leadership. It’s one story of reliability if we’re building something like a recipe app. It’s super cached and there’s no lives on the line, et cetera. It’s another thing if we’re building a distributed system with trillions of events a month. And it’s another thing if that call gets dropped or that call doesn’t go through, an ambulance doesn’t show up. That’s the weight.
Laura: Jesse, I wanted to end on a question more about developer experience because a lot of folks who are listening right now are working on platform teams or focusing on developer experience with internal customers. And Twilio, for those that aren’t familiar, our people build stuff with Twilio. You send and receive 157 billion messages yearly. That’s totally crazy.
Jesse: I believe it. Yeah, especially with SendGrid, for sure.
Laura: Yeah, yeah. And so when you think about developer experience for external developers, for the actual paying customers of your product, I wonder what kind of lessons you could offer or what lessons there are to learn from a company like Twilio that has such a focus on external developer experience and how internal platform teams could bring those lessons in-house for their own internal customers.
Jesse: Absolutely, and it’s one I’ve been drawing a parallel to actually internally recently, because I think support, capital S support, should actually be a capability of the platform. So the same way that any paying customer with any business is either going to click the chat bubble in the bottom right of some web page or they’re going to call or whatever, as a paying customer, you expect that support.
Now, we actually talk internally, should we call users, customers, because they don’t pay us money? But if you do that analogy, I think a lot of people do, you want support to show up the same way. You want a consolidated experience where people go to a place to get help. You have really, really high-quality documentation where they can self-service as much as possible. And again, that’s another thing I’ve seen at multiple companies I’ve been at, where Slack almost enabled bad habits, maybe. It’s really good for helping your peers and learning new faces and getting connected with folks, which again is important. But we have these patterns where it’s like, help-some topic, and then you have these help channels. What that shows up as is this really, it’s the opposite. It’s this fragmented experience where there’s hundreds of places to go get help from either different teams or different capabilities that teams are building. What happens in a reorg, a different team. Right? It’s a mess.
And maybe this is another area where we look at AI to help consolidate with RAG or something like that, where it’s giving people the right answers at the right time. But I think my dream there would be a help channel in that analogy, where it’s, how you help get help from platform. And you could equate that to the chat bubble on somebody’s website. Right? There’s one entry point for chatting with platform. Maybe the computers talk back to you with our documentation links so it’s short-cutting folks, and then you can always escalate to a human. We’re not shutting that path down.
But I think back to the core of the answer is, treating support as a capability. How do you want to show up to your users on a day-to-day basis when there’s a gap in the documentation or the self-service models? But I think drawing that parallel to, what would you expect as a customer paying somebody money and how you get help when you need it? There’s also, how do you get help when you need it? You’re usually in a bad place. You’re like, man, I really need help. This is broken, I need to do a thing and I can’t. It’s an emotional state for anybody to be in, and then they got to go get help, and you don’t want that bar to be even higher. Continue down the rabbit hole, so.
Laura: Just like when if I’m a paying customer and there’s a production incident, I need to have an oh shit button. And as you said, chances are when people are really in a bind, they don’t want to be looking through 15 different help hyphen channels to figure out what it is, because they’re already in a bad place and they need that oh shit button as well.
Jesse: Yeah, exactly.
Laura: Good. That’s an interesting, I’ve actually never heard that expressed in that way of support as a capability because I think most teams, internal, external, see support as a cost. And we have an emphasis on trying to reduce support costs, which I think is still a good way to think about it. Right? We don’t want that to be the default. We want self-service, we want tools just to work, the golden path to be there and paved, but.
Jesse: Yeah, and it’s interesting because the way we’ve seen it show up too is this, it truly is a muscle you’ll have to focus on and build over time. Because the help channel, the anti pattern actually creates a lot of dopamine for folks. Right? You get these quick wins where somebody comes, they look for help, you give them help, and you move on with your day and you get to at the end of the day, maybe you’re like, oh, I helped 15 people. But the effect of that is usually not seeing the forest through the trees. You’re not seeing the themes of which… We recently had an example where somebody did take that step back. They kind of combed one of the help channels and they were like, oh, if you actually just automated these two things, support load would go down some double digit percentage.
Jesse: And it’s not like they’re ignoring it. Right, yeah. They weren’t ignoring it, they couldn’t see because they’re just in the day-to-day, so.
Laura: Yeah, they’re in builder mode and not product manager mode.
Jesse: Yep, absolutely.
Laura: Totally. Great. Well, thanks Jesse, for the lovely chat.
Jesse: Yeah, thank you.
Laura: Great to have you on.
Jesse: It was a great conversation. Appreciate it.