The Peterman Pod - CloudKitchens CTO on Intelligence, Regrets, Steve Jobs and Travis Kalanick Stories

Episode Date: November 21, 2025

Brian Attwell grew to Senior Staff at Uber by age 25. After that he left Uber to join CloudKitchens (Travis Kalanick’s current startup) and quickly became the CTO after his team doubled in size every 6 months. I asked him about how he did it. He also had a bunch of interesting takes about big tech and stories about Travis Kalanick and Steve Jobs. 𝗣𝗼𝗱𝗰𝗮𝘀𝘁 𝗹𝗶𝗻𝗸𝘀:• Transcript: https://www.developing.dev/p/cloudkitchens-cto-on-intelligence• YouTube: https://youtu.be/egNtHu4q-vI• Apple: https://podcasts.apple.com/au/podcast/the-peterman-pod/id1777363835𝗧𝗶𝗺𝗲𝘀𝘁𝗮𝗺𝗽𝘀:00:00:00 - Intro00:01:26 - Growth to Senior Staff at Uber00:10:05 - Was it luck?00:11:45 - Interviewing for IQ00:18:02 - Intelligence and prioritization00:22:19 - How his team doubled every 6 months00:28:30 - Manager promos tied to scope00:39:13 - Amazon and Google brutal honesty00:43:39 - CloudKitchens behind the scenes00:50:24 - Biggest career regret00:54:17 - Travis Kalanick experiences00:56:01 - Most impactful advice received00:56:56 - Most impactful book for career00:57:53 - Advice for his younger self00:58:48 - Outro𝗪𝗵𝗲𝗿𝗲 𝘁𝗼 𝗳𝗶𝗻𝗱 𝗕𝗿𝗶𝗮𝗻:• LinkedIn: https://www.linkedin.com/in/brian-attwell/• X/Twitter: https://x.com/attwellbrian• CloudKitchens: https://cloudkitchens.com/careers/• CloudKitchens tech blog: https://techblog.cloudkitchens.com/𝗪𝗵𝗲𝗿𝗲 𝘁𝗼 𝗳𝗶𝗻𝗱 𝗥𝘆𝗮𝗻:• Newsletter: https://www.developing.dev/• X/Twitter: https://x.com/ryanlpeterman• LinkedIn: https://www.linkedin.com/in/ryanlpeterman/• Threads: https://www.threads.com/@ryanlpeterman• Instagram: https://www.instagram.com/ryanlpeterman• TikTok: https://www.tiktok.com/@ryanlpeterman

One time I was on my deathbed, the doctor told me that I was going to die tomorrow. This is Brian Atwell. He grinded to a senior staff engineer at Uber in under four years, and now he's the CTO at Travis Kalanick's current company, and he came with some insane war stories. One time at Uber, I was walking home and I collapsed on the side of the street. My chest was aching, and I couldn't move any part of my body. You grinded an obscene amount to get to where you are today.

If you want to be senior staff at one of the world's best tech companies by the time you're 25, this is the only way to do it. He also dropped brutally honest takes about how big tech actually works. I held off saying this, but Google had this policy where they wanted to keep as many smart people on staff as possible, and they didn't want their competitors to have them. He had a run-in with Steve Jobs that didn't go how he hoped. Like, I really made Steve Jobs think I was an idiot.

And he also opened up about what it's like working directly with Travis He says, guys, the core problem here is that this is lazy, you're over-indexing on scope, it's uninsightful. You could do so much better, it's worth your time to do better. Why is this company so strict on privacy? We don't usually talk about it, but I talk to Travis about it, and he said, I could give you a bit more than we've given anybody for. This was just the surface. Here's the full episode. Your career grew really quickly to senior staff at Uber. I mean, you got there,

in less than four years after graduating college. And I kind of want to go over the story of that. So what would you say are some of the top things and the highlights that led to your growth? If I think about it, probably the things that really helped a lot is that fairly shortly after graduation, I went to Uber. And early Uber was just a fantastic engineering firm, right? There's good people to learn from.

They're very meritocratic. And they're growing, so there's lots of problems. right there they were uh you don't have to be growing to have problems but it is one way to have a lot of good problems to solve and um the other thing is that just naturally i care a lot about my team you can't you can't succeed if you're selfish in the long run doesn't work out team support all right so so those kind of things are just natural and i got for free but the things that um i intentionally did is that i cultivated this tolerance of extreme pain.

And pain tolerance early in your career, a lot of this is just work ethic. And if you plot engineers career growth against how much work they do, it's like a linear relationship. It's at least linear.

It's actually super linear for a lot of it because of the compounding effect of how much you work. And this is especially true because managers will only give the really valuable work the really strategic, the technical, the kind of things that helps you with your career, once you've already proven you're good at it.

And sometimes you just got to go and you've got to make time to learn that yourself. So I do think that working, pushing really hard early on does have outsized returns. I actually don't totally buy that that means you should stop after because there's always like more levels you can grow. There's also levels that haven't been invented yet. So you could do that. But certainly this is something that I thought about early on. And like when I joined Uber, I was very aware that I had more time than I'd ever have in my future. And that if I was going to invest in growing, this would be the easiest time to do it.

It sounds like you grinded an obscene amount to get to where you are today or to kind of grow as much as you did. And I'm curious, like, looking back, was it worth it? You know, one time I was on my deathbed and I was told, the doctor told me that I was going to die tomorrow. and I was sitting on, I was sitting there thinking like, damn, I'm going to die, that sucks. I haven't accomplished anything yet. There's like so much stuff professionally I want to do. Right. So that expression of like, you're never going to think about wanting to spend more time in the office.

You know, that's not true, right? Like I went back when they found out they messed in my medication. I worked harder than ever. And yeah, I totally overdid it sometimes. But the times that I pushed really hard, they were fun. They were like being in the soccer. game where you're tied until the last minute and then you score or somebody else scores your team wins and it was painful but you look back on your head and you're like that was great so when you were

on your deathbed you you weren't saying oh i have regrets that you know i didn't travel more do that your your regret was i wish i worked harder yeah it actually was yeah yeah i was like shit i'm gonna die Oh, I was really looking forward to building some cool stuff. I was really looking forward to that. And then I got out and I was on an internship and I went back to work the next week and I just worked harder. So everyone has a breaking point. Obviously, you can't work, you know, 168 hours a week. Where is that breaking point for you?

And like, how do you know when you're working too much? I think the best way to know, I have an hour's number in my head. but that's less useful. The way that I know is if I start to get a little grumpy. Like if I, let's say that I work a few weeks without taking any day off, I'll start to get a little bit grumpy, I'll be less patient with people. And I'm in management, so I really have to be patient. So when that starts to happen, usually my partner will tell me.

And I'm like, oh, yeah, of course. I haven't taken a day off in weeks. Right? This is me catching it earlier than when I was younger. One time at Uber, I was walking home and I collapsed on the side of the street. My chest was aching and I couldn't move any part of my body for 15 minutes. I just watched people walk by me. In that moment, I knew I should have cut back by 5%.

Right? I knew it, but ideally I would have known that a little sooner. Did you go to the doctor after that? or like, what was that? Yeah, I did. And there was nothing where they were like, I don't know, you're too anxious. You're working too much.

If you don't take time off and just like every moment of your waking day is trying to do really high quality work, your anxiety levels go up over time. It's the same reason that professional athletes are really intense. They're training all the time, but they are conscious about taking time off to let themselves their body, their mind, to regenerate.

Are there any concrete stories you can tell me that kind of illustrate how you grew as an engineer? There's this guy called Yi Wang. We both joined the same team at Uber. It had been there for a few years before we joined. The reason for this team was to fix some of the maintainability issues that were happening in mobile as the company hyperscale.

So we're the most junior guys. Every day we overhear some kind of big debate on the team. Like we'd hear, hey, should we use our X-Javas streams admitted from this library, would that make a lot of these issues go away, or should we use some other more conventional type of multi-thread work distribution system? Should we do something else? And I overhear people user experience to prune out the worst options, right? That was like fairly easy. And then picking the best option was a bit more subjective. Like they debate it, they'd go back and forth, eventually they would disagree, they'd commit, they'd move on with their

lives. Everybody on this team, other than he and I, they leave the office at 7 p.m. You and I worked from 9 a.m. to midnight. So after I'm done, like doing a good day's work, my usual kind of stuff, this day I went and I built the prototype of the ARX Chava approach. I found eight representative examples that I'd seen in past issues that I just read in post-mortems, and I built compiling examples for them. Then I did the same thing for option B. I did the same thing for option C. While I'm doing this, you did it on iOS, I did it on Android, re-reviewed each other's stuff, and then the next day, everybody comes in, and we show them what we've done, and they say, well, yeah, I mean, we thought option B was better, but you guys have done the work. Clearly

option A is better. We can see that. Thank you. We do something like this every day. And at first, our hit rate is not good, right? It's like super not good. Uber would not have paid us to do you to spend this time. Because we're hunching around, we're trying to find some kind of unexpected, hidden valuable truth. And most of the time, we're just hitting a knowledge ceiling.

We can't get past. And our intuition for where to hunt is bad. But after a few months, we're getting better at it, right? A few months later, we're now the guys who commit the most code on the team. And instead of overhearing things, and then doing it after hours, people are now going,

yeah, what should we do? I don't know. Let's involve Ye and Atwell. Okay, so this is like a few months and it's joining this team. We're now that a de facto tech we do it. And we just keep outworking everybody that basically around us. A few quarters go by.

And now, they were like top three committers across the mobile organization at Uber. And we're also the guys that get pulled in for a lot of the gnarliest things across all of mobile and also the biggest debates, which is like a 400-person team. So at this kind of point, promotions are inevitable. So they happen. Okay, I know that like people listening to this may think this is extreme. This is, I also worked a weekend. So this is like 90, 100 hours a week. And it hurt.

Physically, my body hurt and my brain hurt. I had a lot of headaches at first until I got used to it. But if you want to be senior staff at one of the world's best tech companies by the time you're 25, this is the only way to do it. To someone who says like your career growth was luck and you were lucky to be where you were, what do you say to that? Yeah, so luck matters a lot and that things that happen in frequently, right? Like if you do actions every day, 100 times a day, and you do those very well, it's not really luck that those go well for you, but if you make a decision and you only make it every three years, then luck matters a lot there, like selecting which company you're at. So, yeah, I picked Uber for a reason, right?

Like I was choosy in the company I picked, but I could have gone wrong. Once I was there, you know, there's a lot of things that I'm doing myself, but if, like, I'm not trying to suggest that everything is solely based off of, like, your own merit and that there's always deterministic mapping between effort and outcomes. So you're saying you increased your chances of luck by shooting so many shots. Yeah, well, I guess I'm saying that once you're in the company, I think, like, I was going to do well. Right. I mean, if you outwork everyone around you and you're fairly smart and you've got a lot of the right mindsets and it's a culture of merit, then you'll probably do well. But what if I joined a company that wasn't like a merit-based company? And like that would have set me back. It would have taken me a while to figure that out. People don't tend to job hop that well and doesn't look that good when you do. So joining Uber, yeah, there's a bit of luck there. You mentioned you were choosing in picking Uber. What did you? see at the time that made you pick Uber and like what signals are you looking for? I think that I would spend probably foremost, it's my first company, spend time sussing out

the quality of the engineers at different companies and trying to figure out like what is the process that he used to hire engineers by because that's very indicative of the quality of the engineers that come in. Processes that hire strong engineers are processes that explicitly test your brain's ability to reason about on-the-spot trade-offs. Of course, perform job-relevant skills, like there should be, like, difficult coding aspects, your ability to quickly assimilate and discuss information. There might be like a, hey, here's a five-page post-mortem, read this thing, and then we're going to debate whether or not this entire team should be restructured based on the post-mortem. And you absolutely should not be able to pass

them unless you have high mental acuity. Like an, an interview that tests your ability to recall things, your experience, or just your mindsets, does not build a strong engineering team. An interview that anyone can pass regardless of IQ, if they can practice enough, that does not build a strong engineering team. And there's actually a lot of, there's like a comically large corpus of studies around how to interview effectively. The reason that companies don't do it is it just takes a ton of work to build a good process. Like in a tech org you have dozens of different roles And each one needs different interviews

So the leadership team needs to really dedicated to it I would say that our interview process is fairly well designed I welcome people to try it out But we still are doing like 20 experiments at any given time To try and improve it So then what is it that you would ask That would actually test for IQ or something like that? Yeah, you know it's funny

Some places will literally do an IQ test up front and that's not terrible. Our accounting team does that. But if you can come up something that requires you to hold a lot of concepts in your head and is also job relevant, like you find an applied programming task that also involves, requires you to understand a lot of different requirements at a time, and the requirements are a little bit in conflict and a little bit hard to reason about, that kind of thing is really great.

That post-mortem example, right? like a read a five-page post-mortem, and then just read the whole thing in like five minutes and then discuss what are the structural problems with the team, where one part of the post-mortem says something, another part, maybe conflicts of that three pages down, is the kind of thing that most people, and also chat CBT, can not get anywhere close to doing.

Interesting. So it sounds like you're saying that if someone's IQ is higher, their job performance will be higher. Yeah, I mean, this is like one of the most well-term. researched results in applied psychology. But the reason you don't notice it as much when you're at create tech companies is that everybody that gets in is usually fairly smart already. There's not a a lot of differentiation between the performance of people on your team based just on IQ because all of them are already like one or two standard deviations above the norm. But like Matt is sure as hell

filtering out people who are, you know, below the median before they get it in. So then how do you filter among the people that are already like one to two, standard deviations above. There's a bit of, like, how do you design problems that are, they're not just mentally straining, there are a combination of mentally straining and experience and, like, relevant skills, which shows, okay, are they sharp and have they mastered it and can they apply it? Some people will be stronger when they join. There is no interview process that has an R-value of 1.0, right?

Nothing. No interview process in the world is 100% predictive on the job performance. Not yet. Maybe. Maybe we'll figure it out, Ryan. but I can tell you that I and no company yet in the world has it. Well, it's interesting that you say IQ correlates with on-the-job performance. I'm actually very seriously considering to slapping an IQ test in front of some interviews.

Because, no, I mean, it's actually a very honest, it's part of why leak code is a thing, right? Like, leek code is not that related to the kind of work that you do, but it's, like, kind of tricky. So it just gets how good people are. It's, like, tricky, abstract reasoning. But the problem is it's so gainable that you can just practice leak code. IQ test you can't practice it. I don't know, maybe it's slap up the front. I'm going to try it.

I'll probably try it for PMs first because they're harder to interview generally. And also, like, the pass rate for my interview bar that I've defined for PMs is, like, super low. And I'm just annoyed that I have to keep interviewing them. So I'm like, maybe I'm going to slap an IQ test in there and save some time. Why is interviewing PMs harder than interviewing software engineer? Okay, so some aspects of it are very hard. skill-oriented. Those are very testable. A lot of the issue is, okay, yes, there's soft skills, but it's also that this role is generally less well-defined than the engineering role. It's incredibly

well-faceted. There also is not such a thing as school for PMs. PMs are different across different disciplines like software versus non-software PMs, the discipline is younger. So there just haven't been as much thought put into how to interview them very well. We ended up having to do like a whole rethink of what is a world-class PM. We interviewed CEOs from a varied variety of companies to get their take on it. And we, like, wrote it down, and then we designed an interview process. And it's, like, completely different than other companies do it. And I think it's good, but it just showed, like, how little I could borrow from. And look, other companies have interviews, like, met as PM interview, it's pretty good. I think it could be way better. With what? Like, slap an IQ test?

Well, actually, I mean, it probably wouldn't hurt. Yeah, if you slapped an IQ test in front of the PM interview your process, it wouldn't help differentiate between the excellent and super excellent, but it would help weed out people very early. And then you could spend more time differentiating between the good versus excellent in the rest of your process. And when I talk to places that do do IQ tests, because it's not that uncommon at places that have very high standards to do someone like this, is always in the screen stage. It's always just the let's filter people out to save them time and that's time. I say, oh, you're saying some other companies do run IQ tests? Yeah, they do. Yeah. I don't think there's that many, though. I think this is a little, this is, this is certainly a move.

I always hear the common take is that it really doesn't matter how smart you are past a certain point. It matters more, you know, how hard you work or your ability to choose impactful work and, you know, work in a team, etc. What would you say to that? IQ's the thing and it influences how much you can do all the other things, but you definitely need to consciously. they get good at other skills. And knowing how to fiercely prioritize your time, super, super important. Like every time that I do,

that I'm thinking about what to work on, I think about three things, which is, A, how important is this work? What's the expected value of this initiative over a fixed time window? B is what the probability of its success with and without me? And then C is how much time does it take me?

I multiply A times B, I divide by C, and that's my expected value creation for hour. And I'm always want to maximize this kind of thing. What's kind of interesting about this mindset is that often, you'll often get into situations where we're working on the most important thing is not actually the most valuable thing you can do with your time. Because especially early in your career, early in your career, you may find that by the time that you hear about the company's top priority, There's a lot of stuff figured out, and it's already super well-staffed.

So joining, it'll be fun, but you may be joining as a cog in a really well-oiled machine, whereas if you go to priority number three, you find something that's valuable, but in a tougher spot, you can maybe go in and be a hero. It's interesting that you say that because, you know, when I think about prioritization, obviously it's cost-benefit analysis, you know, benefit divided by cost. The thing that I think is interesting is that second term where you were saying that what's the probability of it succeeding with and without you? Can you explain that a little more? Yeah, I mean, this is harder.

I think getting good at estimating expected value is already a very difficult thing. And then figuring out like what how to kind of create uplift is even harder. but at early stages it will often be like let's see you're fresh out college at that point it's often fairly easy it's just what is not going to be staffed that's important

and then as you get a little bit further it's what are the things that you're uniquely good at and where is that match with something that's valuable and you can kind of do some fuzzy math but it's never going to be three significant figures of precision yeah I'm kind of curious about that expected value calculation as well like how

how do you recommend developing that, what's important to figure out and determining the benefit? Yeah. Okay, so there's absolutely things that everyone can do to get better at this. Engineers, fresh out of college, no business background, it's not a natural thing for most of us. So what I recommend is every time that you have a director or a PM and they talk about, we really want to move this metric by this amount for some quarterly goal. Like maybe it's, we want to improve recall, on this model by 10%. You want to know why they care.

Maybe it's because they want to reduce churn. They think that'll happen if they improve recall. And then churn, they're mapping that in their heads to additional dollars and cents. If your manager punts on a project, you kind of want to know what there's principles behind that. And you can ask these guys. Like, you probably should use regular time

on your one-on-one to ask why these decisions are being made. But the best possible case is that you find your company, Nate already has a spreadsheet somewhere with all the top initiatives or all of the projects of the quarter. And there's a column that says, here's the expected value. Or it says, like, here's why we care as a company. If that column exists, it is gold. And you should read it.

You should just every now and then go read that column. This is all the work that other people have done to calculate expected value or give some sense of it. And you'll pick up intuition from it. Talking about management, I'm curious. what's the story behind you eventually getting into management? Dude, yeah, I procrastinated. I put it off forever.

People, my manager at Google told me I should do it. My manager at Uber told me I should do it. When I joined, CK, I was told I should do it. And we had really great engineers. Travis, our CEO, he built Uber. He was the CEO of Uber. So we pulled a lot of Uber's strongest engineers. They had friends.

They pulled them. It was just like this really super strong, super tight crew. And I also had eight engineers that sat around me, and they effectively treat me like their boss. And they asked me what they should work on, and I came up with stuff. So I had all of the fun of being an IC and of having a team, and none of the responsibilities of being a manager.

It was amazing. And then one day, my boss said that I'm either going to hire a people manager or you've got to do it. And he was saying that because they didn't need a manager. They didn't really have one. And I thought that when my boss said this, that he was right. They deserved somebody, but I didn't like the idea of somebody coming off the street, like of a random people managing them. And I also really didn't like the idea of somebody coming in and messing up my vision for the

team, which I thought was pretty good. So I was like, all right, I'll do it, I guess. And I did a terrible job. Right? Like, yeah, I mean, I, I, I, you hear about how people, how managers will procrastinate a bit by coding. It's good for managers to code. But I procrastinated by it so much.

I did so much coding that there was somebody that joined my team. and after three months, he said to me, wait, Brian, are you my boss? Like, are you my manager? I thought you were just a really helpful engineer. It was really, like, how negligent must I have been in my management responsibilities for someone to have said that? It's a real wake-up call.

So after that, I stopped procrastinating so much on these things. I got better at picking up the management fundamentals. And then at that point, the portion of the company that reported to me doubled roughly every six months. Yeah, that's kind of insane for the part of the company that reports to you to double every six months. Why did your team grow so insanely? Every time an organization has moved under me,

from somebody who's admittedly already pretty smart, I'd still assume that there's at least an order of magnitude improvement that we could make and how this organization performs. And I'll just start truth-seeking with that team. I assume that everybody, including myself, is wrong just all the time. And I get really, really excited when somebody says something like, you know, Brian, we've been doing this thing for years, and it's like a religious thing. We believe it so strongly.

But I think it might be wrong. Oh, that gets me really excited. And I'll give you a small example. So a few years ago, there was an integrations team. move under me. This team, they built 1,200 different integrations with other companies, which sounds like a lot because it is. And their goal was that they want to basically have all the information about the entire restaurant industry in one place, clearly valuable. Each one of the integrations was originally a very smart bet. Analysis was done to decide whether it was needed

and it was built. So now there's a lot of inertia around maintaining it. And the team works super hard to maintain them and keep the data quality good, Kenji, who manages the team to me, says, Brian, how important could each of these 1,200 integrations be? And just fucking great point, Kenji. That is a lot of integrations. They can't all be equally valuable. So we spent some time digging into that.

We spent a couple days trying to come up with different formulas to quantify the value of each of them. And once we came up with the just, distribution, like, it was really hard for anyone to say, no, you got to keep them all open. It's just obvious that some are much less valuable. So we stopped supported a bunch of them. The amount of pages that the team received went down significantly. The amount of time that the team got back was very large.

And what ended up happening is that the quality of our product in aggregate got better because now the iterations that matter are well supported. And we've got time to build new things. It's just a win, win, win. So it sounds like when these teams get moved under you, you start questioning some of the base principles. You try to find the truth in these long held practices on the team to uncover these huge wins. Is that right? That's right.

Yeah. I'll never say. And often, folks, often there's a lot of hints. You kind of want to start with what are the things that people just have suspicions around? that can be good. That'll get you a few quick wins, and then you'll have to take a bit deeper. You mentioned a lot of teams got moved under you.

How does that conversation usually go? Yeah, I mean, the conversation is always really different, but it's got to be done with empathy. It's a fact of life that if you have a culture that's based on merit, that in order for some people to rise to the top, that other people's scopes maybe need to be reduced, or some people who are overall quite capable, may still may need to be managed out. And you can absolutely have that conversation in an honest way

that says, like, hey, what we really need here is this, and you haven't been doing that lately, while still showing them a lot of appreciation for what they're still doing well or for what they used to be doing well. One thing that can happen at some companies is managers' career growth is tied to their scope. And so they kind of hold on to it with, you know, everything that they've got, whether or not it's good for the company or it's a better setup to do so. And so I'm curious, like, in those cases, like, you know, why did people give up their scope or is there not an incentive structure like that at that company? Yeah, I mean, there shouldn't be an incentive structure like that. That's not a good way to set up an incentive structure, in my opinion. And one of the things that,

or the head of Picnic and I did a few years back is rethink how we can avoid this. actually, I think Travis reserved some credit because we originally had a leveling system and an incentive structure for obvious reasons, very similar to Uber's. And we knew there are some problems with it. So Charles and I spent time improving it. We presented it to Travis, and he read over it, and he's just like dropping comments everywhere in Google Docs on how each clause can be better. And he looks up at the end, and he says, guys, the core problem,

here is that this is lazy, you're over-indexing on scope, it's uninsightful, and you could do so much better, it's worth your time to do better. At this point, so I'm convinced that it could be a lot better, and I'm also convinced that a lot of companies do a bad job. We ended up spending a ton of time figuring out more about where other companies were failing. I think I spent basically every evening and Saturday for months on this. And I can get into what we learned, but one of the big things is really that if you tie promotions to scope, you're really over-indexing on just one type of complexity. And you're also encouraging a lot of empire building.

When you were going and redesigning the incentive structure, like what was the biggest changes you made compared to what Uber had for this new company? Okay. Yeah. So if you look at what Uber and SaveMeta and Amazon have, they have a lot of competencies that read something like, I design processes for the company as a whole. I design, I partner with directors on strategy.

I influence other teams on undefined goals. These are really position-oriented things. And what this is basically saying is, you get promoted by being loud and being well positioned, which kind of fucks up younger people because it's really like be loud, be good at politics, be good at maneuvering. Some of that's valuable, but if everybody does it, people don't actually learn to be good at the corporate job and it's bad for the company.

So what we did instead is we started with these 1,000 different examples of where people differentiate themselves on ability. we converted that into 250 human attributes. And then I performed a principal component analysis to collapse it down into 12 different dimensions where each dimension is basically like a skill gradient. And as you climb those skill gradients, your compensation goes up.

If you've got more impact and you're more skillful on the things that we might believe matter than your compensation goes up. Where did you source the initial thousand examples of high performance from? Yeah, so this is talking to a ton of engineers. There's like 12 books that I read. I also looked through years of our calibration notes.

Every time we do quarterly calibration, we'll talk about why this engineer did well. So I just scraped all that out. And then wrote them all down. This is about 1,000. And I made certain that they're all things that I knew personally had actually happened. They weren't bullshit. otherwise you could get into a situation where the skill gradient is bullshit at the high levels, right? It's like just an unachievable dream.

What are the biggest attributes that differ from well-known ladders? Because everyone who works at these big tech companies kind of knows the existing. So what are the things that you introduce that are different because of this analysis? Yeah, I think the probably main difference is this. is this emphasize on truth-seeking and, like, how you perform very well instead of what you perform very well. If you look at, I think Meta's level of leveling guide, it'll say you have to be able to, like, influence other teams at E6 with good ideas. And in our ladder, we'll say something like, you have to be right most of the time when questioning a foundational engineering and product decision or industry norm. And it's not so much about convincing people.

it's how good are you at actually getting good ideas. And there's a separate competency on how good you are at communicating ideas, which we define what good looks like, instead of just saying it's about like a social, kind of social proof thing. I see. But then how do you determine if it's good communication or not? You give a lot of examples. Right.

In your document where you define these things, you say, okay, here's the verbal description of what it means. And here's a few examples. And then when engineers are scoring themselves, they can kind of look at the examples and go, well, I mean, if I'm being honest, was I that good? Right? If I look at this artifact, does it stand up to add? I'm not sure how it fixes the politics, such social problem of calibrating engineers because you could have a manager that lists out those examples but says them in a biased way. So, like, how do you get rid of that incentivizing politics?

Okay. Yeah, so this is still a thing that managers could try to do. It's a little bit, the kinds of things that they would posture around would be different, though, right? Like the engineers aren't going to spend as much time trying to figure out how do I, how do I, like, design company-wide processes, say, or like explicitly influencing other teams is not necessarily the goal anymore. So you might have people posturing around being good at communication. and exaggerating that, but at least they're trying to get good at communication or they're trying to get good at truth-seeking, which is almost always beneficial, as opposed to something that's not always beneficial. There's still, though, things you can do to protect against this,

and the answer is it's like a lot of work, right? You have to, like, spot-check managers, and if you find them exaggerating, you have to fire them. Easier said than done. I'm curious, like, how... Is it? Well, I mean, I don't know. Who wants a liar in their team?

There was someone else that I had on before, and he said, that's a big problem in management, is it's someone who is bad for some reason, but is well liked. They're one of the biggest problems because it's difficult to fire them. What would you say to that? Yeah, you know, it's funny because I do hear this, but I don't think that it's really true, right? Like, it feels very difficult to fire them if you're a frontline manager because you like them, and you see kind of the social bonds. But often there is a bit of simmering resentment about that person.

The people on the team who are working hard, they're like, yeah, man, Joe's so great, but why the fuck did you just go home at 2 p.m.? Like, why am I working at 6 p.m.? I feel like a chump, right? So if you remove this person, immediately it may feel bad, but a month later the whole team will be happier. You've mentioned truth-seeking a lot in this new ladder,

and I'm kind of curious, like, How do you prove truth-seeking? Like, how do you give examples of someone that did that well? Yeah, I mean, a lot of it is, have you uncovered something that is, like, highly unconventional? And there's a bunch of different dimensions that could result in that. Like, oh, it was actually in plain sight for a while and nobody found it, even though it's highly valuable. It's sort of a signal. or is it different than what every other company does,

but because our constraints are different, it's actually beneficial to go against the grain. Like just some, there's a bunch of different dimensions that result in truth seeking being difficult that can you latch onto. And then there is a bit of subjectivity. You know, there's not like, you have to kind of write it down

and then calibrate managers on how to score these things. It's not as easy as counting PR stats is, but we all know that that's not a great way to judge engineers. Yeah, yeah. Well, a lot of companies have some sort of measure of, like, directional contribution. Like, you know, how did they, how did you change the direction of everyone based on your contributions?

And that sounds very similar to truth-seeking here. Yeah, I mean, it's not like these are, the way that tech company, have designed their leveling frameworks and their center of structures are not completely broken. And in many ways, they're just way better than what exists in the like Dilberdesk era of the 1980s. There's some ways, they've been actually, I think, kind of nicely designed to reward you once you get into a specific position. And they're very good at rewarding you once outcomes are achieved. They're a little bit less about the leading indicators.

but you're not going to get wildly different results. You'll just make it a little harder for some people and a little easier for some other people. Yeah, one thing I'm curious about because a lot of tech companies, they incentivize the result, not necessarily the thing that happens before the result. And so, yeah, is there a case where you could have an engineer does a phenomenal job on something that gets deprioritized

and they would still get rewarded? Oh, yeah, of course. Yeah. Oh, okay. Maybe if you're like at the highest level, you should have the business savvy to know that it's not going to be. But if you do phenomenal work towards a project and for no reason related to you, this thing gets canceled, you've still done phenomenal work,

and we can still measure that you've been doing phenomenal work and reward you for that. It's kind of on our fault as least. Our fault is leaders that I got canceled so late. One thing I'm curious about is, and I think companies like Amazon are famous for, you know, not really rewarding the high performers that much. And I was curious to ask you,

because you've worked on company design for a while now or engineering organization design is like, why do these companies not reward their highest performers? I held off saying this, but a lot of it is just because they can get away with it, right? Like they think, oh, the equity went up by a lot. Maybe it's a little bit unjust to pay you less because your equity went up.

I think it's unjust. That's basically your investment. You've got a good investment result. It shouldn't factor in future decisions. But they can get away with doing it because people are mostly happy that got a lot of appreciation. We actually made a point

of not doing that earlier on. I just think it's, if you design your company processes around being just, it's going to be better for you the long run, but you kind of just got to believe that. You know, we've been talking a lot about big tech, and I know you started off at Google.

And I'm kind of curious, like, you know, what was that like or what did you get from starting at Google? I think the main thing that I got from working at Google is I got like a real deep, seated skepticism for how well tech companies are run. In my, all right, so I joined Google, and in my first week, I see that there's a guy on my team

doesn't do any work. And let's call him Frank. And I talked to my manager about it. I'm like, what's the deal with Frank, yo? It's not how I talked, but you get the point. And my boss says, yeah, I know, but he's such a nice guy, Brian. So just lay off. I talked to my engineering director shortly after this, and I say the same thing.

He is a little bit embarrassed. He knows that there's something off about having people that don't do work, but he repeats the same thing, which is that Brian, this guy's a really great guy and everybody likes him. I actually complained a lot about it, and I can't prove anything, but he was eventually moved off my team onto a team where no one would complain because no one on the team did any work. The team was just like, they're building demos for the gift shop or something like that.

So what you got from that is that, like, that's a Google problem and that he should have been fired. Yeah, absolutely. Or, yeah, he should have been fired or there should have been a serious conversation. Right. And we're like, so you've been here for a while, you've done good work, we're still paying you. Like, could you? Could you do work again? Right?

You can't expect us to keep paying you if you don't. And then he might have gotten back into it. Why do you think that that hard conversation wasn't? had at Google? I mean, so there is something Google specific that exists there, which I can get back to, but generally at large companies,

the performance of the company is fairly decoupled from the performance of individual team, so it does become easier for this kind of thing to happen for managers to do things that are convenient for themselves, even if it hurts the company. But there's also this natural

thing that happens at companies of any size, where it takes a lot of energy, to raise a standard. And it takes very little energy to lower it. Few people will complain if you suddenly ask everyone to do less work, which means if you have entropy in a system, standards will naturally fall over time until the company dies. It'll just keep going down until the company dies

or until some kind of trauma kicks it back into place. Right? Like if you're at Google right now, the deep mind team, oh, they're working hard. Right? Like Google's like, alphabets like, oh, there's an existential threat to, existence, the deep mind team better work hard now.

I mean, Andrew will always lower the bar. And there was this thing at Google, which I cannot prove existed, but several managers at Google told me it. So I haven't seen it writing, but like a VP and some managers told me it existed that around a decade ago, Google had this policy where they wanted to keep as many smart people on staff as possible, even if they weren't working anymore, because maybe they'd work hard again in the future, and they didn't want their competitors to have. have them. So that's just a super unique Google thing. I mean, that's kind of crazy. I don't know of

any other company that's done that. I see. And do you think there's any merit in that kind of hiring strategy? No, because there's a lot of smart people in the world. I think it's fairly difficult to have a monopoly on intelligence. And now at this point, I'm kind of curious, like, you know, what are you working on these days? And maybe we can talk about that a little. Yeah, okay. So it's fairly secret, and we don't usually talk about it with reporters because we're in stealth. But I talked to Travis. about it, and he said, I could give you a bit more than we've given anybody for. So I'll give you some stuff. I'll give you the whole, like, thesis of the company. The core insight is that

no one should cook their own food in a few decades. And no one should cook their own food. And we know that people don't want to because when you look at places with lower cost of labor, like middle, upper class people, they don't cook anymore. Like, of course they don't. they choose to save 10 hours of their time a week and take it back. And if you look at the U.S., there's like Uber Eats, there's DoorDash, these things are fairly convenient, they offer some of that, but they're super expensive, so nobody can use them every day. If these things were way cheaper, though, that would work.

And here's the second core insight, which is that there's a ton of avoidable. waste in the food supply chain. So we're just kind of scratching the surface on this, but we've built robots that reduce labor costs in real restaurants by 50%. We've built this lunch logistics network that reduces the cost of a meal overall 30, 40%. We have what else. We've got this real estate thing, where the cost per meal is half of what normal cost where meals are, and we also have the software product called Otter.

Processes 18% of the world's orders that makes them a bit more efficient. And we've got all these things going going. Some of them are early, some of them are a lot of customers, but it shows just how much an inefficiency can be squeezed out. It shows that if you're willing to spend the R&D money, you can make real moves on lowering the cost of food that's made just for you, like fresh without any leaper on your part. So if the size of the pie is big enough, we can make this happen,

and Americans spend $2.5 trillion a year on food. So if you think about the most conservative cost modeling possible, like you just imagine that you redesign this whole supply chain, you have super thin margins. This is $5 trillion sitting on that table right now, just waiting for the companies that go and solve this problem. And that will happen eventually no matter. or what, right? Eventually, robots are going to do a little thing. But we think that we can do a lot

of work now to enable this. And then hopefully we capture a few trillion dollars of value and our partners capture a few trillion as well. You know, one of the things that I'm most curious about, because I remember at some point, I was living in SF and I got an invite to recruiting event for Cloud Kitchens. I'd never heard about it. It said, you know, we're a large stealth startup. Hey, we're going to treat you at a dinner and just come and listen about it. And it, and it's, It was something I never heard about, but it had Travis's name. One of the most unusual hiring strategies I've seen for a company at that scale. So I'm curious, why is this company so strict on privacy?

Yeah, right. So, I mean, we are super strict. You're right. We don't have a corporate website. We ask employees not to post that they work here on LinkedIn. We were to do a fairly good compliance around. We don't have any PR people. Here's why we wouldn't have done it.

And I'll tell you why we did it. When you're founding a company, if you're very public in the media, it's easier to raise money. It's easier to hire. It also makes the founder's ego swell, all of these great stuff. And we, our CEO built Uber. He's a billionaire. He's got a good network. He's got funding.

And his ego is doing just fine. So these upsides didn't really mean a lot to us. But the downsides of being public did. if you look at 2018 and you look at like headlines sentiment, you can actually go and check this. I've checked it. It took this nosedive towards negativity after Cambridge Analytic happened. The U.S. Pipeless just loved reading shady news about tech companies.

So if you're working for a tech company at that time, you're constantly reading bad things about yourself. And it's very distracting to employees and especially distracting to leadership. It takes your mind off of innovation and puts you more into, damage from a place. And then the other thing is that we really wanted to minimize the amount of competitors we had. If you've got a good idea and your founding team has a strong track record and you're visible,

other people will see that who are enterprising go, maybe I'll just do that. When we launched in Korea, we are very public about it. We talked to reporters. There wasn't just one competitor or two. There's three. It was a whole ecosystem of people that decided to compete with us just because we had a famous starting team. And then the same thing happened in the U.S.

where this company received $150 million. They got a vision fund investment, even though they had very little going on for them. And yeah, they were never going to make it. They'd never had a hope. But it was still annoying. It was still distracting for us.

The answer is just shut up, be quiet, and build great stuff and don't talk about it, and then win silently and confidently. I mean, this to me is like the very opposite. I see a lot of other companies. They get started and they start with distribution actually. Like they have these rage bait products that go out and explode on Twitter and then, you know, people start using it from that.

And there's obvious benefits to that. It's like you get users. You get people talking about it and all the other benefits that come with that. So, like, how are you handling distribution then if you're so quiet? A lot of the stuff that we do is B2B. And you can still do marketing around individual products. We have products that we talk about quite a bit, right? We have picnic, there's Otter, hundreds of thousands of restaurants use it.

And there's ads around those things. We just don't talk about our core company as much. So the main thing that it adds a bit of difficulty around is hiring. So people like me have to go on famous podcasts, you know, and see if they can mitigate that a bit. Right. But I think it's not as hard for sales as you'd expect. Coming to the end of the conversation, I just want to go over some career reflections. And so one thing that I'm always curious about is when you think back over your career, what's your biggest career regret?

So I've messed up a lot of things, especially early stage. and there's things that, you know, you'd think I might regret, and then I don't. All right, so I was a first year undergrad. I was interring an Apple, and I was building this, like, tweak to the OS. It's like a fork of it that it made the phone easier to use in sunlight, which is a problem at the time.

And I remember I was showing it to my mentor at lunch, and it just so happened that Steve was sitting right next to the table beside me. So I mentor Ken, amazing guy, just starts like really spouting off on how good this prototype is. He's like super loud. He's like, this is a game changing for the company.

It's going to differentiate us so much. It's going to make us so much money. He's like, he's like, all right, let me check up this thing. He walks over, he sits right in front of me. And Ken's still going. And I'm like Ken, Ken, Ken, Ken, wait, come on, it's not that big a deal.

It's like 50, 100 lines of code. It wasn't even that hard. Steve like sighs. You know, you could see as wide. Did I sit down? He rolls his eyes. And Ken's trying to win him back. But Steve just, like, walks away.

Right. He doesn't say anything. And at this point, Ken explains to me that just how badly I've fucked up, right? Not only did you lose your chance to impress this industry icon, which is like, would be a story for your life. But also, it's very likely that this thing that you've been working on will now never see the light of day because my team does not have funding for it. This is just a thing you're trying out, Brian. So by doing this, you've killed it.

And, you know, the thing here is that I didn't know anything of a product, how to pitch it, and I was a really awkward 18, 19-year-old kid. So there's really very little chance that that was ever going to go, right? And even that night, when I got home, I didn't feel too bad. I was just like, oh, I now know I'm an awkward kid. and I should learn how to pitch better, I guess, right? Yeah, that kind of thing I don't regret because I couldn't have done better. What I do regret is the places where I, like, knew what I should do,

where maybe I was just too uncomfortable communicating about it or I was worried I'd do a bad job so I didn't bother. Those are the kind of things I'm embarrassed about. And do you have a concrete example? I don't know if I have a concrete example. example that I can say without making people feel bad. But it's like, imagine you're making a decision and you're halfway through it. You realize it's the wrong thing and you just kind of go with it. Maybe you're just two years in your career. That's a really easy thing to do. But you should

be really honest. We're like, actually, you guys, I was way off. And now our product's off track. We can keep going forwards, but everyone on this team deserves to know that I made a mistake in case we want to go and correct it. Even not knowing whether or not we would have corrected, I still look back on that. I'm like, that wasn't great. I should have been more honest. So the regret is, I guess, not seeking towards the truth.

Like if you knew there was a problem in the middle of initiative to cut it or at least share that we might want to reconsider. Yeah, that's right. And I think you kind of, I feel like you owe, even if you think you can't convince people, you owe them a bit of the benefit of the doubt that they're going to be receptive, they're going to hear you out.

And you kind of have to try. If they ignore you, it's fine. If you're wrong, it's also very fine. But you should try and you should get better at being able to communicate that kind of thing. You mentioned Travis earlier. I'm curious. Do you have any interesting stories

working directly with Travis? Yeah, I don't know. I mean, I've got a lot. But so, okay, here's what everybody knows about Travis Kalanick, intense palignath. What people don't know is like intense dad energy, right?

We had this off-site where is the senior engineering leaders and Travis, it's over the weekend and we've got, you know, like work sessions. In between them, Travis is just like having a blast to teach him to how to play backgammon. And he's also almost like a world-class water skier. So he's coaching people how to water ski.

And he's super patient with us, even those of us that are like pretty unathletic, which let's be honest, we're engineers, so it's like most of us. He's pretty patient with like all of us that needed a lot of help. It sounds like you went to Cloud Kitchens from Uber in large part because Travis Kalanick was founding it. And I'm curious about picking companies based on the founder. And so in your case, like when you reflect on that, like was that a good decision? Would you recommend that for others?

Yeah, I think it can make a lot of sense for founder-led. early stage companies. Because these companies, a lot of what matters is what is their current positioning and what is their culture and what are their standards? And a lot of the two points there, they're just being set from the top at a company where you have somebody with that much control. So if you've got a really good person, it can be just a huge multiplier for the effectiveness of the company relative to others.

And it also can also go very much. other way if you don't have the right person in charge. You mentioned receiving advice from other people, and I'm curious, is there a single advice that impacted your career most? Okay, this is gold. I've got something. I had this computer science teacher in high school, and I would ask them a lot of questions, and every time I asked a question, their answer would be like, Brian, figure it out for

yourself. And, like, I actually never, I never learned whether or not it was because, it was a because this was a good pedagogy, or if they just didn't know the answer, right? It's possible they knew nothing about computer science. But it didn't really matter. It's very good advice because 95% of everything that you learn professionally is going to be self-directed learning.

So you've just got to get comfortable with that and accept that you always have to be learning and, like, pushing yourself to go kind of beyond the immediate area at which you're comfortable. Was there a top book that impacted your career? No. So instead, I'll give you kind of a cheesy answer for books that I'd recommend. If you are like a front engineer, I'd recommend you read how to pass the system design interview. And if you're like an MLE or a back end, read something like how to pass the PM interview. What these books have do is they're designed to help you cheese your way through an interview process, which is fine. But what's cool about them is that they are designed to give you a very broad and superficial understanding of a domain that you're not already very familiar with. And if you go and you do the exercises, you'll actually remember it.

So it'll stick in your head, and then you will have a good ability to have productive conversations with people that are in other roles in you. And that's very valuable. It'll also give you some foundation to learn stuff in that domain. If you could go back to yourself when you just entered the industry and give advice to yourself, what would you say? I'd probably say younger self, be more courageous and less embarrassed. You're going to fail a lot and it's fine.

That's easier said than done. Like, I feel like embarrassment is like, you just feel it. Yeah, I know. I mean, this would be the opening two sentences before a larger conversation. about how to search your own feelings and understand them. Maybe it would actually be, Brian, you should go to therapy. That might also be good advice.

I think it's generally helpful to be more in touch with your own emotions for your own sake, and it helps you relate with other people better. Cool. All right. Well, yeah, thank you so much for your time today. I really appreciate it, Brian. Yeah, it's fun, Ryan. Thanks for listening to the podcast.

I don't sell anything or do sponsorships, but if you want to help out with the podcast, you can support by engaging with the content on YouTube or on Spotify if you want to drop a review. That'll be super helpful. And if there's any guests that you want to bring on to, please let me know. I feel like sourcing very senior ICs. There's no well-studied list out there on Google that I can just search this up. So if there's someone in your org or at your company who you really look up to and you want to hear their career story, let me know and I'll reach out to them. Thank you.