Ashwin Sreenivas spent his childhood in India waking up at 5am and studying until 8:30 at night. History, geography, physics, chemistry, math. Every day, from 4th grade through 12th grade, through the Olympiads and the National Talent Search Exam. He says now, three years into building one of the most exciting AI-native companies in the world, that all of that is precisely why what he does today feels almost easy. “I get to come in here and there’s a lot of people and I’m having fun.”
That mode is what Decagon runs on. The company Ashwin co-founded with Jesse Zhang in 2023 is now valued at $4.5 billion, has crossed 450 employees in three years, and works with some of the largest enterprises on the planet. The path there has in some ways been simple: don’t theorize about where AI is going, talk to customers until the pain is unmistakable, build for that, ship, repeat. Decagon went from zero to $1 million in ARR with two co-founders and no employees.
In this conversation, Ashwin walks through what that means in practice. How Decagon operationalizes a single cultural priority: speed, even when it costs coordination. How they hire 450 people without breaking the bar. How AI has reshaped the IC engineer, the AE, and the VP of EPD. And why, after a year of running 6+ days a week, the thing he and Jesse would tell their earlier selves is: go faster.
Listen on YouTube, Spotify, and Apple Podcasts
Ashwin Sreenivas is the co-founder and CTO of Decagon, the AI customer concierge platform founded in 2023 that serves enterprise customers including Substack, Eventbrite, Duolingo, and Notion and is valued at $4.5 billion. Decagon Labs, the company’s in-house model development effort, now powers around 90% of Decagon’s model traffic. Before Decagon, Sreenivas co-founded Helia in 2019, an AI startup acquired by Scale AI a year later. He started his career as a strategist at Palantir Technologies in New York. Sreenivas holds a Bachelor’s degree (2017) and Master’s degree (2019) in Computer Science from Stanford University. Decagon raised $35M in 2024 and has scaled to over 450 employees.
Where to find Ashwin Sreenivas:
Where to find Nakul:
Where to find Audacious Ventures:
In this conversation with Ashwin Sreenivas:
00:00 Who is Ashwin Sreenivas?
02:10 How did Jesse and Ashwin decide what to work on at Decagon?
04:19 Why did they reject the top-down market-sizing approach?
13:16 What does Decagon give up to keep moving fast?
17:54 Does Decagon expect their team to be 6-days in-office?
23:33 Why didn’t they hire a single employee until $1M in ARR?
27:12 How do you hire 450 people in three years without breaking the bar?
31:20 Are Decagon engineers even writing code anymore?
35:08 How does the IC engineer role change with Claude Code and Cursor?
36:32 Shipping in two days: how does EPD leadership change?
40:15 What are the two types of FDE, and which one do most AI companies actually need?
49:21 How will the human role at Decagon evolve over three years?
57:15 Why did Decagon build its own models in Decagon Labs?
1:00:50 What worries Ashwin most about Decagon today?
1:03:52 How does Ashwin manage his psyche while running this fast?
1:08:00 What hiccups has Decagon had that no one sees from the outside?
1:09:50 Quickfire: overrated advice, AI products, books, red flags
1:12:43 What would Ashwin tell his younger self about Decagon’s journey?
Ashwin’s sharpest lines from this conversation:
On what actually matters:
“If you build a company doing something that your customers care about, you can mess up everything else in a way and it doesn’t really matter.”
On founder market fit:
“If you pick the right market, the market will pull the problem and product out of the founding team.”
On what Decagon traded for speed:
“The pace of building has changed so quickly. With AI, there isn’t that much time for coordination. You have to give somewhere, and we gave for speed.”
On packing desks tight:
“I specifically asked our head of workplace to get smaller desks so that people are packed even closer together, so that you can lean over and talk to an exponentially larger number of people.”
On responsibility for AI-generated code:
“Use all the tools you have available so that you can move faster, but at the end of the day, you are responsible for the code you push and you should be prepared to defend it rather than say, ‘oh, the AI agent wrote it.’”
On hiring red flags:
“It’s not a specific flag, but rather that gut feeling of something’s a little off and I’m not sure I want to pull the trigger on this.”
On the normality of “fires”:
“I guarantee you every fast-growing company, probably without a single exception, they’ve had a thousand fires internally. Just normal. That’s just how it is.”
On the advice he’d give his younger self:
“Go faster, hire faster, build faster, get out to the biggest customers faster because the need is real, the market pull is real. You just need to go capture as much of it as quickly as you can.”
Full Transcript: Ashwin Sreenivas on Knuckle Up
Ashwin:
I would wake up at 5:00 in the morning. The first hour I would do history. For the next hour, I would do geography, and then I would take a 30-minute break and then physics, chemistry, where I would do math every day from five in the morning to 8:30 at night, from fourth grade to 12th grade.
So in a way, I’m somewhat used to this and now all of a sudden I get to come in here and there’s a lot of people and I’m having fun. This is all of a sudden much easier. The pace of building has changed so quickly with AI. There isn’t that much time for coordination and you have to give somewhere and we gave for speed.
Go faster, hire faster, build faster, get out to the biggest customers faster because the need is real, the market pull is real. You just need to go capture as much of it as quickly as you can.
Nakul:
Then the Decagon journey, have there been any hiccups where you guys felt today was rough?
Ashwin:
I guarantee you every fast-going company, probably without a single exception, they’ve had a thousand fires internally. It’s just normal, that’s just how it is.
Nakul:
Ashwin Sreenivas co-founded Decagon in 2023. Three years later, the company’s AI customer concierge platform serves some of the largest companies on the planet is valued at $4.5 billion and is one of the fastest growing startups of the AI era. An immigrant from India who started his career at Palantir and sold his last startup to scale AI, Ashwin.
Is as customer obsessed founder as they come. In the first few months of Decagon, instead of theorizing about where AI was headed, he and Jesse focused singularly on talking to as many customers as possible and understanding their pain points and finding where willingness to pay was unmistakable.
That obsession is how Decagon went from zero to $1 million of VRR with two founders and no employees. As a co-founder of Decagon, Ashwin is in the rare position. He has an AI native org and an AI native product that is growing superfast. What do culture and operations look like inside a fast-growing AI native company like Decagon? We get into all of this and more today.
Ashwin, welcome to the show.
Ashwin:
Yeah, thanks for having me.
Nakul:
So I want to start with a quote of yours. A lot of first-time founders, us included at the time, spend a lot of time over intellectualizing the problem, being able to figure out what is the right three-year strategy at the start. It’s really easy to fool yourself into thinking you’re doing great important work. Can you talk about how you and Jesse decided to work on this specific idea for Decagon? How did you go through the idea maze?
Ashwin:
Yeah. Yeah. First, thanks for having me. I’m really excited to be here. Early on in the company, we decided to explicitly avoid this thing that I think a lot of first-time founders do, which is thinking through, okay, what is our 10-year plan? How are we going to build the right set of modes to build our defensibility? Just because I think in the early days of the company, there is so much that is unknown that doing that well, I think is nearly impossible.
So early on in the company, essentially what we did is we said the only thing that matters is what do customers care about and what are they willing to pay for today. Because everything that comes is downstream of that. So in the early days of the company, all that we did was we said, “Hey, let’s focus on a buyer and the problems that they have.”
As an early stage company, the only thing that you’re looking for is what is a common unique pain amongst a specific set of buyers? Once you figure out the pain that you’re trying to address, only then do you say, “Okay, now, this is how I think I can solve this pain. This is the product that results from it. This is the go to-market motion that results.”
So in the early days, the only thing that we focused on was who’s the buyer that we want to serve and what is the specific pain point that we have? Ultimately, as we started talking to a lot of these buyers and specifically we were looking at heads of customer, success, heads of customer service, VPs of operations within fast-growing tech companies, the number one issue that they all had was customer support.
They kept coming back to us again and again saying, “Hey, we have all these problems, but the number one thing that I’m struggling with is customer support.” Because number one, it’s crucial to the company because this is the lifeblood of companies today. Two, it’s very labor-intensive and it’s hard to manage. So that was kind of how we hit on the problem we wanted to solve.
Nakul:
Did you not consider the top down approach at all like market sizing? A lot of founders come into it from what they’ve individually felt as a pain point in their last startup. They take a top down approach of, “Hey, where is the world headed? This is where I’m excited.” It seems like you guys were maniacal about finding customer pain point through that journey. So no top down approach at all in your journey with Decagon.
Ashwin:
No, not as much because I’m of the opinion that the markets that you serve honestly determine a lot of the outcome of the company. There are great markets to build companies in periods of time and there are bad markets to build companies and in periods of time. I wanted to ensure that I wasn’t just going after what was a bad market.
I think Mark and Jason had a blog post that he wrote about, I think this was in the early 2000s or maybe the late 2000s where he said, “Great market means bad founder market wins. When bad markets mean great founders, market wins.” So we were very focused on making sure that we picked the right market and the right problem within the right market, which was ultimately this view that if you pick the right market, the market will pull the problem and product out of the founding team.
Nakul:
Do you feel actually in today’s times, even more so this bottom-up approach is the only way it works because the world is changing so dramatically that if you’re not too opinionated about where the world is going in three years, you’re going to get killed by the market shifting sands.
Ashwin:
I would say having done a company now both ways.
Nakul:
Yeah.
Ashwin:
Right? One which didn’t work out quite as well and one which did, I think this advice holds all across time. I think the difference today is that so many markets are changing so quickly that opportunities that did not exist before are opening up. So I think the big difference today is just that things that were kind of completely off limits, markets that were completely captured by companies before and markets that just weren’t accessible to software are just opening up.
So it’s worth kind of reexamining every single market from the ground up and saying, “Okay, what are the primary pains that the biggest buyer in this market has and is there now a way to solve them?”
Nakul:
Given so much is changing now though, how do you stay true to what you decided as the product vision? Your own primary research with buyers is still true today. Are you and Jesse constantly revisiting product market fit?
Ashwin:
Yeah, I think this is actually extremely important for us to regularly think about. The reason is because the technology is changing so quickly, something that was state of the art six months ago because of where the models were and things like that, if you overbuild a product toward that, what could happen is six months later you have a new set of models that come out and all of a sudden all the assumptions you made before in terms of the way you built product, the kinds of problems you thought you could solve, because that was all that was solvable at the time, all go out the window very quickly. We built a research team in house to focus on that.
Our engineering team and product teams are very heavily embedded within our core customer base because we know that every six months because of how quickly the technology is changing, the kind of product that we build, the kinds of problems that we solve are all going to completely change. If we don’t get ahead of that, someone else will and we will end up being the ones that get disrupted.
Nakul:
So let’s get into how Decagon is run. I really want to focus on the next hour on the core of it because not just is Decagon one of the most exciting companies in the world today, but it’s also probably one of the most AI native companies. You started three years ago right at the beginning of this wave. So I want to spend the next hour thinking or talking through culture, how the various functions are run, how leadership works at Decagon.
Let’s start with the culture. So your four stated values are just get it done invent what customers want, winners mindset, the Polymath Principle. How do these actually show up on a Monday or any given week?
Ashwin:
Yeah, yeah, yeah. Invent what customers want, I think was tied to the thing that we was just talking about, which is this idea of the only thing that matters is customer pain, and we really wanted to avoid this world in which at certain point, once you get big enough, there is this pull just because it’s a little bit easier to sit in a room and say, “Okay, I have the perfect vision. I know what customers want. We’re just going to build that and put it out into the world.”
We really wanted to ensure that that wasn’t how product got built within Decagon. So this idea of invent what customers want is mostly on the EPD side, which is ensure that anytime you’re building something, you know who it is for because they have explicitly asked you about it. Not because you think, “Oh, this is probably what they want,” but most of the time, again, the market will pull it out of you. The Polymath Principle was something that was-
Nakul:
That’s an interesting one. I’ve not seen that one before.
Ashwin:
That one is actually because we consider everything within Decagon to kind of be a team sport. The fun example that I’ll give is most enterprise sales teams have a gong, some kind of a gong where once a deal is closed, you have the salesperson come and strike the gong for having won the deal.
At Decagon, it’s not just the salesperson, it’s the salesperson, the APM on the deal and the engineers that support the deal that all kind of do it together because we believe that everyone is involved in getting a deal across the finish line and we think it makes everybody better because a salesperson that deeply understands the product and the technical complexities and the engineering decisions is able to understand customer issues better and communicate why we are different.
Similarly, engineers at the other end of the line that deeply understand, “Hey, this is what is important in a sale, this is what customers care about today,” are able to build better products. So we really want to emphasize this idea that, hey, just because you’re in one particular team doesn’t mean that that is the only thing you should care about because you just end up doing better work the better you understand the business as a whole.
Nakul:
Does that polymer principle show up on your recruiting criteria then?
Ashwin:
So this does show up on the recruiting side as well. So for engineers, we spend a lot of time thinking through, “Hey, how do you think about product? How do you think about designing things in a very user-centric way?” I mean, it’s hard to simulate a sales cycle or things like that, but we do check for this ability to understand user problems and build against them well.
On the sales side, of course, it is, “Hey, how much do you have the ability to sell a more technical product to dive into details?”
Nakul:
Of these four, which was the hardest to operationalize as you’ve gone from two people to 400 plus people within three years?
Ashwin:
Honestly, it’s different ones for different teams. So this idea of build what customers want does often get more difficult as you scale out because you now have people that can get farther, farther away from the end customer, because you have more teams that are dedicated to running that customer specifically. So we put in very conscious efforts to make sure that that doesn’t happen, right?
Because on one hand, you want engineering teams to be able to stay focused, have long periods of deep protected time, but you also, again, want to ensure that they don’t build in silos. Similarly, on the sales side, it can be easier to say, “Hey, here is the talk track, here’s a talk track that’s worked a thousand times before, as long as you stick to these well-defined playbooks, things go well.”
So ensuring that we have this kind of deep cross-cultural, cross-team collaboration, especially again, as we get bigger, we have offices and countries all over the world, ensuring that that stays well has been something we’ve put time into.
Nakul:
Is there any mechanism that you guys have figured out sales reps listening directly from customers on what they want or if there’s friction in sales processes or customer success orgs getting that, that the entire company gets to hear that whether it’s a weekly Slack summary or something. Is there some mechanism for you to know this?
Ashwin:
Yeah. So this is exactly where luckily the Polymath Principle helps us a bunch because if we were behind on a deal, like the sales rep can quickly figure out why we’re behind and then the right engineers are pulled right in. They join the customer calls themselves. So we don’t have to go through this process of, “Okay, how do we make sure that that goes into a digest somewhere that is then distributed to the right teams?” We just make sure the right person on that team is in the sales call themselves.
Similarly, if this is an existing customer and they’re unhappy about something, we have Slack channels with every single one of our customers and anytime that customer has an issue, the right engineer or product leader on the team gets added to that Slack channel if they weren’t there already and then they respond directly.
So again, we want to ensure that there aren’t this kind of long chains from the customer to the person building the thing. So this actually just solves that problem entirely.
Nakul:
Then the next one to just get it done decisive action and speed over prolonged deliberation and planning, how do you ensure... Because speed has a trade-off, right? So speed, obviously, is an attribute that all of us aspire to in business, but at the same time, speed can also mean thoughtless execution, sloppiness to cut corners to just get it done fast. How do you kind of strike that balance?
Ashwin:
So I think the trade-off for us has been speed on one hand versus coordination on the other. So in terms of quality, we’ve been able to maintain the quality part by ensuring that, hey, when you ship something up, when you roll out new process, it meets the quality bar, but coordination is something that can suffer because if you have two teams building the exact same thing in slightly different ways, then it’s hard to coordinate if everyone is building it out in two days.
That’s actually just a tax that we have decided to accept. It’s not a perfect trade-off. You have to give somewhere and we gave for speed. The reason I think this is more true today is actually because the pace of building has changed so quickly with AI. In the old world when development took a lot longer and if you say, “Okay, I’m going to scope out this feature and it’s going to take me two weeks to build,” there’s kind of some inherent coordination time in there because it’s going to take two weeks to build.
So during that two weeks, you have time for everyone else to coordinate what people are building. But now, instead of two weeks, if it’s two days, there isn’t that much time for coordination. We knew that one of these had to give and so we were more okay with the coordination piece giving in because we think if you’re building fast enough, yes, if you have two teams that turned out to be building in slightly different ways, we’re moving so fast anyway that we can fix that on the backend when it actually becomes a problem.
Nakul:
Actually, it’s an interesting point like the trade-offs. So you have these definitive cultural elements that you really want to adhere to. Some of that is informed by our past experiences maybe for both you and Jesse. You mentioned one, coordination is something you’re willing to give. Are there other aspects that you guys came in thinking, “Hey, these things get talked about a lot, but we are okay giving up on those a little bit for the sake of these four?”
Ashwin:
Coordination is definitely the biggest one. The other big one is probably productization quickly, by which I mean our general philosophy as a company, because we sell primarily to enterprises, was making sure that whatever we built worked exactly for the company as though it were built just for them. This is something that people generally are like, “Hey, don’t do this because it’s going to be very, very, very difficult to scale if everything is built bespoke.”
So the difficult decision for us was how do we make something feel very bespoke and scalable at the same time? So what we did was in the early days, and this is now the very early days, we actually built basically bespoke in a completely unscalable way because we figured once we get big enough, we will figure out how to productize.
Now, that we are much bigger, the way that we productize is not by saying, “Hey, we’re going to build the standard thing and everybody should be able to get to that.” But rather to say, “We are going to build the kind of right configuration points so that you can configure the product to suit you exactly.” That last mile of configuration, now, we have AI agents, this is what they’re very good at. So as an end customer, you can get something that fits you perfectly, in a scalable way.
Now ,the problem that this causes is now when you’re building out a new thing, there is a risk of you overfitting to a customer because again, our philosophy is it should fit you perfectly. Then if three people want three different things, you figure out the right configuration points.
Again, that’s a trade-off, right? Sometimes you’re right, we will overbuild, we will build in a somewhat custom way that isn’t scalable. But again, the assumption that we’re making is, hey, once this becomes a problem, we will figure out the right configuration points and rebuild if necessary.
Nakul:
Were some of this informed from your stint at Palantir? I know you started there in your careers.
Ashwin:
No, a lot of it was, but I think a lot of it is also because of the market that we serve. We sell primarily to large enterprises, primarily in large deals. So effectively what happens is these are very demanding customers and as they should be. We are essentially representing them to their end consumers and they have very specific needs. So I think part of it is a lot of what we did at Palantir back in the day, but a part of it is also the market and type of customer that we serve at Decagon.
Nakul:
Then the next piece about your culture is in office, what? Six days a week, five days a week? Five and a half?
Ashwin:
Yeah. We used to be six days a week actually when we were much smaller, but now we’re big enough that we’re five days a week for most of the company. Jesse and I are in the office on every Sunday.
Nakul:
I mean, today’s a Sunday when we are recording, and you were coming from office.
Ashwin:
Yeah, I was coming from the office. Yeah. So Jesse and I are in the office every Sunday. Then teams that have things that are blowing up are on non-Sundays, but by far for most of the teams, five days.
Nakul:
Why are we so religious on this?
Ashwin:
Honestly, just because it comes back to that coordination problem. Actually, in the very early days, it was because everything we were doing was new. I think just in my opinion, nothing beats everyone in a room looking at a whiteboard and whiteboarding things out.
Today, it’s mostly because of that coordination piece that we talked about. Like the more remote you are, the higher the coordination tax. Again, we talked about given that things move so quickly, the more remote we are, the less coordination you can have, which kind of forces you to go even slower or you have even more chaos, and that’s quite difficult.
So even now, we find that most of our conversations are from...
Ashwin:
... That’s quite difficult. So even now we find that most of our conversations are from people leaning over and saying things to each other. In fact, funny story, not only did I want people to be in the office, but when we move, we’re actually about to move to a new office, and I specifically asked our head of workplace to get smaller desks so that people are packed even closer together so that you can lean over and talk to an exponentially larger number of people.
Nakul:
Does it create an issue? The 16 offers especially for some kind of people Decagon is not a great place then.
Ashwin:
Now that we are a much more mature company, for most people it is actually just five days a week in office. The only people expected to do the six are actually just me and Jesse. Because again, we understand that there are a lot of people that work at Decagon that have families. And I want them to spend time with their families on the weekends. I don’t want them to miss dinner with their kids and things like that. And we understand all that. There are people at different phases of life and yeah we make it work for all of them.
Nakul:
So let’s talk about recruiting. And the first and most important hire is the co-founder hire for both of you. How did the two of you decide to work with each other? Yeah, just give us the backstory there.
Ashwin:
Both Jesse and I had started companies before. I started a company called Helia that we sold to scale. He started a company called Lowkey that he sold to Niantic. And this was right in the period where both of us were figuring out what we were doing next. And once we met, we had a number of things surprisingly that were very much in common. So we both sold our first companies. We both got married relatively young, both to women a year and a half older than us. And actually our wives get along very well. In fact, we now live in the same building. Both of us wanted to start enterprise companies. Both of us wanted to do problem discovery in a similar way. Everything we talked about in terms of being very focused on the end customer and what their pains were.
Both of us grew up in very similar environments. Both of us used to do the Olympiads and so we had a lot of common background. Both of us thought about work in a very similar way, which is neither of us did much in our life except work. And so we were just aligned on a lot of things. The most important thing was also I think both of us respected the other person’s competence, which is actually very important because when you have a fast-growing company, you have to lean on your co-founder a lot. So being able to say, “Hey, I know this is a big important issue to figure out. I don’t have time for it, but I trust that you can do it and I don’t need to think about it anymore.” So having that quality was very important as well.
Nakul:
How long did you know each other to get comfort on that?
Ashwin:
It ended up being relatively quick because when we started the company together, this was kind of a gradual process in that initially we were like, “Okay, you know what? We’re both figuring stuff out. Let’s just hack on things together.” And there was no let’s sign on the dotted line, start the company immediately. That was a few months later, but mostly because in the early days we were validating problems, talking to customers, things like that. So we kind of got to build that out over time by seeing the other person do it.
Nakul:
Do you guys now know or even at that time knew the relative competence where one is stronger than the other?
Ashwin:
We found out pretty quickly because again, in the early days we were doing all of the things. We were cold emailing customers. We were getting on customer calls. We were prototyping and building solutions to things. So we got to see all of that pretty quickly.
Nakul:
But both of you are polymax. So my point was more like, is one person better at people problems versus product problems? Or actually both of you, because you’re president, he CEO, it seems from a distance that both of you are polymax across the org.
Ashwin:
So both of us actually do get into the weeds on everything across the org, which is actually great. But actually to make things go quickly, each of us have very clear areas of ownership because again, internally we believe that every problem should have a single person that is responsible for it. And between me and Jesse, everything maps either to him or to me uniquely so that we know that, “Hey, these are the things that you’re going to take care of and you will do them well.” Jesse does a lot of the go to-market stuff. I do a lot of EPD. People, interestingly enough, rolls up to me, people in recruiting. But both of us actually go into the weeds on everything across the company.
Nakul:
And then the other interesting thing about Decagon is you guys did not hire a single employee or maybe there was one junior employee till a million of ARR, which is right. I mean, we are in the business of recruiting for our startups and most founders come and they start recruiting engineers two, three, four right at the beginning, some start hiring their sales reps at 500K of VRR. Why make that choice of not hiring? Was it intentional or just happened so quickly?
Ashwin:
No, it was somewhat intentional, but looking back, I wish we had started a little bit earlier, but with the information I had at the time, I think it would’ve been difficult. I think now having seen so many companies, us included, growing so quickly, it’s like, “Oh, it’s obvious that we should have hired sooner then.” But I think if you think back to 2023, before a lot of these companies had started, a lot of the revenue ramps were much slower. So one, we were surprised by how quickly our revenue ramped in the early days, but we weren’t sure how quickly it would continue to ramp, which was honestly why it took us a little bit longer to hire our first people. And also secondly, early stage recruiting takes a lot of time and we just had our hands fill with building for customers and onboarding new customers that were like, “Okay, next month, as soon as we build these three features and onboard these three customers, then we’re going to have so much time and then we’re going to recruit our first set of people.”
Nakul:
Do founders selling also, where did you have the bandwidth to build all the things that the customers need? Because the first few customers all have their unique-ish demands and you again took that approach of-
Ashwin:
Make sure they have everything exactly as they need. Yeah. I mean, it was tough. In the early days, we would be in the office, which was one of our apartments at probably around nine in the morning and we were there until one o’clock at night. And in the early days, we did seven days a week. The two of us did seven days a week, I think for the first year or so. And then we stopped that because both of us are married. Seven days a week is a lot.
Nakul:
I was just about to ask, how are you convincing your wives of this?
Ashwin:
But yeah, it took a lot of time. And the other benefit that we had was, again, because both of us could do sales calls, both of us could do customer onboarding and both of us could write code. That helped quite a lot because we were able to juggle and fill in for the other person whenever needed.
Nakul:
And then you made the switch and you’ve gone pretty fast. So you’ve gone from zero employees to 450 employees now within three years. I want to get into what’s the trade off of hiring that fast and all of that. But before that, do you guys have an overall recruiting philosophy and framework that the entire org follows? Or each hiring manager ends up having their own framework?
Ashwin:
We do have an overall philosophy and even to this day, Jesse and I are pretty involved in recruiting. I mean, at this point, neither of us can do all the interviews anymore because there’s just too many, but even now including for ICs, we review hiring packets. And so we’re still pretty involved. And the things that we’re trying to make sure of are that all the new hires that we bring on align to the kind of core cultural values that we’re trying to look for. So have we looked at this person’s ability to operate across multiple teams? Have we looked at their ability to go really, really, really deep on problems? Has the interviewer on the Decagon side probed for all of these things? Have we found a clear champion within Decagon? We, like many other companies hire on the one, two, three, four scale. And if you just have threes all across the board, “Okay, there’s no clear champion for this person. They haven’t spiked strongly enough and we shouldn’t be making them an offer.” So yes, we’re still pretty involved in recruiting up and down the line.
Nakul:
But at that pace, 450 employees are being hired in three years. How do you maintain that bar? Because the flip side is you maintain the bar that high, hiring becomes slow.
Ashwin:
I’m of the opinion that when you need to hire at scale, you need to talk to a lot of people. There are a lot of great people out there in the world and now it is our job to find them and convince them that, “Hey, Decagon is a great opportunity for you.” In terms of how we maintain the hiring bar, we actually have a group of bar raisers internally that do the final interview. So once you’ve gotten the thumbs up from everybody, one of the bar raisers interviews you and we’ve specifically picked out the bar raisers as people within Decagon and we’re like, “Hey, these are the people that really kind of hold our values. They’ve demonstrated it over time and they know what they’re looking for amongst new folks.”
Nakul:
Actually, I’ve never heard this before. So the bar raiser, how many bar raisers at Decagon today approximately?
Ashwin:
I think 20, 25 people.
Nakul:
Do they go and interview the final interview in their own functions or it can be cross-functional?
Ashwin:
It can be cross-functional because again, the thing that these people are looking for is this person’s ability to move quickly without needing to wait for permission or decisions, dive deep into various areas. And they’re looking for evidence that this person has done this in the past because in terms of competency at the function, that’s what we expect the regular interview process to do. And you’re right, we’re hiring a lot of people. So a lot of people that are interviewing might themselves be newer, but we always make sure that the hiring manager himself is extremely competent at interviewing capability for that function. Even to this day for managers, both Jesse and I are reasonably involved.
Nakul:
Is there a cultural expectation that every employee at Decagon has to be AI native, their AI savviness across engineers is probably easier because they are in the thing, but hiring customer support person, customer success, sales, do your sales reps need to be AI native? Are you testing for that in the recruiting process?
Ashwin:
Pretty much everybody across Decagon has embraced AI, also because of the product that we sell. If you look at each of the three orgs sales and everything pre-sales, post-sales and EPD, on the EPD side, of course, it’s much more understandable that everybody is building with AI. On the post-sales side, interestingly enough, we have built an AI agent that handles Decagon, implements Decagon. Actually, we announced this maybe a week ago called Duet. So the post-sales team is building a lot of their Decagon implementation and everything through Duet. We’ve built out the ability for Duet to be taught new skills on how to implement Decagon, things like that. So everybody on the post-sales side is pretty AI native at this point because of the kinds of work that they do. And on the pre-sales side, again, we’ve used a whole range of AI tools, everything from, “Hey, how can you help me prep for this meeting better? How can you help me find new accounts better?” Things like that.
Nakul:
But is there a recruiting criteria, you need to see some AI nativeness in the person or no?
Ashwin:
I think on the EPD side, yes. In fact, we’ve rebuilt a lot of our interviews. I wouldn’t go so far as to say it requires AI, but honestly to do a pretty good job and build out as much as you need, you either have to be one of the fastest coders in the world, in which case, great, we will hire anyway, please, or you probably need to be pretty good at AI coding. On the pre-sales side, we haven’t required it as much because we’re like, “Hey, these are skills that if you’re very good at your job otherwise, you can pick these up pretty quickly and we’re happy to help.”
Nakul:
I’m actually curious, have there been senior business execs who’ve built a lot of their career in the pre-AI world who are laggards and who you had to kind of, “Hey, no, no, this thing is like-
Ashwin:
Not as much at Decagon because again, of the kind of person that we pull in and recruit for. And also this is probably a kind of person that says, “Hey, I want to opt into working at an early stage startup that is moving pretty quickly.” And again, that’s the kind of person again that’s like, “I want to use the latest and greatest stuff.”
Nakul:
So let’s now dive into each of the individual functions for a bit. So let’s start with engineering. At this point, are your engineers even writing code at all?
Ashwin:
Yeah, it’s a great question. I think I would say at this point, the vast majority of code that is written is written by Claude Code, Cursor, Cognition, Devin, but we still expect our engineers to understand what was written and essentially sign off on it and saying, “Hey, I’ve pushed this PR, I’m fine with it.” Right now we want to give them all the support around that. So for instance, we’ve spent a lot of time investing in how do we set up our code base to be easy to use AI with, right? How do we create good documentation in the code base? How do we split it up in a way that the agents can understand? How do we create good Claude MD files if you’re using Claude Code, for instance, so that as an engineer now picking it up, you can get started very quickly.
Similarly, on the review and testing side, we’ve invested a lot in saying, how can we find issues very quickly? How can we automate checking for style issues and structural issues and things like that and security issues, of course. But we still expect the engineer to be responsible. We say, “Hey, use all the tools you have available so that you can move faster, but at the end of the day, you are responsible for the code you push and you should be prepared to defend it rather than say, “Oh, the AI agent wrote it. That’s all I know.”
Nakul:
Do you mind sharing whatever you can on what’s the engineering stack at Decagon now in terms of course, what AI tools that you guys are using?
Ashwin:
So interestingly enough, we subscribe to all of them at this point because engineers have their preferences on what they would like to use. So we have some engineers that use Claude Code, we have some engineers that use Devin, we have some engineers that use Cursor and we have some engineers using Codex and we are fine with whatever they want to use because ultimately we view this as an accelerant to building and so we’re not opinionated on what they use. So the things that we do on the EPD org to help is number one, making sure that the code base is well set up initially to be able to work with these kinds of agents and number two, ensuring that everything downstream can handle now the increased rate at which PRs are created, testing reviews and things like that that would otherwise become bottlenecks. But in terms of the tools themselves, we actually partner with all of those folks.
Nakul:
Testing security, enterprise readiness of the code at this pace of code gen, and you guys are selling to some of the largest organizations in the world and these people probably have low tolerance for customer support, or you’re giving them something that deals with their customers. So have there been some fuck-ups in the journey? Have there been areas where you’re like, “Guys, we need to be really, really strong on this. We can’t just adopt AI.”
Ashwin:
On the security side, we’ve been very, very tight, no issues there because again, from the very early days, right from day one where we work with extremely large enterprises that are trusting us with extremely sensitive pieces of data. So even from the very early days, security was always very tightly maintained. And the way that we actually go about operationalizing this is several fold. One is ensuring that your coding practices itself make it hard to mess up. So for instance, requiring that when you create a new route and you automatically add authorization tag, it just does all the best practices for you. So it’s kind of essentially we make it harder to mess up on the security side. Second, a lot of our PRs explicitly look for certain kinds of security issues. Third, we have a application security team in house that’s constantly doing pen test, that’s constantly doing reviews on any changes to anything sensitive. And fourth, we are getting pen tested externally all the time. So really something would have to go through lots of misses for there to be any kind of impact.
Nakul:
How does the IC engineering role change in these starting from six months ago when Claude Code seemed to have made a very step function difference to the next one to two years?
Ashwin:
So I think the IC engineer’s role changes to being able to just iterate really fast. Back in the day when you had a very high cost to trying something, the correct thing to do was say, “I’m going to spend a lot of time planning because if I do something incorrectly, it’s going to take me even more time to fix it.” Now essentially what we’re doing is we need to push a lot more of that planning and thinking into one engineer’s head because they can autonomously run for a really long period of time. So the way that the IC engineer’s role changes is being able to say, “Okay, my job is no longer just taking a well fleshed out PRD and just executing against it to getting a much more vague PRD with not all of the pieces filled out and saying, ‘I’m going to be able to try things for each of these things that are unfinished and develop good taste on what the right final thing should be.’” Because that again constrains the development cycle substantially, right?
I don’t need to wait for PM to come in and review this. I don’t need to wait to have three meetings with people to figure out what the right thing is. Now because of this, I think the VP engineering and VP products job changed substantially because since you have these small teams that are moving very, very fast without as much time to coordinate between them, the job of EPD leadership becomes to very clearly paint the targets of where we want to go. Because the moment you do that for a specific week, a hundred micro decisions will be made without you. And to ensure that everyone is rowing in the same direction, achieving the same kinds of goals, your job on EPE leadership is to figure out very clearly and articulate very clearly what are the core problems we’re trying to solve, who is responsible for solving each of those things and if there are big cross team decisions, being able to very clearly point out what those are and what the decisions were.
Nakul:
EPD leadership has just not created a lot of noise or surface area for too many micro decisions being made, I have to pay attention to so much of this.
Ashwin:
Yeah, no, you’re absolutely right. So I think effectively what the job has become is to be able to define these kind of higher level goals without being opinionated on how they’re implemented. So for instance, you should be able to say, “Look, we built agents, so we need a good solution to be able to test agents well.” And maybe say two or three sub bullets under that in terms of, “Hey, here are the kinds of things it should do-
Ashwin:
Please sub bullets under that in terms of, “Hey, here are the kinds of things it should do,” and not be as opinionated on, “Oh, exactly how do we accomplish each of these?” Because if you can say, “Okay, this piece on how an agent is tested with the three sub specifics is done,” and you just trust that, okay, this person’s going to do it. And now you look at a separate thing. Essentially what you’re looking for is you have these services and you have contracts between them and you’re not as opinionated on how each of those things is built. And as an EPD leader, your job is to be able to draw these clean lines and say, “Here are the interfaces. This is what each part should do.” I’m not opinionated on how it is built because I know all of those decisions will be made very, very quickly without me, and team should just be able to trust that everything on that side of the house will get done.
Nakul:
Actually, as we are having this conversation, I wonder if Steve Jobs had a great quote, focuses about saying that. And in the prior era where the cost was, “Hey, if I try 15 different things, it takes time to build it takes times to fix mistake.” Now, you’re saying actually it doesn’t take as much time to build it and it doesn’t take as much time to fix mistakes. Do you actually feel your advice would be to say yes more to EPD leaders?
Ashwin:
I think it’s actually in between where it would be try a lot of things because what you don’t want to do is give the customer at the end of the day wants their problem solved and ideally they want their problem solved in the simplest possible way. And we run into this all the time. If you go into a customer and say, “Here is a product, and by the way, here is 500 different things that you could do to make this fit exactly like you.” The customer just wants their problem solved. So it is our job to be able to abstract away a lot of this complexity from them. So we try a lot of things. We try a lot of different solutions, but we want to go to the customer and say, “Hey, this is the right one for you.” So I think that the adage on simplicity still holds.
Nakul:
So let’s shift towards FTE org, customer success/FTE. And that’s an interesting area for AI because it’s a lot of FTE motion right now in AI. You yourself were at Palantir. How has the FTE motion evolved since your Palantir days to where AI is today in the enterprise?
Ashwin:
I think this is an important point because I think this gets mistaken a lot in this space. There are actually two types of FTE work and I think when people talk about on Twitter, they conflate the two, and I think this is dangerous. The reason is the first type of FTE work is what is more typically understood as FTE work, even historically, this ability to say, “I’m going to go in and build the last-mile of software and integrations for this end customer because no one else is going to want anything like that ever again.” And it is truly bespoke consulting work. The second type of FTE motion is saying, “There is a lot of product I haven’t built yet, and so this is not going to be usable for my customer, but this is product stuff that I need to build anyway.” Now, the reason I think there is a lot of this type of work today, the second type is because there’s a lot of net new product thinking.
So for instance, if you were starting a CRM company or a sales automation company, there’s been 10 years of product thinking on what are the user journeys, what are the kinds of things that I need to support? What are the kinds of workflows my users expect of me? But with AI tools, all of this is so new that the users themselves don’t know what kinds of workflows they need to support until they start using it. So I think the job of the second kind of FTE is honestly just a product engineer that happens to sit next to users and see what the issues they’re facing are and build it correctly into the product. I think confusing the two can be very tricky and dangerous because if you are the second kind of FTE, and this is actually the kind of FTE I think most AI companies need today, your job is to figure out what is the generalizable product thing that I need to understand from my end users and build into the product. And I think this gets conflated a lot because everyone just calls them FTEs.
Nakul:
Yeah, I 100% agree with you. I’m seeing this across our portfolio also, but then accordingly, what’s the right background for that kind of an FTE, the person who can generalize it? Is it a product person?
Ashwin:
Yes, it’s ideally a really good product engineer that can both empathize with the user, understand what the generalizable thing is and build it, because now this engineer can move way faster than before, but otherwise an engineer and a product person, kind of pair them together.
Nakul:
And then obviously every, you touched on this already, but every FTE org runs into the tension of how much of this is permanent services and a permanent drag on the gross margins, people dependence versus how much of this will get productized across the portfolio of customers. Have you guys had that tension at all or this framework that you just shared is pretty disciplined in how your FTEs approach the entire business?
Ashwin:
For us, we don’t feel this tension as much because we view all of this kind of last-mile work as helping us find the right configuration points within the org, right? Because we think two things are true. We think that one, there exists enough configuration points to help you build something that feels completely bespoke and it’s just a matter of finding those right configuration points. For instance, you could say that, “Look, every integration is going to be bespoke work.” Because by definition, someone that has a in house build of some service that they built themselves in house, you’re never going to be able to have a product integration for that. But our view was, great, the way that we’re going to do it is our product itself is going to have an integration service where you can build an integration into anything directly within the product, and now we’re going to have a coding agent help you build that within product again.
So that last-mile integration work goes from, “Oh, I need to create PRs and things like that to integrate internal services too.” “No, you can actually do most of it within the product because we built this generic integration builder and coding agents to help you do it.”
Nakul:
Is your FTE organization, I know you have an agent builder or are they building agents for their own work to get automated?
Ashwin:
Yes, actually. So interestingly enough, again, we launched this as Duet a week or so ago and interestingly enough, we use Duet to build Decagon agents. Duet itself is a Decagon agent. So we built Duet on top of Decagon. So anytime people on the agent building team need to expand the capabilities of Duet, make it do things before, it’s just a Decagon agent. There is an instance of Decagon for it. So they just go in, expand the Decagon agent and now, “Oh, Duet can do more things and now it can do it across the entire customer base.”
Nakul:
Let’s shift towards your sales org. How pervasive is the use of AI in your sales and marketing org? Are you guys using AI, SDR tools and stuff like that?
Ashwin:
Yeah, no, absolutely. Exactly. Like in EPD, we view these tools as accelerating people’s progress substantially. And today I would say AI isn’t yet good enough to be able to do an entire sales cycle end-to-end for our kind of customer base. We think it’ll get there eventually. It’s not there today, but absolutely everything from prospecting to meeting prep to documentation updates to deal cycle reviews, we use kind of AI tooling.
Nakul:
Do you believe in the world where SDRs won’t exist and it’ll be only AI agents? Or do you believe in a world where each SDR will be 5X, 10X more productive because of AI?
Ashwin:
I think for a while the SDR role will be 5X, 10X more productive because of AI. There’s a lot of people building interesting products in this space and maybe that will change, but I think for the next while it’s going to be an AI agent and SDR is 5 to 10X more productive.
Nakul:
Because you guys sell into very large enterprises. So it’s consultative selling and the market is also competitive. Has the AE role actually changed because of AI or not really?
Ashwin:
I think the fundamental nature of the role hasn’t changed yet. In the same way that I think the fundamental nature of EPD hasn’t changed, but I think it’s changed less actually because ultimately if I’m in AE, I have two goals, and just two. Number one, if you’re an end customer, I need to understand what your pain is, and two, I need to show you how my product can solve your pain. And given that everything is interpersonal, I think there’s a lot of work around this motion that has been accelerated by AI. So finding the right person, prepping for the meeting correctly, doing the post call work better with AI. But I think the meeting itself where I’m understanding your problem and I’m showing you things about my product that solve your problem, I think that hasn’t changed yet.
Nakul:
How much AI is being used in your sales efforts? Let’s talk more about the AE side than SDR. SDR makes sense, but based on what you just said, is there much AI being used in your sales team?
Ashwin:
There is, because again, there’s a lot of overhead in sales. I need to take notes during my call. I need to update my Salesforce records. I need to provide proper roll-out. So there’s effectively all of this work that honestly most reps hate doing. All of the work around it can be helped quite a lot so that you can say, “Hey, as the AE, go do what only you can do today,” and kind of focus on that and offload all of the busy work around it to AI.
Nakul:
In recent times, Ramp, as an example, has taken a pretty aggressive becoming an AI-native company stands to release something called Ramp Plus that Div talked about. Have you guys built internal tooling at Decagon that kind of is a connective tissue across the company?
Ashwin:
So we’ve built a slightly different version of this, again, called Duet also built on Decagon, and it’s very focused on Decagon product itself. So we effectively built it for our end customers and ourselves internally to be able to understand the health of Decagon deployments to help people build better agents faster, and effectively do everything within Decagon. So the big switch for us internally was we think there are kind of three phases to these AI agents. And let’s use Decagon as an example. Phase number one is where you do the work. Phase number two is where you decide what needs to be done, and you tell an AI agent and the AI agent does the work. And phase number three, which is what we effectively built the app for is, the work gets done and anytime you need to make a decision, it pauses and comes and asks you for approval.
So it’s not even your job to think about what needs to get done because all of it is just getting done autonomously all the time. And whenever there needs to be human in the loop decision, it’ll just pause and come ask you questions. So it’s a different kind of thing than what the Ramp team does. We have a ton of respect for the Ramp team, but the place where we focused our AI agent was kind of on Decagon deployments themselves.
Nakul:
Do you foresee in the way you just described it three years from now, what is the role of the human at Decagon?
Ashwin:
I think there’s still going to need to be people for a few things. Again, I think for a while, everything on the customer side is going to end up being human to human. This idea of understanding what your core problems are. Now once we do that, perhaps we have everything downstream from there handled by AI agents because AI agents listen to the calls, AI agents listen to all the calls, they prioritize the features, they build out the features, PRs that are created and you have other AI agents that review the PRs and ship them into production. Once you do that, you have AI agents write the call notes. I think getting all of these to work exactly is going to take a little bit of time. So I think until that happens, you’re always going to have humans at kind of each of these stages.
Nakul:
How are you and Jesse using AI day-to-day for your own leadership and call it your third co-founder, as your third co-founder?
Ashwin:
Honestly, it’s for a lot of personal leverage because at this point there are so many things happening in the company that being able to see everything is difficult. So a lot of it is training AI agents with skills and other kinds of things to say, “Here are the kinds of things I want to know about. Now here’s a raw stream of everything, flag things to me that I would like to see and just give me a quick summary of everything else.” Health of these accounts, because again, we have Slack channels for everybody. Just tell me if anything is going wrong that I should pay attention to because otherwise the team has got it. They’re doing a good job anyway.
Nakul:
Where do you not trust AI for your leadership or giving you leverage?
Ashwin:
When there are people issues. I think people issues are always more complicated and really it’s about sitting down with people and understanding what their problems are and talking to them one-on-one. I think AI is good when there are these external artifacts that you can use that are external calls. I can review the calls and that is the full truth of what happened there. Customer health, we are pretty open in our Slack now. Interpersonal issues is never the full story until you really sit down with someone and have a conversation with them.
Nakul:
Do you have thoughts on how your own role might evolve in three years with everything that’s happening around you with AI, your orgs getting more automated, their roles evolving. So how does your role evolve?
Ashwin:
I think my role in a way I don’t think will change that much because as having an executive team, I rely on them to do a lot of the work within their orgs. So now whether that is an executive or an AI agent or an executive sitting on top of a team of AI agents or a team of people, I think doesn’t actually fundamentally change my job, which is making sure as a company we’re building the right things, we’re growing at the right place, we are hiring the right people. And maybe it’s hiring the right people. We have the capacity to do all the things that we need to do. We have capital and the bank to do what we need to do. I think fundamentally all of those things probably don’t change.
Nakul:
You guys are in the rare position. There are probably like only like 10 AI-native companies where you started in 23 after ChatGPT came out, which has had similar success. There are probably not more than 10. If somebody were to start a company today in terms of the AI-native org aspect of it, what would be your recommendation to founders starting today?
Ashwin:
Really the highest leverage place today for AI agents is probably in EPD. If you’re starting a company, that’s almost certainly where you need to be focusing all your time anyway. So really put a lot of thought into how you can create this kind of agent factory where you have a code base that is approachable by AI, where you can have AI agents try things out, where you have AI agents that can review the work, essentially treat building out this factory as a product in itself, and that’ll substantially increase your velocity at building things, which means that increases your velocity at trying things, which means you can put stuff in front of customers faster, which probably increase your chances of success by quite a lot.
Nakul:
Let’s talk about moats because a lot of discussion in AI enterprise layer or application there is about Anthropic is attacking my business and stuff like that. And you’ve had thoughts on this about like if 90% of your value is about which model to use, you’re going to get screwed. How do you guys think about moats at Decagon if at all?
Ashwin:
No, we definitely think about it. However, I think the underlying question might have been, “Well, what if the model labs come and decide to do this?” When we think of the kind of products that we’re building and the kinds of users that we serve, there is a lot of software that we build after the model layer. And we think we have tremendous amount of respect for all of the model companies that are building incredible things, but when we need to operationalize some of the work that we do at these large enterprises, after the model comes, okay, well, we need governance and versioning because you can’t just save something and have it go out.
We need the ability for our 10,000 employees to collaborate and build the right kinds of agents. Now, when we’re having millions of conversations, we need a way to do analytics and insights and QA and things like that. And now we have internal systems, we need a way to build these bespoke integrations into our legacy thing and you kind of have this long tail of just SaaS software that you need to build to make something like this work, which we don’t really see the model labs wanting to do.
Nakul:
Would it be fair to extend your thought in saying, “Hey, people think of AI as the end of SaaS, it’s really SaaS 3.0 or something like that.”
Ashwin:
I think this is true, and I think the kind of companies that are most at risk are the ones where one of two things is true. One is where they were building workflows for human beings to do, and now fundamentally human beings are not doing that kind of work. And two, when most of the value of the product can be replaced like 98% by a model doing the same work.
Nakul:
AI for customer support has become a pretty crowded space, right? You and Sierra were probably the first ones to go and attack this, and you guys are the leaders, but there’s more and more coming. How do you guys think about competitive differentiation and edge in a world where software can just be built faster, the 17th company entering the space can catch up to 80% of your features very fast.
Ashwin:
You’re right, things can be built very fast. So that requires us to also get good at building things very fast. And I think there are two big competitive barriers here in a way. One is just deep understanding of the customer issues because the problems that enterprises have are complex, and we’ve just spent years at this point embedding very deeply with them, understanding the nuances that they have to be able to build and deploy these agents well. And I think that learning takes a lot of time to get to.
And number two, there is actually still a lot of technical difficulty to being able to do this very well. And what we found is our enterprise buyers are pretty discerning customers. These are sophisticated buyers. They’ve thought about the problem. They’re able to evaluate these solutions very well. Someone that is doing something at 80% versus 100%, you actually get weeded out pretty quickly because these enterprises, again, they have options and they want to pick the best one. For this reason was why we started things like Decagon Labs because we do a lot of our own model training in-house. And so I would say at-
Ashwin:
... Because we do a lot of our own model training in house. And so I would say at this point, probably about 90% of all of our model traffic is through models that we build ourselves in house.
Nakul:
Yeah. Actually, maybe double click on Decagon Labs. You released it, what, a month ago, two months ago?
Ashwin:
Yeah.
Nakul:
Why do you need Decagon Labs to stay at the cutting edge when model capabilities are already getting better and parallel people are spending billions of dollars? Why does Decagon need to build its own model?
Ashwin:
It’s a great question. The thing that we’ve found is that at the frontier of capability, model performance is actually pretty jagged. By which I mean, just because you have a model that advances a lot in one capability doesn’t mean that it does that in every capability. And in fact, in certain cases it might regress. Now, let me give you a specific example. For our use case, we use a whole constellation of models in each interaction with an end customer and we care about each of these models doing a few specific things. Now, I don’t care about that model being good at coding. I don’t care about that model being good at writing poetry. I care about a few very specific qualities. Now, if I use the frontier model for everything, in a way, I’m kind of wasting a lot of parameters in capabilities that I don’t care about.
And so, in our experience, you can get a model to do better at the few things that you care about, in a smaller model, which is hence faster and cheaper. And so therefore, if we want to create the best customer experience, we should fine tune and build a lot of those models ourselves, because we get everything better performance, cheaper and faster.
Nakul:
I’m curious, how do you decide what to build in house versus where to partner? So voice is clearly a core aspect of customer support. How do you decide we should build voice models in house versus partner with existing providers?
Ashwin:
Our general approach to everything here is what can give us the best customer experience the quickest, right? By which, if we can get best in class from a partner, we will always do that. If we think we can do better ourselves, because it is better for the end customer, then we build ourselves. I think this example of Decagon Labs was a great one where for the capabilities, for the kinds of models where we think, you know what? A frontier model does do the best. We can’t improve on it all that much if we do it in house, great. I would prefer to partner with someone, because again, now we get to leverage their R&D spend and capabilities automatically get better. Whereas in cases where I think we can build better and it is crucial to the end customer experience, those are the things that we build in house.
I’m not too sensitive to saying, oh, this is really important so we must do it in house ourselves. Everything is about where can we improve on the end customer experience.
Nakul:
In your most paranoid self, where do you and Jesse worry about, hey, if the frontier labs keep pushing, this is where we get cooked? And then how do you think about, is it going back to all the orchestration and the software around the agent? Maybe talk about the paranoid itself a little bit.
Ashwin:
As I’m sure every startup analyst is paranoid about lots of things. Luckily, that isn’t actually a top five concern, because again, our view of the world is that there’s so much software that you need to build around the core models to make these things work at enterprise scale, that we don’t think that is where primary competition comes from. Now, of course, I’m worried about loss of other people building similar things or competitive pressures or market dynamics or things like that. Luckily, the model labs are not one of them.
Nakul:
That’s a good steer into the inner game section that I wanted to cover with you. What worries you most at your perch today?
Ashwin:
It’s actually two things. One, interesting enough, is hiring. This is probably the number one thing on my mind, because I think it’s clear that the market opportunities here. There are a lot of buyers, there are a lot of customers that need the product that we’ve built, but to service them well, we do need a team that can do this. Again, we have customers all around the world and that just requires a lot of complexity to service well. And so, we need to hire people very, very quickly. And so there are two issues here. One is we don’t hire fast enough to be able to meet the market demand and then we kind of fall short of where we could have been as a company. And number two, which is equally bad, is, or perhaps worse is, we hire the wrong kinds of people because we are in such a rush to hire.
And I think both of those can have pretty serious effects to us as a company downstream. So I spent a lot of time thinking about this.
Nakul:
What about the competitive pressure? Is that a concern at all, that everybody’s attacking this gigantic space that you proved has an insanely large market pull?
Ashwin:
Interesting enough, not as much as this, because I think in a way I’m most concerned about, hey, what are the things that could seriously affect us as a company? And at this point we’re growing fast enough. I think we’ve proven out our product for a lot of enterprises that this won’t come from competitors that try to build and push us out. It’ll come from basically us having indigestion, trying to bite off too much and not hire well enough or not hire quickly enough. And I think that is more likely to kind of slow us down than competitor comes in and tries to do something.
Nakul:
Taking a slight step back beyond the over intellectualization point you made, that both of you probably had some scar tissue from a prior startup. Are there any other lessons that both of you were bringing to the first few days of Decagon and how that have stayed true for this journey?
Ashwin:
The biggest one probably remains don’t over intellectualize and listen to your customer, because in a way, it’s also the only one that matters. Because if you build a company, doing something that your customers care about, you can mess up everything else in a way and it doesn’t really matter. And conversely, you could do everything else right and not really build something that people really care about having. And also again, nothing else matters. So in a way, it’s kind of pure. It’s just this one thing, and if you focus on that, don’t worry about everything else. Everything else will work itself out.
Nakul:
And it’s also clear from your culture, even in my prior interactions with you, you guys move at an extremely high pace. It’s part of the culture, cultural values and stuff. Does that get tiring as the leader? Because there’s a little bit of a mental capacity that it takes to drive the organization week in, week out, day in, day out, probably in every interaction. How are you managing your psyche driving this organization at this pace?
Ashwin:
I think maybe this goes back to when I was growing up, this is back in India, I used to spend a lot of time doing these competitive Olympiads. There’s this one particularly intense period. This was in eighth grade. You had the NTSC, the National Talent Search Exam. And this was in eighth grade and they test you on everything, like history, chemistry, geography, physics, like everything. And I remember the prep for that, that entire summer was I would wake up at five o’clock in the morning and for the first hour I would do history. And then for the next hour I would do geography, and then I would take a 30-minute break to have breakfast and then I was fresh again. So for the next hour I would do physics, the next hour I would do chemistry and I would take a 30-minute break to shower and I was fresh again.
So in the next hour I would do math and so on. And I would do this every day, from 5:00 in the morning till I went to sleep at around 8:30 at night, and I did nothing else except this for that entire summer. And this was roughly the schedule, probably from like fourth grade to like 12th grade. And so, in a way, I’m somewhat used to this and now all of a sudden I get to come in here and there’s a lot of people and I’m having fun hanging out with people. So in a way, this is much easier for me in a way, rather than sitting by myself in a room and just working alone. It is challenging, but I’m like, oh, if I did that, this is all of a sudden much easier.
Nakul:
Well, let me double click on that. So that you did, I can see it in the way you... This is a much more rewarding journey, you’re building a great company, but there’s a people aspect of it. Now you’re not just driving yourself, you’re actually confronting slowness in your organization, you’re confronting issues. Does the people aspect become tiring for you?
Ashwin:
The nice part about having been one of the co-founders is you get to pick the people that you work with. And I love our executive team, because they’re also all people that care about the same kinds of things and have the same kinds of values. So my job just becomes spotting things that they might have missed otherwise. And again, if they were the kinds of people that would push back, then you’re right, it would be extremely tiring, because it would just be a whole set of arguments. But they’re actually great, because once you point out, they’re like, oh yes, you’re right. Let me go fix that problem.
Nakul:
So psyche management doesn’t seem to be a thing that you either needed or might, maybe you’re just...
Ashwin:
No, the psyche management thing, I think matters in places, not in this one luckily, but I think it matters in a few other places. One, you’re right, if you push too hard, you can get burnt out. So we actually, Jesse and I have had actual conversations with each other. We’re like, hey, how do we make sure this doesn’t happen? Because again, we want to build this company for the next 20 years. And yes, burning yourself out is a real thing. So we take our Saturdays off and we actually take that fairly seriously to be able to decompress. Number two, I actually ended up talking to a number of sports coaches actually, because there’s a lot of similarities between high performance sports and building company. There’s a lot of pressure, honestly, that you also put on yourself. And there’s a lot of kind of visibility into how you’re doing.
So being able to separate, here are the things in my control, here are the things that I can fix, and here are the issues that I need to work on. Whereas here are outputs that I can’t stress too much about, is actually very important, because even today we take every deal loss very seriously and personally. It’s like, okay, we lost this deal, it’s okay. We need to strip it down, remove the emotion from it, figure out why we lost, figure out what are the processes that caused us to lose, and kind of look at it a little more analytically, because otherwise, yes, you’re right, it can crush you. But yes, we put a lot of time into thinking about these things to make sure that you can kind of stay sharp for the long haul.
Nakul:
From a distance, somebody looking in Decagon seems like a straight up into the right story. You guys started it, the fundamental ingredients were great, the market size was large, you guys are moving at an insane pace. Have there been hiccups in the journey so far in this one? I know prior startups, you may have some stories, but in the Decagon journey, have there been any hiccups where you guys felt, man, today was rough?
Ashwin:
There’s been probably a 1,000 of those, like in every company. I think the thing about every company is, from the outside, everything looks amazing. But I guarantee you, every fast-growing company probably without a single exception, they’ve had a 1,000 fires internally, which I think that’s kind of the nature of things. As you grow quickly, as you have a lot of people, as you have competitive markets, just things are bound to go wrong. The person that you hired, that you thought was amazing, wasn’t, and then they messed a lot of things up. The deal that you thought was a for sure thing, that you were going to win, that you built a lot around for, you lose at the last minute. So all of these things happen and I think they happen to everybody. And so, I think a part of it is spending a lot of time realizing that, you know what? It’s okay. It happens. I know you had Frank Sloupman on your podcast a while ago.
Nakul:
Yeah.
Ashwin:
So Jesse and I were talking to him maybe two weeks ago and he was the one that was telling us, he was like, Snowflake was his third company that he scaled and he was like, “You know what? I was anxious the entire time, because there were always things blowing up.” And so for us, we’re also like, okay, this is someone that has built three generational companies, was also anxious the entire time. It’s just normal, that’s just how it is.
Nakul:
I actually asked him the specific question that, “Did you ever have doubt on yourself?” And his literal answer was, “All the time.” So next up is our quick fire round. First one is most overrated advice in AI in founder circles right now.
Ashwin:
Hire a lot of FTEs, because FTEs are necessary. Again, I think they’re necessary for the early days, but only if you think of it as that second type of FTE, otherwise, you’re asking for trouble.
Nakul:
The AI company other than Decagon that you admire the most.
Ashwin:
We have a lot of respect for the folks at Ramp, because they would in a way, have every excuse to not be an AI company, but they’ve just built incredible things.
Nakul:
Personal favorite AI product, other than ChatGPT and Claude?
Ashwin:
I use Whispr Flow a lot, actually, because again, now I do a lot of Slacks, I do a lot of emails and I can talk way faster than I can type.
Nakul:
I swear to God, that company must have the highest NPS. It is one of my top two personal favorites also, and I know so many people who just swear by it.
Ashwin:
Yeah, it’s a great product.
Nakul:
One book every AI founder should read.
Ashwin:
Probably two come to mind if it’s okay. One, there’s this biography on the Wright brothers that I think was pretty interesting, because again, it talks about the cycle of invention in a way. I think one of the interesting anecdotes from that book was about how, once they built the airplane, you would think that there would have been incredible pull for this. I mean, obviously this invented a flying machine that nobody ever had. Do you know how long it took them to convince the US Army to buy their first airplane? Six years. The point was just, even if you have these amazing, incredible inventions, it takes a lot of time to educate the customer on why this is necessary, how to adopt it and things like that. And it’s not just you build an amazing thing and they will come. It’s also important of good go to market in a way.
The second was this book called Creativity, Inc. By Ed Catmull, from Pixar and it talks a lot about how they built this culture of creativity into the company, which I think is probably very, very important for companies, especially today when so much stuff is changing and you can rethink everything from the ground up.
Nakul:
Red flag in a candidate that you never ignore when recruiting.
Ashwin:
I actually changed my mind on this a little bit over the last several years, having hired so many people. It’s not a specific flag, but rather that like gut feeling of something’s a little off and I’m not sure I want to pull the trigger on this, because there have been times when I’ve kind of ignored that and said, look, I’m looking at everybody’s reports. Everybody loves this [inaudible 01:12:19]. I’m looking at their background. It’s amazing. I’m looking at everything that my notes from my interview and they answered everything correctly, but something doesn’t sit right with me. And I used to say, “You know what? That’s okay, because I should be objective. Let’s look at this clinically.” And every single time I’ve been like, I have regretted that hire. And so, now it’s just this unsettling, maybe I shouldn’t do this, that I now take very, very seriously when I have.
Nakul:
Last question. So you’ve had a phenomenal run and it’s just a beginning still, but if you could go back to the day you and Jesse were starting Decagon, knowing everything you know now about the journey, what would be the one thing you’d tell both of yourselves?
Ashwin:
It is go faster and kind of play to win. The market is so much larger and moving so much faster than either of us had thought of at the time. So it would be go faster, hire faster, build faster, get out to the biggest customers faster, because the need is real, the market pull is real. You just need to go capture as much of it as quickly as you can.
Nakul:
Great. Ashwin, this has been a pleasure. Thanks for coming on.
Ashwin:
Yeah, thanks for having me.
