Engineering Culture and the API Revolution: A Conversation with Sagar Batchu

Transcript

Shane Hastie: Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture podcast. Today I’m sitting down with Sagar Batchu from Speakeasy. Sagar, welcome. Thanks for taking the time to talk to us today.

Sagar Batchu: Thank you, Shane. Really excited to be here. I’ve been a long-term follower of InfoQ, so this is a really exciting moment for me.

Shane Hastie: Thank you, and we appreciate you following us. My normal starting point on these conversations is, who’s Sagar?

Introductions [00:58]

Sagar Batchu: Maybe I’ll start in reverse. I’m coming to you today as a CEO, co-founder of Speakeasy. We’re a pretty young startup here, based out of the Bay Area and London. We’re, what we call, a developer tools company, so we build a toolchain that helps developers everywhere build great APIs.

I start here because the last two and a half years or so, as you might expect, this has completely taken over my life, in a good way. I love working on it. These days I spend my time building and growing this company. We’re a small company of 20-something people. We have a growing customer base. We have some early-passionate employees all around the globe. That’s where I’m coming to you from.

The journey I’ve gotten to here is an interesting one. I actually didn’t start in software. My background is in physics. That’s what I studied. How my journey evolved is, I was actually thinking about doing experimental physics. I was going down the path of doing a PhD, and I realized at the time what I loved more than anything was actually building the software to do the data analysis and actually constructing all of that tech around the experimental physics.

So, instead of getting a PhD, I pivoted into software. Entered the industry the in early 2010s. Actually a really great time, I was very lucky to come to the Bay Area at that time and work in various startups. And over that time, I got lots of exposure to big data APIs. It was the early cloud era as well. I worked for an AdTech company called LiveRamp that was a massive at scale company in terms of data and APIs. We did this massive cloud migration from on-prem to Google Cloud. I think we were the second largest customer behind Spotify for a long time.

It was a really exciting journey, and through that it was probably one of my most foundational experiences as a person and as an employee. It also took me out to London, and I got this amazing opportunity to grow and build an engineering team based out there, and really help define a fledgling part of the business. All of that together, I think has led me back to the Bay Area today, where I’m lucky to be working on this kind of developer tools, just culmination of all of the various things that I’ve been able to do over the last decade or so in the industry.

Shane Hastie: Let’s dig into a few of the points, but one I’d like to dig into is moving from the Bay area to London and starting up a new venture there. What was interesting or difficult or exciting about that?

Starting a new venture in a new country [03:28]

Sagar Batchu: I think what was really interesting about that journey was I entered it thinking, “Hey, I’m already working for a big company. They’re starting a new team. Hey, let’s put my hand up, it’s going to be a fun journey to go out there and take my learnings and continue to be an IC”. Once I did, I realized actually it was going out to help build out a completely different part of the business that actually was essentially a startup.

All we had was an MD, a few early salespeople, basically no tech team yet, and really vision but not much execution yet. I had never done anything like that. It was a shocking experience to go out there and be handed an empty slate. As an engineer, many of us, as we start our careers, we usually enter teams, systems and software that have already-established patterns, have established patterns for development, but also established patterns for growth and how the teams are structured and all of that. It was definitely a really crazy way to be pushed as an IC to be put in that position.

It ended up becoming actually five years of working closely with the business team to help define a new market. We were AdTech, so building in Europe during GDPR’s rollout was actually a really fascinating experience of how to navigate software and regulation at the same time. And then also, building the team and learning how to hire in a new market where you have no contacts, you realize that actually engineers don’t want to be reached out to directly. They like agencies and they like recruiters. All those kind of learnings.

It was honestly a new experience for me, all the way from the tech to the people to business building and what it means to be more than just an engineer, but to be an engineering manager, engineering leader, eventually director and a VP. You get thrown in the frying pan and you figure it out. I think that’s really what that experience was for me.

Shane Hastie: You’ve gone through the journey from individual contributor all the way through now to founder. The steps on that journey… One of the first steps, and I think one that a lot of our audience is going to be looking at, is that shift from individual contributor to a team lead to lead engineer. Stereotypically what we do is, we take the best engineer and we throw them into this new role and we give them no support and training, and we hope that they can figure it out.

What’s your experience been and how can we do it better?

The shift from individual contributor to team lead [05:51]

Sagar Batchu: Yes. Good question, Shane. I think you’re absolutely right. For typically on a team, you take the best developer and then you make them a manager. I actually think unfortunately, that’s not a complete criteria to find the best manager sometimes on a team. I think the first and foremost thing that probably we should do as an industry, and I think it’s happened over the years, is understand that going from being an IC to a leader on a team or manager, it’s a very different set of expectations and very different definition of success or what does great look like.

I think the promotion process, especially for companies that are well established, should really talk through the differences in growing as an IC and differences in growing as an engineering leader. I think those are two different things. I think people think implicitly it means one’s less technical than the other. I don’t think that’s necessarily true. I think especially in today’s ecosystem, a great engineering leader can still be very technical, but their definition of success and what it means for them to be successful is very different.

I think in my experience, what I found was, as you become an engineering leader, you get closer and closer to owning revenue, as any leader does in the business. You are owning some component of revenue, whether it’s bringing new business, promoting the success of existing business, or growing a talent pool of people that will help bring more business in later. It always goes back to that.

For me as an engineer manager, and that too in a new market, it was really doing whatever it took to help the business team get traction and bring new users and new customers in. I think for a lot of engineering managers, it can be a little bit more aligned towards an established product. That can mean really defining and finding the right KPI for their team, is probably one of the most important things that an engineering leader can do.

I would say that’s the first thing I would really push people to think about, is in that growth path from IC to manager, making sure that you are aware of what does great look like and how is it different than, let’s say, going from an L5 to an L6 versus stepping sideways and going to an EM or some other kind of leadership role. That’d be where I would start.

Shane Hastie: What are the pitfalls? What are the risks in that journey?

Pitfalls and risks in the journey from IC to leader [08:04]

Sagar Batchu: Pitfalls and risks in the journey. I think as developers we have a certain intuition that we fall back to, like a technical intuition, that is basically very close to the product. It’s all about what is the best way to build something or what is the best way to design. At the end of the day, we’re very much creators and builders. We like to put together different components and we really think about things bottoms up. We think about how do we construct a system. A classic systems thinker is someone who looks at all the components and decides, how do you stack them together?

I think sometimes as a leader you have to have that perspective, but the often pitfall is that you don’t have the perspective from the other side. Which is instead of looking bottoms up, can you look tops down and say, “What are the top one, two, or three things that are important for a business to achieve? Let’s go from there”. I think that’s one of the pitfalls for any leader, and I think it happens especially on engineering leaders who have started as ICs, which is almost all of us.

I think that’s the main pitfall that I have also fallen into, is thinking too systems-forward rather than making sure you have a really clear grasp of what are the business goals, the KPI, and then working top down from there. And then really delegating to other leaders that you have, either with you or under you, to make those granular decisions.

Shane Hastie: Part of leadership in organizations is owning culture. What is culture, and what is good culture?

What is good culture? [09:28]

Sagar Batchu: Yes. Great question. Earlier in my career, I used to think a lot about what it means to be ex-Google or ex-Facebook or ex-Uber. These little phrases we had to describe people who had worked at certain companies was quite common amongst me and my friends. And I realized that the reason that they say it was, it was an indication of culture or technical experience, a bit of a broad-strokes way of categorizing people into these buckets.

I think that was something I’ve always thought about with culture, is that sometimes the best way to understand culture is actually once you leave an organization. You leave it and you realize what are the main things that you’re taking away, and what do other people see in you when you go to a new organization? That’s probably a reflection of culture that you had in the last experience.

Something I used to say on my team today is, “The kind of culture I want to build at the company is one where when people leave and go onto the next opportunity one day, being able to say they worked at Speakeasy will have some kind of gravity or weight for themselves as a foundational experience, but also the kind of people they go work with”. I think the culture is really those set of experiences that ends up making it a foundational experience for you. Is there anything at all in an experience that you would take away? I think that really is culture.

I think another popular saying everyone knows is, “People join companies but they leave managers”. I think that’s a reflection of culture as well, is at the end of the day the culture ends up becoming the binding glue that helps you go through the up and down and build some resilience. I think there’s a lot to it there. Those are some things that stand out to me.

Shane Hastie: As a leader, how do you frame and build that culture?

Leaders frame the culture and it grows organically [11:08]

Sagar Batchu: I’ve always been one that cares a lot about autonomy and really driving high ownership. I think the first big realization for me on culture is being okay to let people create the culture organically, which means people will misstep. There will be things that you don’t agree with. There will be moments where you don’t feel like it’s how you would do things. But you have to let it play out and let the culture form organically.

Really, where you can steer and guide as a leader, I think, is really thinking through some of the core tenets around which the company can revolve. One that we really talk about, especially as a product-heavy team, is asking for forgiveness and not permission. As a high-autonomy company, being okay with individuals making decisions and with conviction going through. As long as they own the consequences and implications, then we should be comfortable with people making those decisions in the areas that they own. That’s an example of one of the central tenants on which you can revolve as a company.

I think those are the ways you can steer, but outside of that, I think I do let the team and the company make its decisions. In both, I think, make mistakes, have wins, have losses. I think at a meta level, as a leader, you have to be okay with those ups and downs for the culture to really solidify, otherwise the culture is really a house of cards that you are holding up, and every interaction needs you to be a good interaction. That’s not sustainable. And ultimately, that’s not culture. That means it’s just you, rather than some kind of culture that permeates past you.

Shane Hastie: High autonomy, allowing people to make decisions and to own the results of those, how does that play out?

Enabling high autonomy [12:50]

Sagar Batchu: High autonomy can lead to a few things. I think the positives are that you would probably have happier employees, people who feel empowered by making decisions. They get to make big decisions, small decisions live with both up and down, and they would probably learn faster as a result. I think another real positive to autonomy is it reduces the stress on managers and leaders to be the gatekeepers of decision-making.

I think the not so positive part of autonomy that you have to live with is the chaos. It can be more chaotic. There’s more movement at all levels of the organization. It’s a little bit more messy on the margins. There’s more chaos in the decision-making. I think the highly autonomous behavior works great for early companies at our stage, where what you really care about is that employee passion, the speed, the velocity at which you can move as a company. I think companies at our stage, velocity is our only friend. That’s the only thing that’s pushing the company forward. I think it works really well at us.

As you get bigger, I think the autonomy has to be traded off with a little bit more consistency. I think my last company, LiveRamp, I saw that as we got bigger, a lot of the engineering initiatives went from being driven off autonomy and about product-building to more about creating a consistent experience. I think autonomy can go both ways, but I think at an early-stage company, I’m a big proponent of it.

Shane Hastie: How do you keep the blast radius small?

Keeping the blast radius of mistakes small with well-defined ownership [14:16]

Sagar Batchu: It’s a good question. I think to keep the blast radius small, autonomy pairs really well with ownership and well-defined ownership. Something we did recently as a company was, for the first time in the company’s short history, evolved from having one engineering team to multiple engineering teams. A big question was, what is each engineering team going to own? If every team’s going to be autonomous and make decisions, then the ownership has to be really clear, otherwise there will be chaos and an unnecessary chaos that we are taking on ourselves. I think autonomy can work really well when the ownership is clear.

In our case, we decided to go down the path of product teams or revenue teams, where every team owns true full stack development, all the way from the sale of the product to how it’s built and deployment, front to back. The ownership is really clear as far as what each team owns, and now we can let each team operate and own an end-to-end lifecycle of both the product, the sales, support, and all of that. I think that’s one way to reduce the blast radius for a highly autonomous organization, is making sure the decisions fall within a clear bound of ownership.

Shane Hastie: What are the other challenges that you’ve dealt with in this growth path?

Challenges in career growth [15:28]

Sagar Batchu: I think growing from a senior IC into an EM has been challenging. I think I did it in a non-traditional way, where I was forced into it as a result of location shift to a newer market as opposed to more traditional. You get mentored by an engineer manager and grow that way. It was a tough learning experience to be thrown into that position.

I think the second big one has been really taking the leap from an engineering leader of any kind into a founder, which honestly is the kind of leap of faith that you really just have to close your eyes and take a jump and hope that it works out. There’s no amount of preparation anyone can give you mentally for the kind of shift in role it’s going to be. I think the thing that stands out the most to me as a founder is that it’s very hard to find people with empathy for the position you’re in.

I find that actually on a week-to-week basis, I seek out conversations with other founders. Because even if they’re in completely different industries, like e-commerce or finance or something else, the journey of a founder, the amount of up and down and emotional swinging it gives you, can only be empathized through talking to someone else who is going through that or has gone through it. I think that’s been a very tough growth experience for me, is realizing that the founding journey is actually one where very few people can actually empathize with some of the problems you’re facing.

Shane Hastie: Shifting focus from the people stuff to the technology. You’re an API company. What’s the implication of all of these AI agents on APIs today?

The implication of AI agents on API development [17:02]

Sagar Batchu: It’s a really fascinating time to watch the technology emerge. It’s so fun to play with and look at. It’s like taking a peek into the future of development that’s no longer purely human-driven, or at least predominantly human-driven, to development that is primarily machine-driven. It’s really a crazy thing to think about.

I just think about it, our flow as developers every day, everything from writing code to version control, to shipping code, to deployment, it’s all designed to solve problems for humans. The whole concept of developer experience, it’s all about humans. Even things like authentication is all about humans. You have to log into a portal and get a key or get an OAuth token or something like that. It’s all about how people interact with systems.

With the agents, I have this paradigm shift that if we had to go into a place where agents, essentially little applications, make the calls on behalf of humans and even write code on behalf of humans, after you watch the demos and the excitement subsides, you realize that every piece of tech we have today is not really optimized for that. Even the agents that we’re seeing today that can make API calls on our behalf, they are really working within the framework of scaffolding of all the software that’s being designed for humans.

I’ll give you a really concrete example. When you think about APIs, API authentication is a really big problem around which there are many big businesses that are being built. When I think through that, I think about something like OAuth authentication, which is all about authentication for APIs, creating scopes, making sure that the right APIs can be accessed by the right actors. And those OAuth workflows are all about humans taking their usernames and passwords and fetching tokens to actually drive those authentication workflows.

And you think about an agent, it doesn’t really make sense for an agent to log into a browser and log into a workspace and get a token and do its work. Sure, it can do that. The technology makes it possible, but it’s very inefficient. You think about things like that and you realize there’s actually tons of scope for disruption and tons of scope for new technology to be built. As an API company, where we are positioned, is that we really work closely with our customers to build out their APIs today.

How those APIs get built is going to evolve. I think the role we will play is continue to build the picks and shovels, the components, the toolchains that they will need to interact with agents, to build agents, to let agents build APIs themselves. We are at day zero. There’s no framework stacks, there’s no protocols, there’s no years worth of standards that have been built like we have today. I think all of that is really up for redefinition going forward.

I think the agent side of things is very exciting. And I would actually say we are truly at day zero. Everything we’ve seen is POC or demo. It’s not enterprise-ready and it’s far from being so. So, lots of opportunity for companies like ours to go build the right tools for enterprises to leverage these things.

Shane Hastie: What’s one piece of advice that you would give an individual contributor working in an organization today, thinking about where they want to go with their career?

Advice for career growth [20:16]

Sagar Batchu: I think it’s worth thinking through your motivations and what is it that drives you every day? Is it building the technology? Is it building a business? Is it team growth and the people aspect of it? I think once you’re able to hone in on what is the motivating factor for you, you can best align yourself with the different roles out there. I think if you’re an IC and you really care about building amazing technology and doing things like defining standards and defining new frameworks, then…

Growth as an IC is immense. It’s maybe arguably the most deep of all the tracks. There’s an infinite amount that you should learn and become an expert on. I think there’s the engineering manager track, where what you really care about is efficiency, productivity, building high-performance teams, really bringing together a group of people who want to work with each other and do an amazing job.

And then finally, if you’re motivated by business and trying to think about that fabled product market fit, then taking the leap as a founder and doing that is a path to go. I’m only describing three paths. There’re probably a lot more. But I think, yes, starting with those motivations of what drives you.

And I think as an IC, as an individual contributor, it takes some time to figure that out. Because the day in, day out of doing contributing doesn’t necessarily leave a ton of time to think about this and get exposure. I would say even before taking that leap of faith, trying to get a little bit of exposure to all of these different paths is great.

One of the best ways to do that, and of course I’m biased, is to work at an early-stage startup that is going through that growth journey. There’s just an immense amount of opportunity on all those fronts: technical contribution, of management, hiring, selling, revenue. If you’re able to do that, then I think as an individual contributor, you’ll have the right experiences to make an informed decision.

Shane Hastie: Sagar, thanks very much. A lot of interesting ideas and good advice there. If people want to continue the conversation, where do they find you?

Sagar Batchu: You can find me on LinkedIn. You can find me on X. Our company has a website to which you can access a Slack community where we have all of our customers and users. We hang out quite often. I’m in all of these places, and I’m based here in San Francisco.

Shane Hastie: Thanks so much for taking the time to talk to us today.

Sagar Batchu: Thank you so much, Shane. It’s been a pleasure to be on this podcast.

Mentioned: