Determining when to leave to start your own company, making strategic bets, and selling to enterprise customers w/ Anhang Zhu @ TierZero

Speaker A: Hey, Zay. Um, welcome to our show. Thanks, ah, for coming here.

Speaker B: Yeah, thank you.

Speaker A: Um, I'm really excited to talk to you about how you transitioned from a new leader to become a, uh, founder, um, and building really awesome products and, uh, also an AI native company. So, um, before we jump into it, uh, would you m. Mind sharing a bit more about yourself?

Speaker B: Yeah, of course. Um, my name is Az. Started, uh, Tier zero about two, two and a half years ago. Now, um, we build software. We build AI agents to help with software production. Talk about what that means later. But, um, you know, before this, I spent three, uh, years at, uh, Niantic. I owned the platform and parts, ah, of the infrastructure for Pokemon Go. Um, and before that was a startup founder, built a AI coach for gamers. This is pre ll a lot of fun. And that was acquired by Niantic. That's how our team, um, joined there. Uh, and before that spent six years at Facebook. One of the first engineers on the Ads team. The claim to fame. We built the very first React app. Had a lot of back and forth with the React team on what should go into the initial version of React and whatnot. Um, but, yeah, over the years, uh, seen a lot of ways that systems have failed. Uh, and so when I left Niantic, wanted to really build software to help engineers and engineering leaders like myself, they never have to worry about firefighting.

Speaker A: It's a big transition from, um, an engineer, then a new leader and founder. Maybe you can help us to navigate from being engineer and being a builder, uh, inside of a big company and how that idea of creating a startup, uh, came up to you.

Speaker B: Yeah, so I've always wanted to start companies. Since high school. I wanted to start companies and I did a, uh, couple side projects. But I think really when I graduated college, um, I was working on a startup already. And the quick story there is I had two co founders and they ended up getting jobs at Big Tech. I said to myself, okay, I guess I should go get a job. So I went to Facebook. A good friend of mine who I respect a lot, he was there as an engineer and I followed him there. Every year I think about, okay, is this the year? Is this the year? Should I go start something? Should I leave? Um, I thought about leaving or almost left, uh, three years in, and then I finally actually left six years in. But, uh, I think when I made those decisions, the main thing I wanted to learn at Facebook was 1, how do I take a product from 0 to 1? And so I went after teams that were literally Building brand new products. So I had the opportunity to work on Facebook business manager, literally first line of code, um, to where it was when I left, which was all of Facebook revenue was going through it. And I think the main thing to compare with, you know, between big tech and a startup is I think big tech, the first thing that stands out is just it has a lot of, uh, support for you. You know, I built 01 products at Facebook, but it's nothing like building it yourself outside of Facebook. Just the amount of support, the amount of talent, people you can ask, amount of machines at a time that you can use. And also it's very easy to underestimate, like when you ship something at Facebook and it works, is it you or is it Facebook's own network effect? Yeah, and I think a lot of people conflate that. But yeah, I think that's, that's the biggest thing, uh, is just, you know, you get a lot of support and you know you're going to be missing a lot of.

Speaker A: Yeah, there are a lot of things you take for granted.

Speaker B: For sure, for sure.

Speaker A: I remember that when I, my first company at Amazon and they have an advanced deployment system called Apollo. When I switched to um, a small company, I was surprised this didn't have a deployment system. So, um, it's actually.

Speaker B: Yeah, it's funny you mentioned CI because my, uh, first startup when I left Facebook, it's a gaming company. And uh, I was just trying to build a website and I was like, how do I actually deploy this thing? And so I just ran Rsync. I just got a machine on DigitalOcean and just rsync'd it. I was like, okay, I guess this is how we deploy code. Uh, and then later on I realized that there is actually CI CD products and we started using Circle CI. I think at the time the one

Speaker A: thing you mentioned, uh, caught my attention is that you are kind of, from the very beginning, you know, you want to start a company. So you are proactively seeking out, um, roles and positions at Facebook, doing the kind of zero to one building phase. So that gives you more exposure. So can you break down the six years at Facebook and what are some of the roles that help you to get it ready for being a founder?

Speaker B: So when I first joined, uh, I was a new grad. This is December 2011. Facebook was actually working on a phone internally. I forgot the project name was called but never actually shipped. But, um, the phone needed a Photos app. So I was like, great, let me work on that app. So, uh, I Spent first three months actually just using a lot of linear algebra, uh, and applying that to CSS transformations to get, uh, image modifications. Working in this JavaScript OS. Pretty crazy, um, for, for the time. But that was just like me wanting to just like build something from scratch. And then later on that project shut down. And so I was deciding whether or not I go to, you know, a few different teams. But ads actually called out to me one because I think there is very high visibility. This was Facebook thinking about going to IPO and monetization. And Zuck is on stage saying, like, we need to make, I forget however many X billion dollars this year. So that was very exciting to me. It's like, okay, cool. Zuck cares about this, I should care about this. Um, so I think that's the first thing. I just talked to my manager at the time and uh, I said, I want to go work on ads. Um, so when I was assigned to ads, there's also a lot of different projects. And the first project that stood out to me was, uh, rewriting the ads creation flow from scratch. This is the interface that all advertisers will use to create ads on Facebook and it needs to be completely rewritten. And so I joined the team, worked on this product for about three to six months and it got to a pretty good state then. The next iteration was great. People are able to create ads. How do they manage ads? How do they see, you know, ads performance and things like that? So as manager, same thing, Almost a brand new rewrite and you know, this takes us to maybe two years in. That was actually when I thought about leaving. Okay, cool. I did two projects. Feels good. Um, I actually talked to my manager at the time and he convinced me to stay. He says, hey, you're going to start a company. I think that he was, he was actually a founder before this. He said, hey, you might want to think about these things, like how do you run a team, how do you build, uh, alignments and stuff like that. I was like, okay, cool. So went after another project. This is the business manager project, my last one. And this was literally brand new nothing. We had a team team. And, uh, saw that project end to end through and finally felt ready. I was technically on this team. We had a bunch of folks that, uh, I was sort of directing. And after that I felt pretty well versed on the technical side. And during this project I also had a lot more, um, exposure to the business side of things. I've talked to the advertisers, talked to the product marketing people. During this phase, we flew like all around the world to meet various firms. So yeah, so then I was like, okay, cool, I think I get it. I'm shipping this product. We're making money for Facebook. These are the people that are giving us money. I can see the business. Um, and then I felt pretty good about, okay, I think I have all the high level pictures. Let's try to do this ourselves.

Speaker A: Now I feel ready.

Speaker B: Now I felt ready.

Speaker A: Start your own thing.

Speaker B: Yeah.

Speaker A: And what happened next?

Speaker B: Uh, false confidence. Complete false confidence. When I left, first thing was, I don't know if this is salient advice or correct advice, but at the time the advice to me was, you should probably have an idea that you want to work on before you leave. But for me, I didn't really have an idea. I know. I just wanted to start a company because I think it's fun to build something from scratch. So I just left. I had no idea. I took a quick sabbatical, like a month. And uh, I was at home playing a bunch of video games with my roommate at the time. And we were just up to like two in the morning playing a bunch of games. This is like early days of Discord. You know, we met a bunch of wannabe, um, professional gamers and uh, and just hung out with, you know, these sounds bad, but I don't want to record this sounds bad. We, we end up playing a lot of like, uh, games with uh, like esports games with high schoolers, um, and saw that there's this trend that kids are growing up now with Discord, um, and with the idea that they can be a professional esports athlete. When we grew up, it was never a thing, but this new generation was a thing. And so we saw the opportunity of like, okay, cool, this is a new trend. Let's try to build something here. So it really was kind of very organic. We saw this behavior in people and wanted to build things to help. So that's how we stumbled upon sort of the esports coaching area.

Speaker A: How do you go about building the company, how do you assemble a team and how to figure out a business plan to make revenue?

Speaker B: We didn't have a business plan, to be honest. When we started. It was just, let's just build stuff. People clearly have a problem. Let's just build some stuff, get people to use it. Um, so I just hacked something, some stuff together. And then my co founder, he was like the product business person. Uh, he went on Reddit and Discord and just like found users and just like beg them to use our product. Uh, eventually we got um, you know, we maybe like 2% conversion and they started emails and whatever messages out, they started trying our product out. Uh, and some percent of them, uh, we saw, you know, they used a lot of it and turned out the people that used our product a lot was the coaches. So these are uh, high school college kids that are, you know, doing this for fun. They're coaching other people how to play the game better. And so by the way, the product we built uh, initially was a whiteboarding product. It's like a telestration product to go over game tape. So like uh, real athletes, they watch the game tape. Um, gamers, they do this with their games too. Um, so the coaches really used it for their students. And so we realized, oh, the coaches really cared about this, let's go after them. Uh, and we found coaching communities. We said, hey, try this out with your students. Eventually, uh, we went, I think a million users like in a month.

Speaker A: That's a lot.

Speaker B: Yeah, like coaches plus students. Yeah. So the distribution there was pretty quick and then. Okay, cool. Like we should like this is costing us a lot of money.

Speaker A: We're self funded but at this point there's no. It's all free.

Speaker B: It's all free. Yeah. And it was just server cost. Twilio, uh, cost. And yeah, I was paying for it out of my credit card. Right. Uh, because I set everything up. Yeah. So I told my, my co founder and I said hey dude, like let's go get some. We should probably pay for these services. So we started fundraising and uh, this is like pretty brutal. No one knows about us. Right. We're just kind of two no name people. So we called up everyone we knew and we asked them to intro us to everyone they knew that they knew. Eventually we were uh, introduced to the um, the guys at Afore Capital and Adam Etra there believed in what we were doing. Uh, we had a few calls and you know, I just remember this. I think it was like an after Thursday afternoon or something. He calls me up and say, hey, we like, we love to invest. And Ivan and I were in our, in our room because you know, we're living together with the phone on speaker and we're just like, oh my God, we got some money. We can pay for a surfer. Um, but yeah, after that they were very helpful and introduced us to more investors and it would put together a precede round of the time.

Speaker A: And what happened after that.

Speaker B: So once we, so we raised a little, I think about a million dollars at the time. And we started hiring. We hired a first engineer, he's like a friend of a friend and uh, he joined the team. So it's just three of us. And we applied to YC and got in. We're like, okay, let's do it. Um, we started doing YC and during YC we hired two more engineers. They're all just personal network, all my friends, we pull them out from various big tech I guess. And during YC we had some, we had, we went through a few different product iterations but during YC we uh, actually raised our Series A from Excel, um, before demo day. Um, even though that was like not what we're supposed to do. But uh, but we did it. Yeah. And then we had a team of five coming uh, out of YSC. This is like January 2028 and we had good usage. We're thinking about let's start charging people for the product. You know, people are it, things are growing. But then we hit a snag. Uh, we got a cease and deceased from Blizzard telling us hey, your product is actually helping the gamers win too many games. We think this is a cheating product helping them cheat the game. And we obviously disagree. We're like, we're coaching them. Right. But uh, at the end of the day own the games. Uh, so they have that. Right. Uh, and so we went back to the drawing board and this is like a pretty dark phase for the company. I think as a first time founder it was brutal to just navigate through. But at the end of the day we were able to sort of navigate out of that.

Speaker A: So um, from idea, you build something that you are playing games you fail to pin, you see there's a potential need, you prototype and validate it. Um, there's a real need and then go from there to first, uh, Reddit, convince user to uh, convince user to use it and then you get to a million coaches and users. That's a big step up. So what were the things, what else happened that led to that? 0 to a million users. Is that just a Reddit or. You mentioned that there's a community for. A community for coaches.

Speaker B: Yeah. So we started with like two or three people that believed in us and they were, they turned out to be pretty well known coaches. Overwatch. Coaches Overwatch is a Blizzard game and uh, they started using things and they used, they started publishing or They've always published YouTube videos, but they started publishing YouTube videos with us in it.

Speaker A: Right.

Speaker B: Like not a call out to our product, it's just the user product to create These videos and they're branded. You know, our company name. And so we got other coaches coming and asking, oh, if this coach is doing this, should I be doing this?

Speaker A: Great exposure.

Speaker B: Yeah. So it was great exposure. And the coaches are actually super connectors because they have like 30 students.

Speaker A: Right.

Speaker B: And they know other. Other coaches.

Speaker A: I suddenly find a network.

Speaker B: Yeah.

Speaker A: From one node. Yep. Then a, uh, lot of people hear about it. Yeah. Yeah.

Speaker B: Um, and it helps that it's a free product. We're just kind of giving it to the coaches for free. And so it sort of spread pretty virally that way.

Speaker A: And I'm sure you, the coaches are interested, um, because there's a. They have a real need and nobody el solving the need for them.

Speaker B: That's right. I think there before us, there were other people trying to build products for them, but no one is. I don't think it's all like, no professional software engineers are doing this. Right. They're like, sort of amateur, you know, maybe, you know, college kids. But it was really until. Not until we came along and built something really high quality and professional that the coaches felt like, oh, this is a really, a product that we can, uh, stand behind. It's not just like a jank product that we're using, but more of something that I can tell my students about because their brand on the line as well.

Speaker A: How do you convince, uh, your first semester to write a first check?

Speaker B: I think the product is only a proof point to the people, um, at that early of a stage. I really don't think that they invested in the product.

Speaker A: Even though you already have over meaning.

Speaker B: Yeah, yeah. Because, like, honestly, we didn't believe really in that first product either. And, uh, we saw a couple steps after that we were just not there yet. And I saw it more as a distribution vehicle. Like, let's have this free tool. Let's get everything in. It's more of a lead gen. And I think our investors had the trust that, you know, hey, like, we know how to think about, you know, distribution and product building in a way that, uh, isn't just going to be like, let's build the product for three years and then hopefully people start using this.

Speaker A: Great. All right, so now you have this first hack. You're drawn by C. Do you think Vexi is helpful and how. And, um, any tips you can share with other digital founders that are thinking about starting companies?

Speaker B: I think if you're building a B2B company, YC is very, very, very helpful. The network is so strong. Um, the partners are also really helpful. At least the partners I had, Michael and Gustav, they were very helpful in pushing us to always think and always go faster and be creative. However, I do think that if you're building a consumer, like a very heavy consumer product, you're going to get less value than if you're, if you're a B2B company. I think there's definitely value because I really believe in the, that the partners can help a lot. But I think the network effect is a little bit diminished in that sense. But I think as a first time founder, it's a no brainer. It gives you the network, it gives you the brand, it gives you access to great investors. I think from that sense, definitely, uh,

Speaker A: what are the things that you learned early at Facebook? Uh, actually helped, uh, a lot.

Speaker B: Yeah. When I started learning how to manage our Facebook, the lesson was there's a few big lessons. One is, uh, crucial conversations. You can look this up. This is just a technique on, uh, how to have high stakes conversations. The second is how do you delegate work? How do you keep people happy doing things that they're most proud of? I think those are really useful, uh, skills to have as a big company manager. I think as a startup founder, they're not super useful. Um, so crucial conversations. I do it still. It's second nature to me now. But I think the way that you learn it from the context of managing people is not as useful. One mistake that we made when we first hired more engineers to the team and my first startup, my first instinct was great, I have a new report. I was a cto. I have a new engineer on the team. I need to set up at least bi weekly one on ones. I need to set up a growth plan. I had all this planned out. Uh, I just had templates from my time at Facebook.

Speaker A: Those are. Never saw this. Of course you can do this.

Speaker B: Yeah, of course. Yeah, exactly. But I don't know. No one told me that you shouldn't do it, so I did it. So I just thought that that's the right thing to do. And very quickly I realized that, yeah, we're wasting our time. If you hire the right people for a startup, they won't care about this and they will tell you, hey, I think we're wasting our time by meeting every other week, spending 30 minutes. Uh, they will tell you you're wasting your time. Like I as an engineer want my CTO to think about, you know, the business, how do we grow faster? Don't think about me like I'm good.

Speaker A: Right.

Speaker B: I think you want to hire the right people that, that is able to tell you this or at least be in uh, the mindset of like, like let's just grow the business as quickly as possible. Um, so all of this management stuff goes out the window. I think there's definitely useful things. Um, this is sort of the not useful stuff. I think the useful things is how do you break down tasks in a way that's going to keep uh, people engaged and sort of um, unlock the roadmap. This is a pre LLM, so people are still manually writing code. If your engineers start writing the same amount of same code working on the same product, that's just, you know, wasted effort. These days maybe that's less of a problem because how fast code gets generated, at least that skill of just being able to break down the goal of the company and how do you go from that to a, to a cohesive roadmap, how do you break that down into, you know, different aspects of the technology that needs to be worked on? I think it's very, very useful and that's very transformable because you know, at the end of the day you're building product and the product process is uh, largely the same although it's, you know, it should be, the iteration cycle should be much faster versus uh, a larger company.

Speaker A: I guess that's applicable to today when you manage agents as well.

Speaker B: Oh yeah, yeah, hugely, yeah. My perspective is actually if you've managed teams before, even interns before, like just have thought about delegating work. That helps a lot with managing agents. Our current team uh, at tier zero is uh, all comprised of staff to principal of engineers who have, you know, done this day in and day out for many years. When I see how they use agents, it's like second nature for many of them to think about work in a different work streams. It's like I'll give him this nebulous task of, I don't know, let's improve agent performance because our evals are worse this week what happened, one of my engineers would literally just run with that and I could see him thinking, okay, there's like five different hypotheses, I need five different agents and each agent run these things. And okay, how do they work together? Right. So they're able to really orchestrate that. And I think that is a superpower that I haven't heard too many people talk about that. I think people that are able to really break down tasks in a cohesive way will get the maximum mileage out of agen.

Speaker A: I think In a way, in the management agent to do work for you, it implicitly pushing into from an IC position, more of a leadership position or leadership mindset.

Speaker B: Yes. M. Yeah, because at the end of the day, if you're thinking about what you're supposed to be delivering versus how to deliver the product, it naturally forces you to think higher level. And because if you're tasked of, okay, I need to solve this problem and you just naturally make your agents go solve those problems. Having that mindset is a huge unlock for many engineers. And I think if engineers that haven't done this before and maybe they're newer in their career, I would totally try to read some management books like how to be an engineering manager. It helps a lot. Or like a tech lead.

Speaker A: Okay, so we kind of covered the first journey of first startup. Um, what do you felt is useful taking your experience from meta, uh, and also what to unlearn. Tell us how do you transition from that big dark time to uh, next. The next phase of your um, journey?

Speaker B: Yeah, man, every time I think about that phase, that's like six months. I like using the chills because it was hard. It was hard as founders because you just have to manage the team's expectations, manage investor expectations. And also you have so much self doubt. You're like, do I throw in the towel? Do I call it quits? We, uh, still have money at the bank, so what do we do here? Uh, we have teammates that are, you know, getting married. Right. Like they have, some of them even have kids. It's like, well, you know, like you kind of feel a little bit responsible for their family.

Speaker A: So basically the situation back then is that people can no longer use your product.

Speaker B: Yeah, we just shut down the product 100 to 0. Completely shut down. Uh, in fact the uh, first two weeks I just told my team, like, just go to the gym because I need time to figure this out.

Speaker A: Yeah, because the companies are running.

Speaker B: Yeah.

Speaker A: But the product is gone. Product is gone, user is gone.

Speaker B: People are showing up to work and they ask me what do I do, what do I build. My co founder and I, this is also our office is just a loft.

Speaker A: Right.

Speaker B: And so we didn't have a conference room. And so my co founder and I just like locked ourselves in a bathroom upstairs and we're like, okay, let's figure this out. And I'm pretty sure it was not soundproof. It was rough. Um, but without going into too much, uh, I think we eventually. So we were kind of shooting in the dark for a little bit. We're like okay, should we go build B2B productivity tools and um, you know, fumbling for maybe two months. And during this time the best thing that happened to us was our investor Amit at Excel set us down at dinner and he said, hey, this, hey guys, this, my girlfriend and I, hey guys, this is an intervention. It's like very straightforward. This is an intervention. You guys lost your mojo. The two, you know, the two guys I invested a year ago would not wallow like this. Like they will go pick up themselves and go figure this out. Next day we're like, okay, let's, let's go figure this out. Let's not try like different things outside of gaming, whatever it is. Let's just see. Okay. We built killer technology again. Before LLMs, we were able to, this is a real time computer vision pipeline for games that we were able to understand what is happening in the game, model everything out predict game outcome. And then we have a bunch of people that love our product and we still talk to ask us like, can you open source your product? We want to use it. And so we went back to the drawing board with all these pieces and we eventually built uh, our second product, uh, Mayhem. It's a social network for gamers to play games together. It's a tournament's sort of social platform and talk to the same coaches. Turns out a lot of these coaches play semi professionally. That's why they're coaches, uh, top 500 gamers in the world. Something that they do outside of coaching is they play in these grassroots tournaments. And so we're like, okay, great, we have the tech to track what's happening in the games. We can set up the tournaments for you. So we worked on this for another year. Ish. And timing worked really well. We um, ran a bunch of tournaments for various games. Covid hit. All the kids were staying at home. They were playing a lot of Fortnite. Fortnite's traffic spiked. Uh, their community team needed something to run their tournaments with. So they came to us. Well, they came to their people and the gamers and the gamers said hey, we should use Mayhem. So we started running a lot of these Fortnite tournaments. And uh, yeah, eventually we powered a huge percentage of even first party Fortnite tournaments. Then we caught the attention of Niantic and a few other folks as well in the space. Niantic, uh, came to us and said hey, we love what you're doing. Building community around gamers. Uh, we're all about community here. Even though it's, we Mostly focus on real world communities. But is this something that you might think about of like supporting Pokemon Go? And we said, you know, not quite, but you know, I play Pokemon Go. I like the games. Like, okay, yeah, like, let's try it out. So we started working with their team a little bit on just like what that might look like. And very quickly after that they just said, hey, why don't you just join us?

Speaker A: Uh, so initially they position the conversation as more of a partnership.

Speaker B: Yeah, yeah, I think initially they wanted to learn about whether or not this is something that, you know, we can even help them grow their communities. And so our angle is, yeah, of course we can support your games too, just like with other games. But yeah, uh, later on they said, we just want this platform. I want you guys to really think about this platform here at Niantic across all of our game portfolio. Um, and so it moved pretty quickly. Uh, we loved the people there. We, uh, met, um, great folks and eventually, uh, we accepted an offership from them, um, and went through the process and joined the team. This theme called Campfire, which eventually grew to the social platform that powered all the games underneath.

Speaker A: What a roller coaster, right?

Speaker B: It was crazy. It was crazy. I honestly thought we would just shut down the company.

Speaker A: So what do you have after that dark moment happened? You still have the team, you have technology, you have the insights and connection to the people that you are used to serve, the coaches, for example. But you take all those resources, uh, asset, connection, insight to solve a different problem that they have.

Speaker B: I don't know if you were asking, you're getting here, but I think the lesson for me there is just really focus on your customers. I know it's a very common thing to say, but really we did not focus on our customers at first. We were like, okay, our product is no longer here.

Speaker A: What do we do? Focus on the technology.

Speaker B: But it turned out it was very straightforward. Let's just go talk to the people that love us. What other problems do they have and uh, figure out how to solve it.

Speaker A: What a that you learn from that experience that you think would be, uh, helpful for the founders to know.

Speaker B: I think number one is just make sure you trust your co founder. I've been again fortunate because my co founder was my roommate and we were friends since college and my now co founder is same thing. We've been friends since college. So there's quite a bit of history there. Um, I have friends that started companies with co founders that are less trustless history. And oftentimes when they come to me for help. It comes back down to the root of the problem is just co founder misalignment. So I think really just lean in on your co founder in these dark times and make sure that you have heart to hearts, make sure you connect and set uh, common goals. I think that's the first thing. Then the second thing is, um, I mentioned a little bit on this earlier is just make sure that you are hiring the right people. When things are good, it's hard to tell when things are good. Companies growing, it's hard to tell when things are bad. That's really when you can tell who you should keep around. At uh, this early phase, the people that you really want are people that love ambiguity. They're more like great. We get to think about this from the ground up. This is fun. You want people that are not thinking too much about opportunity cost. You want people to really believe in the team. You have some edge in some way to win in some market, whatever it is. And it's just out there for you to discover. Um, and it's a very optimistic way of thinking about things. And so you really want those type of people in the company. And so if you're going through a pivot or whatever and you're finding yourself spending a lot of time managing kind of team emotions and things like that, I would actually just, just tell people like, hey, you don't have to be here, like just you know, take a severance, like no harm, just let them go. I think I was too young to realize that. I felt a lot of our engineers left during that time and I felt like it was a personal failure. Failure? Yeah, it's like, oh, I convinced them to come here and now they're leaving and now it's on me. But in hindsight it's actually the right move because you want to have all your energy dedicated to building the company and figuring out what's next, not how do I make sure people are happy and like, you know, just have coffee, chats with people and all that stuff.

Speaker A: Stuff, yeah, that's important. But also the company needs to survive first.

Speaker B: Yeah, I forget who says this but like the biggest motivator for, for companies of the size is just win. You just got to keep winning. If you're spending time, you know, explaining why you're not winning, you've lost.

Speaker A: I love that. That's a good not start. Mhm.

Speaker B: Yeah. Uh, anything that's, that you think you're spending time on, that's not on that. Just figure out a way to cut that.

Speaker A: So that's your first startup and a, uh, roller coaster ride, but a great ending. And uh, that's more like B2C consumer, uh, application product. And then a few years in, uh, working at nine Tech and you started your second company and tell us where does the idea come from and what are the problem you are solving? Yeah.

Speaker B: Ah, yeah. So I think this is like kind of a different arc of my life. When I joined Facebook, that was the first real production system that I was responsible for. And, uh, my first incident, I was on call and I didn't even know where to start debugging things. And so a senior engineer on the team and my manager at the time, uh, basically I just watched them. What happened even though I was on call. And I was just fascinated. It's like, okay, Facebook had a tool called Scuba. This is how you dive into the data. Scuba, dive into the data to look at usage and impact and stuff like that. And then there's database access in production. How do you figure things out? You eventually find the issue and it's like these things called feature flags or Facebook calls it gatekeepers. How do you quickly roll back? So this entire production of code is just brand new to me. And in school they don't teach you any of this. They just teach you like good fundamentals of building software, which, by the way, I think it's mystic. I think it should be a class in college that teaches you this stuff. I was just fascinated. I love it. It's just so cool. There's all these things. Long story short, later on I started Mayhem, and Mayhem was acquired by Niantic, and I went to Niantic and we were there very similar situation. M. Things happen, things go down. We had to. We're on call, we need to fix things. The problem there or difference there is Facebook had a lot of internal changes, tools, and I was very spoiled. So first incident at, uh, Niantic, my initial reaction was, where are the dashboards? Where are the internal tools? How do I roll back? How do I auto scale? There should be just buttons for me to click. None of that. There were dashboards, they were not perfect. Uh, there was no Scuba. Scuba lets you basically create dashboards on the fly. But Niantic, uh, the technology it was using did not. And you had to actually write code to create dashboards. So in the moment, because we didn't have the proper dashboard set up up, it's very hard to debug issues. That's just like the debugging part and then the fixing part is Even worse, it's like, well, auto scaling is non trivial, Scaling up is non trivial because of architecture, um, and rolling back is non trivial. So I just remember thinking, man, I guess most companies are not like Facebook. But then I spent three years at Niantic thinking about this problem a lot. One of many problems that I was responsible for the stability of the platform. It's fortunate that our engineers were amazing and they were able to go and debug things and figure things out. But I don't think that's a good use of their time. And so when I left early 2024, this was just a problem in my mind. I was talking to my now co founder about this problem. He basically was like, yeah, I have the exact same problem. I know exactly what you're talking about. He's, uh, also an engineering leader. He, um, spent nine years after graduating college at databricks and he managed the infrastructure and enterprise teams. Uh, and the last two years he was there, he became the tech lead for their AI agents framework, the model serving framework, AI agents framework work. And I was just complaining and he was like, I know this feeling. I'm working on agents right now. Models are not good enough yet, but I think it will get good later this year. Let's go build something here. Basically I convinced him to leave databricks and we're like, okay, cool, let's do this.

Speaker A: Uh, but before you laugh, you already have a sense of direction. What are the gaps? What are the opportunity, uh, for creating a new product?

Speaker B: So I actually go back to what I said before is I would optimize for the co founder, then the problem space. When I left Niantic, I actually wasn't sure if I wanted to start another company. I wanted to do something different, but I wasn't sure if I really wanted to because part of me, it's itchy, it's fun again. But then part of me on good days is like that on bad days I'm just like, ah, I remember the pain, it sucked. But eventually I just felt like I want to do something different. Whatever it is, maybe it's even joining a smaller company company. I spent the first two months, three months actually, just working on different projects. I actually joined a company that was building heat pumps. Complete random, right? Just wanted to do different things, uh, to just kind of understand a new market. But yeah, uh, I went on a lot of co founder dating as well. Probably like 50, I would say over maybe two months.

Speaker A: Yeah. Is there a program you join to do those, uh, co founder dating or

Speaker B: I used, uh, YC's um, co founder dating app, uh, found folks there. So I actually did not want to be a CEO. I was like, I would rather find a CEO that can do sales. I know I can build anything. So, like, after about 40, 50 dates, I just couldn't find somebody I trusted, I guess enough where I'm willing to work 18 hours a day with them. So then I was talking to Ivan, my previous co founder, because he became an investor. So I was telling him this, uh, it's like trying to jam my ideas on where I can find teams to work with. And so he said, hey, have you thought about just being your own CEO? You're a better judge at a CTO than you are at a CEO. Uh, and as long as you believe that you can go pick up sales and learn this yourself, you should absolutely just go find a good cto. That struck me, right? I was like, I've never thought about that, but I believe in my ability to go learn anything. So I said, okay, let me sit on that. And then a couple of days later, I talked to Yoon, my now co founder, and it just so happened we were talking about this problem and I said, hey, do you want to come build this with me? Uh, and, um, yeah, I mean, the rest is history. But I would definitely just optimize for the people that you work with, then the problems face.

Speaker A: But, uh, what are the things that make you feel this is the right person?

Speaker B: It's very hard to build trust in one hour or two hour dates. I think the best you can do is to build enough conviction that you want to spend the next two weeks with somebody and then go from there. And I think there are a few times where I was down to do that. I think the problem is the ROI on those two weeks. Weeks, uh, because things are moving quickly. This is again, 2024. AI is moving pretty quickly if you're deeper in the space. And it just felt to me like I don't want to spend another two months kind of hopping between different ideas and finding the right people. I want to just start building. I want to find somebody I trust and just start investing in that relationship. And so that's actually when I went back to my own network and thought, okay, top five people I would start companies with. And, uh, Yoon was top of the list. And so I was like, great, I'm talking to him next week, I'm going to go talk about this. And so that's sort of the reason there. I think there is a real opportunity cost and I definitely would urge people to do enough diligence. Uh, if you don't know somebody that you're working with well enough, you have to have trust.

Speaker A: Because the roller coaster right there are a lot of things. People have different opinions and things can go ugly.

Speaker B: Yeah, for sure. And nothing to. I don't want to bash on kind of consultants or salespeople or whatnot, but I think as technical people, it's hard to visualize vet salespeople because they're all good to you. Uh, and so if you're like vetting for a CEO, it's just so hard to tell.

Speaker A: So now you found a co founder. Um, what happened next?

Speaker B: We went to work. We're two engineers building very technical product, selling to a technical audience. So both of us called up people in our network and said, do you want to just give this a shot or let us design stuff, um, build this with you?

Speaker A: So that's after you have a prototype or that's before.

Speaker B: We had no prototype. Prototype we had. Well, it depends on what you mean by prototype. We had a very early product, uh, that sort of works. And then I, like recorded a very quick video and I sent it to some friends and just said, hey, would you introduce me to your cto? And uh, we'd love to build this out with you. And I probably talked to 40 companies in the span of a month. Eventually, I think two startups, uh, that I knew were like, yeah, come on over, I'll give you access, but like, just do whatever you need to do. And so very thankful. Uh, as we started building the product,

Speaker A: what did they get out of that? Uh, because you were. Apparently, you don't have product yet you're building with them.

Speaker B: Yeah, honestly, they took a gamble on us. They got nothing for the first month or two weeks maybe. Uh, but the promise was we will make your product more stable. If there are issues that come out of your product, we want to make sure that you're fixed up and running quicker and they just kind of trust it in.

Speaker A: So essentially you're embedding your or, uh, you and your co founder into those companies?

Speaker B: Yes, we went to the office, we sat next to them, build side by side with them.

Speaker A: At that stage, how many companies are

Speaker B: working with just two startups? This is like two months. First two or three months of this company, if you call it a company. Honestly, the product didn't really work. It was really hard to get it to work because GPT4O just wasn't good enough. And then thinking models came out. 01 came out out we wrote a lot of boilerplate code to make four zero do a bunch of reflection and react and just have it be able to uh, think a bit. And then when 01 came out we tossed all of that code. We're just like okay, 01's good enough to do this by itself. By the way. I think this is an uh, interesting sort of lesson in building an AI which is like for us we took a bet on the model and in hindsight it's like of course you bet on the model but it's less that betting that the model will get better. It's an obvious bet bet. But in what way does the model get better? It's a little bit more nuanced I think for us is we were betting that the models will be more agentic. It's very easy to say models will get better at uh, one shotting things but it wasn't very obvious that models will get better at reasoning and using tools. But we were betting on that and so we built a very basic harness around.

Speaker A: But what insight led you to bet on that?

Speaker B: Yeah, I think it's a lot of trial and error comparing models between releases, um, 4.0 and 01 et cetera. Uh, and also talking to other folks that are in the space. Uh, Yoon is very close to the databricks research team. Um, and we have a few other folks that are also building in the space and so we regularly compare notes. It felt like a little nugget that is more on the like a non general consensus yet. But people that we respect and trust believe in it. Um, and we were seeing some inklings of that as well. Models are starting to become a little bit more agentic through different releases this so we figured that is a good area to bet on. So we purposely did not build that much scaffolding on how models should be using tools. Uh and that ended up being the right bet. We ended up building a bunch more around just like if the models can use tools, well what can we unlock? So we went and built a bunch of workflows and a bunch of context.

Speaker A: So betting on the model is going to evolve in more organic way. Um, and then tell us more about what it actually built based on night.

Speaker B: Yeah, yeah. So like I said, the first version or first like two or three versions didn't really work to be honest. We had some early customers that churned just like they expect it to just work.

Speaker A: And can you, let's take a step back. What are problems you try to solve?

Speaker B: Yeah, yeah. So we are working on the software production problem. We started with the firefights. When you're shipping software, production has two sides to it. There is the wartime, which is like running the software. Things go wrong. What do you do? Do alerts, incidents, test failures, test failures, maybe like a halfway in between. But wartime, right. If something happens, your adrenaline is pumping. You're like going to war and doing things and fixing things. Um, and then there's the peace time, which is maybe an SLO has dipped below or maybe you're out of your error budget. How do you get those up and running and fixed? Maybe you have too noisy of alerts and maybe there's some overarching symptom that you're not looking at. So a lot of maintenance load testing is another one. Right. Uh, and so when we started, we wanted to go solve production. The insight there is coding agents are going to get better. We were already seeing this. Even 2024, cursor was just tab, tab, tab. Early 2025, it was like writing some functions. So if you just draw that line, it's like, okay, it's going to be shipping software, but what happens after? Right. All these things, production that I talked about. So for us it's like, okay, well it's very natural for people to start orchestrating agents to go ship software. They should not be, um, debugging things by hand. They should also manage fixes, uh, by hand as well. And I think Cursor recently published the whole, um, idea of software factory. And that's very much in line of how we think about problem as well. Of just like you're really orchestrating a factory and the factory requires you to ship the software, but also if it's broken, come back for recall, you got to fix it, um, or refunds or whatever. But the insight for us is we can't just go solve the peacetime problem even though that's fine. We have to go solve for the wartime problem because that's like the wish, that's like the acute problem that people have. So the first product that we built was automatic. An agent that automatically debugs incidents and alerts, triages it looks at blast radius and, and eventually puts up a pull request and fixes the issue. So issues happening in production are fixes. And the fix could be a pull request, it could be a rollback, it could be a buildkite run, any number of a feature flag change, some kind of infrastructure change, configuration change. And so that was really the problem, uh, that we wanted to go after. How do we get People back up and running faster. And uh, to be honest, agents were not trained for that. Models, uh, were not trained for that. They were terrible at making decisions. We would have to have done a lot of work in fine tuning, training the early models to have it reason like an SRE or a, uh, staff engineer to go and debug issues. But because we're betting that the models are going to be better, we didn't do any of that. It's like, okay, it doesn't work. It doesn't work for 80% of the issues and that is fine. It will work for the 20% of the issues.

Speaker A: So this problem will be automatically solved once the model evolves.

Speaker B: Yeah. And so we were betting on context. How do we capture the correct trial knowledge to feed into the agents, the models, and we were betting on workflow flow. How do we capture all of these contexts? And how do we inject, uh, the models or the agents in the places where it's natural for people? Um, and so we spent basically all year last year just building that. And late last year, I think Opus 4.5 was really when things started working. It paid off. It was pretty immediate, honestly. We saw our evals go from 3 thumbs up to 1 thumbs down to 30 thumbs up to 1 thumbs down almost overnight with the model shipping. And we were just shocked.

Speaker A: Imagine how much effort will be reserved be wasted if you spend time fine tuning yourself.

Speaker B: Exactly, exactly. And uh, we also rewrote the core agent loop many, many times to take advantage of different model improvements. And we still are.

Speaker A: What do you mean by the agent loop?

Speaker B: Ancient history now, but when models do not think, you have to have the models reason. So you have to do a bunch of react loops. This is just like a reflection loops later on, uh, models can't think and maybe they're not good at using tools. You have to build a lot of things that double checks. The tools are good and whatnot. And you know, now the models are good at reasoning, good at using tools. Um, the next frontier is parallel agents, agent teams. How do you get your models to know when to spin off an agent team to go work, uh, together or sub agents to work together, uh, and in what way? And then the next thing after that is like adversarial models, right? Adversarial agents. You have an agent that's debugging, you should have an agent that double checks this agent. Right. Just because again, the models are improving. So you want to be able to be able to encode all of these workflows into this loop. How the agents work together, um, with the goal of eventually getting to higher and higher accuracy. This loop continues to evolve and then

Speaker A: that lead to you're initially working with two startups and then what happened after the product is ready, after the models are now going to think, yeah, so

Speaker B: actually, so we worked with two startups late 2024 and then we realized that the product needs to go up market. And so we went after enterprises, another like hundred rejections and finally, you know, three ish enterprises, bigger company, mid market, enterprise companies.

Speaker A: About why enterprise?

Speaker B: Because the problem we're solving for is not a huge problem for startups. Because at a startup, uh, you're okay with downtime. Most of the time you're okay with downtime, but when you have a lot more customers, then downtime has significant business impact. And because the product only worked honestly, like 20% of the time, it's noise for startups. But for enterprise at scale, if it works 20% of the time, that's still value to them. Uh, and so these companies were much more willing to take a bet and actually want their team to use something, something here. I think also some of these champions, or all the champions we work with were again betting on us that we can figure it out and betting that, you know, they see that our perspective that it will just get better. And so they wanted to kind of be at the forefront of that.

Speaker A: So the approach to sell into, uh, enterprise, uh, are you selling to enterprise or you can apply the same uh, strategy we're building with you.

Speaker B: And we were selling to enterprise. I mean we have some proof points uh, with the two startups and we had a couple other startups as well as we were building. So we were onboarding a few startups and it was like, I don't know, again working 20% of the time. Um, but we had some pretty good proof points there when it worked. And when we started selling to enterprise, it was a lot of like reference calls with these founders, with, you know, the startup founders. Uh, it was a lot of like case studies that we, you know, that we put together and we just had. You just have to keep talking to people that will take a bet on you that feel the pain acute enough.

Speaker A: What do you learn as a technical founder setting into enterprise that feels really, uh, scary.

Speaker B: It's very stress, very stressful, very scary. I was very stressed out, uh, during that time because I feel like every conversation that I talk to, every warm intro that I get or some favor that I'm asking my network to make an intro for me It's a shot that I have to hit or else I'm going to lose that shot. And you have a finite number of shots, and you have to get good at sales in those finite shots. And that was super stressful. So I did everything I could. I got books, I got a sales coach, I watched videos, the mom test, the whole thing, thing to try to get better. And, uh, there's no silver bullet here. It's just, you just got to get reps. You just got to do it. I think there's like, tools now with granola and whatnot that can take notes in these meetings better, so you can sort of review them and kind of learn from that. But either way, you just got to take as many shots as possible and grind.

Speaker A: Uh, I think it's fine to take as many shots as possible. But also as a startup, you have limited resource, limited time. Uh, and for enterprise, it's notorious for how long it takes to, to close a deal. But that means knocking on a wrong door can have real impacts. So then the question become, how do you pick the more likely closable enterprise? Right. What's your thoughts around that?

Speaker B: Well, first is, I think it's very easy for companies at, uh, that stage to be willing to talk to anyone that listens, anyone that is willing to work with you. And I think it's a mistake. I think looking back, we had customer or design partners that reluctantly work with us. They're just like, okay, you know, my boss and my boss told me to spend some time with you. Okay, I'll do it.

Speaker A: That's the worst.

Speaker B: That's the worst. It's the worst. Don't do it.

Speaker A: They're polite, they're engaging, they're spending time, but does not lead to anywhere.

Speaker B: Exactly, exactly. Um, so we had a little bit of that, uh, early days. You just got to recognize that early and move on. Um, or just keep cash and just say, hey, it looks like it's not really a problem, but this is what we want to solve for you. And if it becomes a problem, let us.

Speaker A: No.

Speaker B: And if that means you have no one, no customer to work with, that's fine. But anyway, uh, picking customers definitely find people that are very much invested in it. And, you know, we were just having this conversation, uh, before the recording on. You want to invest in your champion's career just as much that they're putting their neck on the line for you. And I think that's super true.

Speaker A: Yeah, buying can be as hard as, if not more challenging, uh, than selling, because for Enterprise. Someone, uh, if they want, bring a solution. A new vendor that goes through a lot of hoops to prove this is why we need this and why this is the right partner. And lots of efforts internally need to be investing in this before, uh, something like new, a new vendor can be brought in.

Speaker B: For sure. For sure. Uh, when I was at Niantic, I was trying to bring in a vendor as well. Actually, there were two vendors that I absolutely needed. And it definitely felt like I was sticking my neck out for it. I was navigating procurement. I was talking to our CTO and why we need this. I was working through security. I remember thinking, why is this so hard for me to buy software here? And now, you know, on the other side, I see it. It's like my champion is he wants it, but it's like it's still a lot for them to go through to actually procure.

Speaker A: Yeah. Business use, case, finance, legal, Whole thing.

Speaker B: Whole thing. Justification to it depends on the check size. It might go up a couple levels too.

Speaker A: Yeah. But, uh, apparently your company is, um, making a lot of momentum and setting their enterprise. Enterprise. And even though they are in terms of size, company size is smaller than some other players in the market. But you are doing pretty well with a very tight, very tight team. Any, uh, insights you can share?

Speaker B: For sure. For sure. Quite a few, honestly. I think make sure that you're spending your energy in the right places. I mean, it sounds broad, but as a founder, you could do many different things. You can go after many different markets and customers and whatnot, but you want to quickly identify companies that again, really need you and, uh, design a roadmap to go after them. So for us, actually, we run a land and expand strategy. It's okay that you come in as a smaller customer of ours because we believe that we can grow with you. And we.

Speaker A: Small means not the company is small, it's the contract size.

Speaker B: Exactly. So maybe one or two teams are using us, but a company might have 10x20x more people, uh, that could benefit from us. And so we just try to land. Land small and expand there.

Speaker A: Do you do a poc?

Speaker B: We do a pocket. Depends on the company size. Usually if the company has a little bit more structure, we do a poc. If they're, you know, five or ten people, uh, it's less of a poc. It's more of just like, I'll give you some credits and run it for a week and see if you like it.

Speaker A: So that's kind of not, um, a paid PoC but opportunity for them to try things out.

Speaker B: That's right, that's right. Um, but, but more of a mid market to enterprise motion is more of a four week poc. Sometimes we do three weeks. Uh because you know we're very confident at this point that we can get to Valley in the first week. And so we designed the POC very in a way that allows us prove value quickly because again like a POC isn't we need to get to 100% value. A POC is just can't do the buyers, can the buyers justify a purchase and just you got to understand what, what are the buyers? What do they need to justify the purchase? So anyway we definitely run a poc. Um we try to land small on a contract and then we expand from there and we've done this expansion motion a bit. Um so I feel pretty good about that.

Speaker A: So that can work well if you have a really killing product. Product the can product can show the value and show the differentiation for sure.

Speaker B: Yeah. And I think we're competing against companies that are 10 to 100, maybe even a thousand times our size. Competitors in every stage here in different angles. I think one like I said you got to focus on customers that really care about this problem. Uh and I think the second is you got to stay lean especially with AI. Now we're eight engineers. Every single one are staff to principal level engineers that have worked at high scale companies before. There is no management. No we barely do Sprint planning. We have a board that we just kind of throw things on very low overhead and it really helps us in delivering value to our customers as quickly as possible. If you think about the uh software factory analogy again right. You really want to go from customer requirement or even just like you discover a new market that you have some confidence, high confidence that people will pay money for to product being delivered and shipped in the hands of customers as quickly as possible possible. And we do this sometimes we ship features in like an hour. Like we'll meet them and we just ship it. Um but really you want to do this as quickly.

Speaker A: How do you make it happen like one hour, like even just a day or two still it feels magical to the customer.

Speaker B: Must for sure. For sure. There's two sides of this. One is like you don't want to be too focused on the short term, right? Uh you don't want to ship like all these crazy short term custom features for every customer just to win an extra percent of revenue. And then on the flip side it's like you don't want to wait for too long for too many customer requests to come in. And then you prioritize like okay, this feature, 10 customers want it. Great, let's add that to the Sprint for the next Sprint. So there's definitely a fine line, fine balance there. Something that we do internally is uh, I will record all of our sales calls and all of our um, customer calls with uh, our existing customers. Uh, we have a pipeline that extracts insights out uh, from these transcripts and these videos and find common patterns. And then I have a bunch of strategy document that I've written already. So the agent will go and compare to see where it aligns.

Speaker A: What is the, the strategy documents cover?

Speaker B: Just it's a big markdown file that details what I think where the industry should be going in the next 18 months and how we fit in to this. Um, and the part that we want to go after. And then it talks about a few products that I want to go after like uh, that we want to build anyways. Uh, and then the reason for that, uh, so this is a very top down like use a lot of these is like what I think. But no customers are telling us this. And so I just have that as a kind of lot of thoughts in there. And then when customers do tell us about things we will go and use AI to go and map like oh, it kind of fits in here or like it's not quite, doesn't quite fit anywhere but like similar to 2 and 3.

Speaker A: Right.

Speaker B: Like and then so you know, I will ideate with AI a little bit.

Speaker A: It's kind of uh, almost a real time agentic partisation process.

Speaker B: That's right. So this process runs on my computer or a um, Mac studio that I run at home. And, and it will then basically synthesize all this stuff, send it to me and I will read these MD files that Claude uh generates and I will read them and I'll see. Okay. Actually I think this one really fits.

Speaker A: What are the MD files exactly? Are those PRDs or are these uh,

Speaker B: there's no real format. It's literally just like what the agent wants to write. And basically I asked the agent to what is the feature? Why should we build it? Usually it's a citation of something customers just said or said before. Uh, and how this fits into our strategy, quick estimate of market size based on our current customers, which other customers could benefit. And I look at that and I just go okay, I think this is reasonable or I don't believe you Claude. I don't know. Whatever it is, make A judgment there. Uh, and I, you know, if I like it, I usually say, hey, cool, put together a prd. And I have a PRD format that's not a full on prd, but it's more just condensed. All this condensed and the reason I generate the PRD is to convince our engineers to pick it up. I don't tell our engineers what to build. I just write. These documents are like, they're just paragraphs, like two paragraphs. It's like, guys, I think there's something here. If you agree with me, spend some time on building this. And it just gets posted in our

Speaker A: Slack and you are running that kind of prototype. You build those agents and have that uh, render process. The output is sent to the uh, rest of the team. Uh, how often do you run that partization? Like on daily basis or it runs

Speaker B: after every sales call. Every call. And sometimes it'll just generate garbage or something interesting and I'll just archive this or whatever it is.

Speaker A: So constantly, um, regularly triage as new features being proposed by agents.

Speaker B: Every night or even between meetings, I would just look at it really quickly or every night if I have a backlog of three or four, I'll just

Speaker A: review it and then uh, how does the engineer. They don't do Sprint planning and there's no product manager. But uh, how does the engineer their workflow?

Speaker B: So we don't have teams, but I suspect that we will if we double the team.

Speaker A: You have eight in.

Speaker B: We have eight right now. About half the engineers work on platformy m things like more long term bets and the other half work on shorter term things, short to medium term things that we want to ship. And time duration is usually long term is three to six months. Short term is like this week. Yeah. So we would um, let the engineers basically kind of prioritize a little bit. There is something that I think has been sitting there for a while and I think is really important. I would introduce interfere, but most of the time it's very clear, just like, okay, we want to drive revenue and we have this longer three to six months thing that we want to build. Let's make sure we make progress there and let's make sure that we close deals. Right now it's uh, my first comment on we just got to win. It's very clear. It's like, okay, I'm building this so we can make July a big month for us. Oh, I'm building this because May is

Speaker A: like so you're essentially uh, you're are managing and providing context for your team. To decide likely through this AI's assistance, absorbing those contact and figure out what to build next.

Speaker B: That's right. By the way, all this transcript, this entire cloud setup, it's open for the team as well. So they can go in, they can read all my meeting transcripts and they can also make their own decisions. They can go in and just chat and think about things. And some of our engineers are very keen, keen on knowing what the customers are saying, even though they're not in these calls. But yes, I think bring and distributing that context to people that care at least is super important. I think like pre AI, it's a little bit harder to bring all these contexts, distill it, package it up, give it to the team. Now it's just, I just brawl it just. Here's the thing.

Speaker A: How do you do quality? Because at this point I think you have existing enterprise customers using a tool, um, on a regular basis. So when you ship really fast and also very autonomous way, uh, how do you control quality?

Speaker B: So tier zero, actually we ship quality for our customers and so we use tier zero to ship quality for ourselves. So tier zero is an agent that basically um, reads your code, that understands your tribal knowledge, understands your telemetry as well as your agent. So if you're building agents, we can also understand agent behavior. And we primarily work on agent behavior. And so Tier 0 is plugged into our LLM observability, again, our infrastructure and all the context, um, including our sales costs as well. Um, so it has product context. So when issues happen, we will actually go and investigate the issues. It'll go and fix, put up a fix, ship that out, it'll actually monitor that fix into production, make sure that it's really fixed and if it's not, put up a second fix so it'll run that loop for you. I think without Tier zero, a lot of companies, uh, that we talk to try to build something like this with Claude uh, MCPS. And I think if you're sub 5 engineers or sub 10 engineers, you could probably just do something, something like that and it's good enough for you. But uh, I think there's quite a few bottlenecks that you run into as uh, as the company scales, as your product, uh, evolves, uh, that uh, you know, at that time you talk to us and it's like, okay, we want a solution here. We're shipping really quickly. How do we continue to be reliable? I think just like first, you know, to be. If you don't have a automated system in place, you should absolutely have an automated system in place, tier 0 or not build your own. If code is. If you're generating so much code that you're using COD agents to review your code, you should have agents to watch the production side of things as well. Machines generate code, machines on call. And so absolutely invest in something there. And so start with cloud, build it yourself. With MCPS it's very easy to set up. But a couple of things to run into that you might want to consider. Enterprise solution like ours uh later on or more grown up solution like ours later on is uh first is token use. You'll quickly, quickly spend way too many tokens to investigate every alert, especially if you have noisy alerts. And so you will want to figure out how do you consolidate the alerts so you don't spend too many tokens. And that's a whole different thing you want to build. It's some combination of deterministic workflows, some combination of uh, that could be like regex or whatever code ASC comparisons you want m some version of using lightweight models to go and figure out if issues are similar enough where they should be grouped together, grouping all of that and then running heavy agents. So that's one big problem around ready that you probably don't want to spend your engineers time on. But if you do that's fine. Right? Uh and then the second area. So the first is more on cost, uh cost on tokens and cost of your engineers to run it and maintain it. The second area is on the agent performance. So coding agents are really good at coding but debugging production and infrastructure, it's a completely different thing. Coding, it's a closed loop thing. You can write, test it can validate it. It's all, it's a closed loop. You can boot up the machine on the production side it's very open ended issues happen, you don't know what the answer is. Most of the you really need a heavier context layer on top. So you know you can build a context uh layer by naively a rag or whatever it is. You know you can do that but then how do you validate, how do you make sure that uh the context is up to date code changes infra drifts, something might be you know, in memory true 30 days ago, not true anymore. Issues happen, pulls the wrong memory, you know, takes your team in a different direction.

Speaker A: Right.

Speaker B: So those are like two big areas. There's a few others as well. But you know I think either way I highly, highly encourage your shipping software with agents which you definitely should, should be, you should be using agents to go and maintain them as well.

Speaker A: How do you see the future will be uh, a year from now in terms of the problem you are solving in the problem space?

Speaker B: Agents all the way down agents are producing code now. I think agents will be shipping end to end software. I think agents will be instrumenting the code as well. It should be creating alerts, it should be setting up monitors, setting up all these telemetry on the code in case things go wrong. And if things go wrong, agents are there to fix, fix things. And again these, these could be bugs, it could be incidents, alerts, et cetera. And only after all of that and the agents cannot solve the issue. It escalates that to a human. So I think as a, as software engineers our job is really just how do I translate the thing that I want to build that delivers value to people into a set of agents that will go and execute this. And that's not just going from building it, but that's building it and maintaining it as well. And part of that workflow is how do you work with all other human engineers to maintain this company of agents that you're going to be orchestrating. So I really think that there's going to be some interface on that and that could be another agent, right? I don't know yet. But there's some interface there where humans will work on kind of like ah, a chessboard if you will. That just sets this up.

Speaker A: Great. Before we wrap up, I want to ask uh, what are some of the apes you can provide for, um, a new leader? Either they're building teams within our company or foundation founders start um, building their own startup. In terms of building AI native teams, what are the tips that you can share with our audience?

Speaker B: Invest in tooling. We have a unlimited AI budget, uh, for our team, just experiment. Things change so fast. Our team use Cursor and Claude and Codex and Gemini and Conductor. There's so many different tools use everything. So that's number one. I think the second is, I know I've been kind of belaying this point now but really, really hire people that, that think about orchestration versus like you know, doing the work, like getting the work done versus doing the work. And I think ex tech leads. X manager is actually really good at that as long as they're technical enough. Um, so hire, hire people that can think about it in, in like a, in a systematic way and, and that impacts how you interviews and whatnot. And, and I think the last thing is pick a domain that is going to grow as agents become more and more popular.

Speaker A: Popular. Great. Well, I. Thanks a lot for sharing your journey, um, and all the insights along the way you gathered, um, by your own company and kind of riding this, uh, AI wave. And, uh, I'm. I learned a lot of myself. And thanks a lot for, you know, seeing. Seeing that with us today.

Speaker B: Yeah. Thanks for having me, J.

Speaker A: Awesome.