Simplifying & Revolutionizing APIs with Sagar Batchu, Co-Founder & CEO at Speakeasy

(Intro Narrator at 00:00:00) Today, we're talking to Sagar Batchu, co-founder and CEO at Speakeasy, about all the ways they're simplifying APIs. You're listening to Joel Beasley, Modern CTO.

(Joel Beasley at 00:00:17) I saw what you were doing with Speakeasy and APIs, and I was like, that's kind of neat. I was hoping you could tell me about exactly what that is that you're doing.

(Sagar Batchu at 00:00:26) Yeah. You know, maybe I should start actually with why I'm working on it. I've worked at a number of companies over the years and realized how much teams underestimate how hard it is to build a great API. You know, APIs are not new. They've been around for a long time, right? Decades at this point, kind of core to software engineering and modern products. Everything we use around us is built on APIs. Every time we book a flight online, it's a bunch of API calls to all these platforms. And I realized that there wasn't really a great de facto set of tools as a builder to go to. You know, if you're a UX designer, you go straight to Figma or Canva or one of these phenomenal platforms. For API builders, it's still the Wild West. It's a very unusual situation for something that's so widely adopted. So what we set out to do with Speakeasy is to create the de facto platform to help companies build, test, and distribute their APIs. We felt the hardest part of this API building process was actually getting the APIs out to your customers. Like, you spent all this time building it, but the adoption is kind of artificially constrained because of how hard it is to distribute the product to your end users. And, you know, this is a problem builders see in all kinds of industries, right? If you're building a consumer app, great. You built this awesome app. Now how do you get it into the hands of thousands, millions of users? That's a hard thing to do. In SaaS, similar problem. With APIs, it's often the biggest challenge is actually the usability. You know, putting an API out there is like establishing a contract with your users that says, I'm going to give you X, or you're going to ask for X, I'm going to give you Y reliably, in a performant way, you know, great uptime. But often, customers are left with very little information on how to actually build a product around your API, because that's when you get the real value out of it. It's not just getting some information out, but you stitch the API into your own product. It becomes kind of a core service you depend on. And so there's a long way of saying kind of, yeah, one of the main things that Speakeasy helps companies do is build, test, and distribute their API, make it really easy to actually get your users onboarded and using your API.

(Joel Beasley at 00:02:55) How long ago did you start the company?

(Sagar Batchu at 00:02:58) Just over two years.

(Joel Beasley at 00:03:00) And why? You looked in the marketplace. You saw things that were out there because there are some things that have been out there. Why did you decide that, okay, look, Postman's not going to cut it, this other thing's not going to cut it, I need to go build my own thing?

(Sagar Batchu at 00:03:13) Yeah. Good question. I think a couple different reasons. I noticed there was a lot of activity in the open source space, right? There have been open source projects that are quite popular, poorly maintained, but quite popular that help companies create really great, what we call SDKs from an API, and distribute those SDKs. But it's very much choose your own adventure kind of story. And so I felt that was a great basis to explore an enterprise offering. Like, that kind of, to me, was a really strong sign. There's thousands of companies out there relying on this thing that's poorly maintained. It solves a core pain point. It's got value. You know, people are clearly investing time and trying to stitch this thing together themselves. But, you know, whenever that happens, I think that opens up a really great case for a very solid, very well-built enterprise product.

(Joel Beasley at 00:04:12) So you saw that opportunity. And then how did you come up with the name?

(Sagar Batchu at 00:04:16) The name? You know, I was actually living in London at the time, and it was deep COVID. And one night, my roommate and I, we noticed a light outside our house and went over. It was our neighbor, and it turns out that he ran a little speakeasy. Obviously, it was COVID, so he wasn't running the place, but he, we formed a little COVID bubble with him. So we got access to the speakeasy just for the two of us, which is kind of a cool thing. And that was about when I was thinking about the company and, you know, ideating. That was the personal side of the story. The other side of the story is, you know, I just like the word speakeasy. I mean, APIs are how companies communicate with each other, and I just felt that was a nice play on words there.

(Joel Beasley at 00:05:02) That is a nice play on words. Was that the first speakeasy you had ever been to?

(Sagar Batchu at 00:05:06) No. I'd been to others, but that was the first one I ever lived next to, that's for sure.

(Joel Beasley at 00:05:12) I found out about them in my twenties. I traveled to San Francisco, actually. It was the first time I had ever. And we were there for some conference, and some of the older guys—I mean, they were like 40, I was probably 20, at least 21—they were like, hey, we're going to go to this thing, and we've got to get directions from this other guy who has the password and this other thing. And I was like, what do you guys do, like a scavenger hunt? And then we went to this back alley, and there was this bookcase. It was this whole ordeal. And I was like, there's going to be nobody here. And we get into the back area, and there are so many people there. And that was my very first speakeasy experience.

(Sagar Batchu at 00:05:52) Yeah. That's funny. Yeah. San Francisco does have a lot of them. And, you know, the other thing was I just wanted a name that was pretty lighthearted too. I think a lot of tech companies have serious names, and what we do, what we work on is deeply technical. We're in the weeds of code generation and API documents all day. I think it's nice to have a more lighthearted name.

(Joel Beasley at 00:06:17) So what's the problem? We have a lot of technical leaders. Some are still coding. Most are not. We have a lot of people that are managing tech teams. What type of pain are they experiencing that this might be a solution for?

(Sagar Batchu at 00:06:30) Yeah. Great question. So if you are building APIs at your company, either internally for internal users or externally for third parties and partners and customers, if you are experiencing pain around actually creating, updating, and distributing the API, so, very concretely, you know, someone in your company probably maintains something called an API specification, which is the document that says this is what your APIs are. And then from there, there are probably people or teams that take that API specification and create hand-rolled SDKs for your customers to use. And then someone else is involved in actually supporting those customers with any problems they run into. And that whole flow, that whole workflow is something we've seen a lot of teams struggle with in terms of staffing, maintaining, and then also ensuring that customers have a great kind of first touch experience. So what Speakeasy helps you do is it smooths over that workflow and solves this core pain point of as an end user of an API—so your customer—they can come to your website, your GitHub, immediately get a pre-written, very high quality SDK to actually integrate with the API out of the box. That saves them, you know, days, weeks of integration time, and it builds kind of a great developer community. It's the foundation for a great developer community and consistency across how everyone is using your product. So that's the day zero core pain point. There's a number of other things that we do, but that's kind of the core thing I would talk to all the leaders here for them to think about.

(Joel Beasley at 00:08:13) So let's talk about how it expresses in their actual day-to-day life. Is it getting tickets saying your API sucks? Is it the API team being way backlogged and not able to get, you know, 80% of their work as fixes? Like, what is the actual experience that this technical leader is having that might say, hey, our API sucks, and we might need to do this better?

(Sagar Batchu at 00:08:37) Totally. I think it's a great framing. I think there's a top line impact, which is exactly what you said, you know, customers filing tickets, support saying customers are churning off the API or struggling to integrate, taking too long. You know, an API is supposed to give a developer superpowers, but if it takes them weeks and months to integrate, then that hasn't really achieved the vision. So that's, you know, one thing for them to consider about just constrained, artificial constraint adoption of the product. The bottom line is the time it takes their engineering teams to go from building the API to actually having it be usable for the customer. So raw engineering hours to take an API specification, build out SDKs, build out tests, build out all the tooling you need to actually ensure that users have a quality experience.

(Joel Beasley at 00:09:30) How long have you been writing code for?

(Sagar Batchu at 00:09:33) Just about a decade.

(Joel Beasley at 00:09:35) Okay. What was the first API where you were like, whoa, this is so good, it's so much better than anything I've ever experienced? What was that first API for you?

(Sagar Batchu at 00:09:46) Yeah. Good question. I think the first API was GitHub's API. I used those to build a product. It was not even a product. It was like a tool at one of the companies that I worked at, and it was fantastic. Just so well documented, great SDK. The time, what I like to call time to 200, right? Time to go from—

(Joel Beasley at 00:10:12) Ah, I get that. Yeah.

(Sagar Batchu at 00:10:14) Nothing to your first successful call. And I don't mean that in Postman or the ad hoc way. Like, that's always easier to do. Like, you just send off a request, you get something back. But time to 200 in your first application was measured, I felt, under an hour, right? And that was just a phenomenal feeling, you know, especially as a junior developer coming to the industry. You're like, oh my God, I can tell my team the app is working, right? Like, this thing is giving me successful data back. So I think GitHub was the first one. And then there's a couple others that have stood out over the years, like Stripe. Of course, Stripe is so far—

(Joel Beasley at 00:10:51) That's my answer. That's mine. That's my answer. You took my answer from me. Yes.

(Sagar Batchu at 00:10:55) A lot of people agree it's Stripe. Yeah. Twilio. Twilio is another one. There's quite a few out there, actually. I often look at the API top 100 list. It's a list that I think some VCs set up a couple years ago, but it's basically top 100 APIs by usage. And they generally have, yeah, good developer experience. Not across the board. You know, I don't want to throw anyone under the bus here.

(Joel Beasley at 00:11:21) Oh, we're going to throw people under the bus in a second. That's the next part of this conversation. Alright. So my answer on best first APIs—you went with GitHub. My answer is Stripe. When I came across Stripe, I'd never seen anything like it. It was unbelievable. Now worst API product that you've ever had to integrate with. Do you want me to go first?

(Sagar Batchu at 00:11:41) Yeah, you first.

(Joel Beasley at 00:11:41) Okay. Me first. My it was called Authorize.net. It was before Stripe, and it was the worst API. Like, it would take you months to build against it. And even though there was abstractions in Ruby to help and all of this stuff, it was just such a horrible experience. And I remember the day I got into this project, this team was trying to hire me, and I said, like, oh, we're going to use Authorize.net. You have experience with it. And I said, yeah, I know it. I go, it's horrible. I said, I'm only doing the project if we can do Stripe. Once I found Stripe, I refused as an engineer to work on non-Stripe projects. Because I'm like, I'm not going to spend the money and waste my time to try to get this poorly-working API to work when I could just go to Stripe and it's like magic and it's easy and it's fast and it works. And I already had all the, you know, payment management code and stuff I could just drop into new projects. So—

(Sagar Batchu at 00:12:36) Absolutely. Yeah. You know, it's a small digression, but you know that there was a billboard on the 101 in San Francisco a couple years ago from Twilio that said, ask your developer, and that's all it said, right? And I just, this reminds me of that because if an API is so good, like, the point is your developer's going to come to you and say, let's use it, right? Let's find a way to use this thing. And there was just so much gravity in that statement to put that in a billboard. No context. Nothing. Right? It just kind of reminds me of that. Yeah.

(Joel Beasley at 00:13:06) Yeah. And they would, I'm sure they did. That's why it was successful. They're like, what is Twilio? You know?

(Sagar Batchu at 00:13:10) Yeah. Exactly. So what's—

(Joel Beasley at 00:13:10) So what's the worst API that you've ever used?

(Sagar Batchu at 00:13:13) Sorry, but I think it's going to have to be Workday. Workday's API. Yeah. Really bad. Sorry, guys.

(Joel Beasley at 00:13:19) It's okay. They'll get better. You've got to tell people when it's not great. They don't know to get better unless you tell them. You know?

(Sagar Batchu at 00:13:26) Yeah. Yeah. You know, I feel for them. Complex schema, super nested. I think, like, when I was using it, it was a SOAP API. They hadn't even made it to REST yet. Just like a terrible authentication experience. The documentation was just really tough to follow. As I said, the models were all really complex. Like, I felt like I was always shuffling many IDs between API calls myself instead of just working with the customer ID or request ID, something really simple to grok. Yeah. Just a real struggle. I actually know a couple of friends building products around Workday, and they keep asking us at Speakeasy, like, hey, can you guys build an SDK generator? Can you abstract this thing away for us? So, yeah, I'll say Workday is the worst one I've used.

(Joel Beasley at 00:14:21) You said that some of your customers asked if you could actually build some type of wrapper and abstract it. Is that what you're saying that they've asked you to do?

(Sagar Batchu at 00:14:29) Well, you know, I mean, at the end of the day, one of the core issues is the API design itself is probably quite legacy and, at this point, difficult to evolve. Where we can help is because we do generate code and create these nice interfaces, like, there's potential to give them a really nice, modern REST experience on top of even if it is SOAP. There are ways to translate between, and they do have some REST APIs now that definitely could use a really nice, you know, language-native experience to get started.

(Joel Beasley at 00:15:02) Yeah. Some of the problems with the companies is when they get really big and they come to a point where the founder's not there, and it's basically just a bunch of bankers running it, the magic kind of leaves. There's not as much, there's not as much nonsense as if it was just run by a board of bankers.

(Sagar Batchu at 00:15:20) Totally. Totally. Yeah. It's, I totally agree. You need that spark in product building, right? Like, the craft. Like, we talk a lot about craft at Speakeasy, but when we interview engineers, we look closely at, like, are they passionate about the craft side of things?

(Joel Beasley at 00:15:35) Give me a couple tips. What are some tips for hiring engineers?

(Sagar Batchu at 00:15:40) Yeah. You know, it really depends on where you are as a company and the kind of team you're building. But let's say startups, like founding team. I think, to be clear, it's such a hard thing to hire for. I think I have massive respect for people who have built big organizations. Some tips I would say—something we've found that works really well for us is basically run contracting as an interview process.

(Sagar Batchu at 00:16:08) So if you have the liberty to do so, have your early people contract for you for a handful of weeks and turn them into full time, especially for those you haven't worked with in the past. Nothing beats watching someone build, right, and taking the first few days to see how passionate they are, how quickly they're able to grok a problem, how much ownership they take on. Those kind of things are, I think, best assessed in a couple week contracting period. I would definitely suggest that. The other thing that we found is, you know, use engineering as marketing.

(Sagar Batchu at 00:16:45) So everything you do internally—your documentation, your change log—these all become hiring artifacts, tools for you to attract candidates. It's incredible how many candidates out there, how many great engineers actually look at company sites, look at the documentation, the product, and decide based on that. Right? But if they use your product and they see something that speaks to them, that's gonna be a strong reason for them to come talk to you. So at the end of the day, if you focus on the craft and quality and the polish in your product and your external surfaces, that's gonna attract people.

(Sagar Batchu at 00:17:25) So I would definitely throw that in for farming the team.

(Joel Beasley at 00:17:29) Okay. You've used grok as a verb. Like, grok a problem? What is—can you break this down for me?

(Joel Beasley at 00:17:36) I'm gonna get a bunch of DMs about it after if I don't ask.

(Sagar Batchu at 00:17:38) Sorry. Yeah. Yeah. It's one of those developer words to basically say, like, are you able to cut to the ambiguity and understand the core essence of a problem or the question? That's basically what it means.

(Joel Beasley at 00:17:54) Did it come from Grok, the startup? The guy that left Google TPU division, or not? It's been—

(Sagar Batchu at 00:18:00) It's been around. I think it's from an XKCD comic back in the day, really, I suspect. I feel like half the developer terms come from XKCD.

(Joel Beasley at 00:18:11) There you go. Yeah. See? And that's just a perfect example of how you can be in something for twenty years and not come across the term. We've done, I guarantee, we've done a thousand episodes of the show.

(Joel Beasley at 00:18:21) I don't think anyone's ever said grok a problem, but I believe it. Yeah.

(Sagar Batchu at 00:18:24) I'll throw in another one that—so half of our team is based in London, and so they have their own British developer lingo, which I find super fun. They always say nerd sniped, and that was one. I was like, what the hell is nerd sniped? One of the guys on our team, David, always puts in a standup, like, I got nerd sniped today.

(Sagar Batchu at 00:18:45) And I'm like, what are you talking about? And it turns out—I think this is what it means—it means you got deep into a problem, and the problem kicked your ass. Right? You didn't get anywhere with it. So that means nerd sniping is when that happens too. And I think it's also from an XKCD comic, but it just somehow is more popular out there.

(Joel Beasley at 00:19:09) It's an alternative to falling into a rabbit hole, right, or going down the rabbit hole. Yeah.

(Sagar Batchu at 00:19:13) Yeah. Exactly.

(Joel Beasley at 00:19:14) But it's very specific. It's like, I went into the rabbit hole, and the rabbit got me.

(Sagar Batchu at 00:19:19) Yeah. No. Gotcha.

(Joel Beasley at 00:19:20) I got nerd sniped.

(Sagar Batchu at 00:19:22) You got sniped.

(Joel Beasley at 00:19:22) Yeah. Yeah. That's amazing. Oh, that is so cool, man. Yeah.

(Joel Beasley at 00:19:27) And are you having fun? Are you enjoying the business? Where are you guys at as far as growth? Do you talk about that publicly?

(Sagar Batchu at 00:19:33) Yeah. I can talk about a few things. We—yeah. Man, it's so much fun. I think the days are long and the weeks are short. Right? That's always how it feels. Things are whizzing by. And as we go and as we've gotten traction, you know, the goals get bigger, things get harder. Scale—honestly, I feel like scaling is more challenging than PMF. Not claiming we have perfect PMF. PMF is a constant iteration, constant story, but as the company has grown, yeah, there's so many super fun challenges every day across product, hiring, customers. And yeah, I feel like I am living off the adrenaline every day of all the stuff going on. So absolutely loving it. I think in terms of traction, yeah, this year has been an amazing year for us. Started the year with pretty minimal revenue, to be honest. Pretty—I mean, we had done a seed fundraise last year, seed level revenue, and this year, we're in seven figures ARR. So it's been a very rapid growth path for us and have been super lucky to work with some of the fastest, best companies in the valley as well as some larger, very foundational established enterprises as well. So I think we're seeing a really ubiquitous customer base appear. And I think we're realizing, this is our opportunity to lose. Right?

(Sagar Batchu at 00:21:02) It's actually coming down to how well we execute and we are able to build a business. So yeah, traction is good. I think I'm also excited because this business is basically so far built completely on inbound sales. So people, you know, coming to our site, seeing blog posts, discovering us through other customers. And that's for startups, enterprise—companies of all sizes are showing up at our door, which means, which for me feels that we're pretty close to finding this big problem to solve. So if we're able to keep throwing fuel on the fire there and have people come to us, that's fantastic. That's even before we've really built an outbound sales motion or anything like that.

(Joel Beasley at 00:21:49) What type of blog post are attracting the people's interest?

(Sagar Batchu at 00:21:55) Yeah. So since we do a lot of work with API libraries and codegen, we do a lot of posts on API design, how to work with the OpenAPI, which is a complex ecosystem. The other things that attract a lot of posts are this versus that posts. So, for example, we did a big release on Python generation recently, and under the hood, we use something called HTTPX. It's a modern HTTP client for Python that supports sync and async together.

(Sagar Batchu at 00:22:27) And so we did a post on HTTPX versus Python Requests, which is the traditional HTTP library built into Python. And so that post has been flying. And I think it's just that there's a lot of people out there searching who are starting projects, who are searching for, should I use HTTPX, or should I use Python Requests? So those kind of blog posts do really well for us.

(Joel Beasley at 00:22:50) Nice. And then when people use your product, they can tell it's made by Speakeasy or so that you're getting some branded intros off of that?

(Sagar Batchu at 00:22:57) Yeah. If you go to one of our customers' SDKs, you PIP install, NPM, Maven, whatever, you get that SDK. If you open up the code, you can actually see—we keep it very limited because our goal is to help the companies make a branded experience, but there are obviously little badges, tags that you can see as us.

(Joel Beasley at 00:23:18) Yeah. Which actually builds trust too. Right? So if I'm a developer and I'm using an API and it was built on Speakeasy, and it was a really good experience, next time I see an API built on Speakeasy, I'm gonna associate that.

(Sagar Batchu at 00:23:31) Totally. Yeah. That's—it's an amazing in hand virality. It's also a double edged sword too. Right? It puts, I think, a good kind of pressure on us to make sure our customers are maintaining the API as well.

(Joel Beasley at 00:23:44) Nice. Well, we talked a lot about APIs, worst APIs, dust APIs, what you guys are doing in the marketplace. What's the thing that's getting you up out of bed today? What are you really excited about?

(Sagar Batchu at 00:23:56) These days, I'm, yeah, getting out of bed thinking about all the new products that we're building and also the very timely nature of when we're doing it in the market. So we started with this core problem of helping companies build out the SDKs and distribute the API. And I think it's given us a right to expand and a right to help customers with more problems. So we've been pushed into thinking about testing, webhooks, actually runtime for APIs and giving people really quick ways to deploy. There's just this massive, very fertile product surface for us to go expand into.

(Sagar Batchu at 00:24:35) And, you know, what's really exciting now is for us figuring out the right phasing to go do that. That's the job to be done, and that's what's exciting to me. There's no limit of problems we can solve in our space. It's actually a question of what order and how do we phase this to be effective as a business while also delivering value. So it's really this company building that's starting to come together for us.

(Sagar Batchu at 00:25:00) You know, that means we've got to figure out what to build, who to hire, you know, how to stitch that whole fabric together effectively. I just find that super fun and super exciting.

(Joel Beasley at 00:25:11) I've been particularly excited about AI agents and how they're gonna be using APIs. Have you thought about that at all?

(Sagar Batchu at 00:25:19) Yeah. Totally. That was the other thing that I think is getting me out of bed is there's just so much happening in this space. And, you know, in the valley, I think we—it feels like we're pretty deep into it, but actually we're in inning zero. Right?

(Sagar Batchu at 00:25:35) You go talk to enterprise, and the chasm between POC and production usage is massive. Right? Very few companies have actually deployed AI agents for API integration at scale. I think close to zero. So there's tons of exciting stuff happening here.

(Sagar Batchu at 00:25:53) There's also really exciting stuff happening in the IDE and Copilot space. GitHub just opened up early access for Copilot extensions. Pretty soon, you know, you're not gonna have to go to an API doc site to figure out how to use the API. You'll just open up VS Code, type slash API name slash Stripe, and then suddenly you'll have a whole toolkit at your disposal to start integrating the API. There's just tons of stuff happening because of the gen AI revolution we're going through.

(Sagar Batchu at 00:26:25) Yeah. I think, as I mentioned, it's definitely inning zero. I think there's tons to be built. It's not clear where it's gonna go. I think who the winners are, what the new paradigms are going to be, it's all still, you know, up for the taking.

(Joel Beasley at 00:26:42) Yeah. I'm curious to see how payments are gonna work because these agents are gonna need—yeah. I saw somebody on Twitter actually saying that they're mocking out an agent's payment API and asking people in the comments what they would want most out of it because we're so used to going to the website, browsing, signing up, making phone calls, having a meeting, doing a contract. The companies that somehow figure out how to make it so that an agent can autonomously just go up to the API, consume it, and then use it, and there's some payment type system associated with it—those companies are gonna do the best because everyone's gonna build to them.

(Sagar Batchu at 00:27:19) Absolutely. Yeah. No. Totally. And it's kind of funny. I think the best APIs today will also be the ones that agents are able to use most effectively. Yeah. So there's a compounding value here of everything we've been talking about of good and bad APIs, and then also what's coming around the corner.

(Joel Beasley at 00:27:36) Have you personally seen anyone build API calls that are specifically designed to be useful to AI agents?

(Sagar Batchu at 00:27:44) You know, funnily enough, no. I have not. And this is something I've been searching for. I've been also—we've been doing our own research into what that would be. The one thing that I am definitely sure about is that in this world where agents are actually constructing calls, the one thing that you do need to really invest in as a company is have a great API specification.

(Sagar Batchu at 00:28:07) Right? Let's say REST APIs. Your OpenAPI spec needs to be solid because that is the bare minimum that's needed for an agent to understand what requests are available, what are the—you know, just the information needed to actually do HTTP request construction. And it's also what you need today to do more traditional request construction by hand. But that is the number one thing that a company can invest in: have a great OpenAPI spec and a process of updating it, you know, change management, dealing with breaking changes.

(Sagar Batchu at 00:28:39) That's still going to be super important here.

(Joel Beasley at 00:28:42) Oh, it's—yeah. And so do you guys do just documentation? For some people that just have an API and they just want a system to document it, do you handle that?

(Sagar Batchu at 00:28:53) We don't do pure documentation today. We integrate with docs providers like Mintlify and Scalar are two that come to mind. Yeah. We generally try to fit into an existing ecosystem, but yeah, the docs just hasn't been our focus. And I think there are great vendors out there like the two I mentioned.

(Joel Beasley at 00:29:11) And what's the way that people get started? Do you have it set up to where I can just go download it and try it for free, or do I have to talk to a salesperson?

(Sagar Batchu at 00:29:20) No. It's absolutely self-service. We have a very generous free tier. Go to it, download, get started, built in quick start command. Even if you don't have an API spec, we give you one to start with.

(Sagar Batchu at 00:29:33) And then the idea is in a few minutes, you could have a fully hosted great SDK on GitHub for your API.

(Joel Beasley at 00:29:40) Right. I wanna touch a little bit more on what we talked about with the consulting hiring. What type of—during that consulting period, what are the behaviors that stand out to you? So when you see this happen, you think, okay, this person is definitely gonna get a full time offer.

(Sagar Batchu at 00:29:57) Oh, great question. Couple of key things. I think first and foremost, velocity, right, that the person is able to show. And I don't just mean amount of code pumped out or amount of product built. That's obviously important.

(Sagar Batchu at 00:30:10) But also velocity of decision making. How are they able to get through these decisions we have to make with very low amounts of data and input? Do they have an instinct around it? Do they balance both getting perfect data and instinct? That's super important in what we do.

(Sagar Batchu at 00:30:28) You can't wait around to have all the answers given to you by customers or anyone else. You need to operate a little bit on intuition and instinct too. So that I think is super important to me. I think another thing is, you know, communication, how well they're able to communicate these concepts. At Speakeasy, we do something called RFCs, request for comment.

(Sagar Batchu at 00:30:53) It's a core part of engineering culture that helps us work in this hybrid environment we're in, but also, I think, really helps engineers stand out in terms of showing, you know, how they're able to scope and grok a problem. You just—grok again.

(Joel Beasley at 00:31:09) There you go.

(Sagar Batchu at 00:31:10) Yeah. How are they able to communicate a very complex set of thoughts? Right?

(Sagar Batchu at 00:31:15) And then the last one, I think one thing, and this is more personal for me, is customer support. Right? How are they able to, are they happy to jump in the line of fire and get involved on customer questions in Slack and other locations? That to me shows ownership and wanting to own things end to end, all the way from the customer to code and back. Company at our size, that's super important.

(Sagar Batchu at 00:31:46) There's no reason for us to create artificial barriers between the customer and ourselves.

(Joel Beasley at 00:31:53) So you've not always been a founder. You've been an employee before, correct?

(Sagar Batchu at 00:31:58) Absolutely.

(Joel Beasley at 00:32:00) What are some of the biggest mistakes that you've made as an employee?

(Sagar Batchu at 00:32:05) Good question. Made a lot of mistakes, to be honest.

(Joel Beasley at 00:32:10) It's good. You've got to make, that's how you learn.

(Sagar Batchu at 00:32:13) That's how you learn. Yeah. I think one thing that comes to mind is focusing too much on the process as an employee. Especially when you're at a bigger company and it's growing. The last company I was at grew from a hundred something when I joined all the way to 1,500 plus when I left.

(Sagar Batchu at 00:32:33) And it's very easy, I think, to get bogged down into trying to figure out what the perfect way to run a project is or achieve any task other than just doing the thing and focusing on the outcome. I think that's one mistake I've made multiple times.

(Joel Beasley at 00:32:52) Yeah. I made a mistake where I'd build tools before hiring people to manually do it to make sure that we understand how it works. Interesting. Focusing too much on process. I think we've all kind of, I think everybody that's been professionally working for ten plus years has gotten into that trap.

(Joel Beasley at 00:33:12) Yeah. Yeah. Yeah. It's kind of easy.

(Sagar Batchu at 00:33:14) I think it plays into, especially an engineering mindset of wanting to think about things as a system and try to map out who's involved and how do you achieve this versus not forgetting that you're a builder and you're a product person and your job is to figure out how to make the customer successful. I think I keep reminding myself that here now too, especially now we're starting to grow and hire a little bit more, not to get too caught up in process. It is important to have some structures in place as you grow. But I think what's more important is clarifying vision and goals, and everything else kind of falls in underneath that. Right? You don't need to build the system bottom up and tell people how to work and how to organize themselves. If you set a really clear vision, goals, and what we want to achieve, then the systems kind of, they shake themselves into place behind it.

(Joel Beasley at 00:34:14) Yeah. I found at my business of all the processes that we've tried and played with over the years, the core two systems when I walk in every day, I'm like, how many meetings do we have being booked? Because you can't have a close. You can't have a proposal without a meeting. So that's first and foremost, keep those meetings high.

(Joel Beasley at 00:34:35) And then look at proposals sent, deals closed. And then, I mean, that's just important because I've said this a bunch of times, but there's no magic paycheck fairy. Your employees are getting paid because you're doing something useful to the marketplace. You're making people's APIs better. You're giving them a better experience. You're reducing their churn. You're doing all of these things, and they're like, take my money and help us do this. And then you use those resources to employ people. And you'd be, I know it sounds silly for me to say it, but you'd be surprised how many interviews I've done with people where, off the record, they don't actually understand how paychecks get made.

(Sagar Batchu at 00:35:11) Yeah. Totally. It's, you know, I map that to our world, and I completely agree. Where we are as a startup, the only two things that matter are top of funnel.

(Joel Beasley at 00:35:21) Mhmm.

(Sagar Batchu at 00:35:21) Right? How many people are finding out about you? And then the other end of it, customer success or happy customers. Right? And then everything else, even product, it kind of just figures itself out because those two things are the end input and output of the system kind of working together.

(Joel Beasley at 00:35:39) Yeah. And then culture is kind of your quality of life and how you do things. And if you nail that right, you get really good people, and then you're also good at managing the very few KPIs that truly matter. That's a pretty good indicator of success.

(Sagar Batchu at 00:35:54) Totally. Absolutely. Yeah. Yeah. Stuff is super interesting to me personally. You know, what you focus on as a business kind of, I think, either, first of all, decides whether you're successful and then decides whether people are happy doing it.

(Joel Beasley at 00:36:07) Well, hey. It's been great getting to hang out with you and chat with you. I want to make sure that we do a call to action for people to go sign up for Speakeasy, put their hands on the keyboard, get to experience it for themselves. Where do they go? What's the website?

(Sagar Batchu at 00:36:21) Really easy. Speakeasy.com. And you go to speakeasy.com. You can log in with your Gmail or GitHub and get started in just a few minutes. If you have an API, that's great. Bring it, and we'll work with it. If you don't have an API, we'll give you some starter to get started. We want to make it super simple for you to take your API and build out the best possible developer experience for your end users and get that hosted and running in just a few minutes.

(Joel Beasley at 00:36:50) I love it. Your branding's beautiful. We've got similar colors. Yes. Matchmaking Avenue.

(Joel Beasley at 00:36:57) Thank you so much for listening. And if you found this episode useful, please share it with a friend or colleague who you think would get value from it. And if you have topics that you'd like to hear discussed on the podcast, either add me on LinkedIn or send me an email, [email protected]. Every time I get an email or LinkedIn message, it absolutely makes my day and inspires me to keep going.