Podcast
Join Viktor, a proud nerd and seasoned entrepreneur, whose academic journey at Santa Clara University in Silicon Valley sparked a career marked by innovation and foresight. From his college days, Viktor embarked on an entrepreneurial path, beginning with YippieMove, a groundbreaking email migration service, and continuing with a series of bootstrapped ventures.
Links
Follow Me
Follow Me
Join Viktor, a proud nerd and seasoned entrepreneur, whose academic journey at Santa Clara University in Silicon Valley sparked a career marked by innovation and foresight. From his college days, Viktor embarked on an entrepreneurial path, beginning with YippieMove, a groundbreaking email migration service, and continuing with a series of bootstrapped ventures.
Startup Founder Lessons on Scaling Teams, Systems, and Culture with Kevin Henrikson
Play On
23 APR • 2025
1 hour 16 mins
Share:
In this deep-dive conversation, Viktor sits down with Kevin Henrikson to explore what it really takes to scale technical teams, ship faster, and survive the transition from startup chaos to operating at enterprise scale.
Drawing on his experience across Zimbra, Microsoft, and Instacart, Kevin shares lessons that most startup founders only learn the hard way. From being turned down for a coding role and later managing the team that rejected him, to leading engineering through acquisitions and hypergrowth, he breaks down how systems, structure, and culture evolve when a company goes from 10 people to 1500.
We get into the operational and cultural challenges behind some of the most common startup transitions:
- Why acquisitions often fail due to “organ rejection” and how to avoid it
- What changes when a founder becomes an advisor inside a large org
- How a simple Friday shipping cadence transformed Outlook Mobile’s engineering culture
- Why scaling isn’t just about hiring, it’s about systematizing decision-making and trust
- What breaks first when demand suddenly explodes, as it did at Instacart during COVID
Kevin also shares his approach to buying SaaS companies and applying AI and automation to operate them more efficiently with fewer people and more resilience.
We also cover:
- The real role of a CTO at scale (hint: it’s mostly not about tech)
- How to build teams across geographies without creating silos
- Why code, not people, should define your infrastructure and processes
- The value of having a clear North Star in operational decision-making
The episode closes with a look at how systems thinking and automation are reshaping what’s possible in modern engineering orgs and what founders should pay attention to before things start to break.
Whether you’re a technical founder, CTO, or operator building your first team or scaling your fifth, this conversation is full of practical insight from someone who’s been through every stage.
Transcript
Show/Hide Transcript
Welcome back to another episode of Nerding out with Viktor.
Today I'm joined by my good friend Kevin Henrikson.
Welcome, Kevin.
How are you, buddy?
Good to see you.
Good, good.
I am excited to have you on.
We've been talking basically since I think last season to have you on, but now we finally got around to put on the calendar, so.
Yeah, me too.
So today we are going to talk a lot about engineering and scaling engineering in particular, you have a long history of both building and scaling engineering teams.
So we're deviating slight bit from our normal topics, but I think it's going to be a good one.
So for those who are not familiar with you, Kevin, give people a quick overview of your background so we can give people like some context to work with before we dive in.
For sure.
So yeah.
So been building companies in Silicon Valley for like the last 25 years a lot with the same team and same co founder.
Spent about 18 years building email across several different companies.
The last one was a company called Accompli we sold to Microsoft that got renamed to Microsoft Outlook.
And so if you have Outlook Mobile on your phone, that was our original app.
And then when I was there, sort of ran the engineering teams for all the non Windows, so iOS, Android and Mac.
And so there's hundreds of engineers working on that across know five or six different global offices.
After that went to a company called Instacart just before the pandemic.
And so again, you know, kind of had around 40, 50 engineers when we joined.
Took that, you know, to whatever, 1500 engineers.
My partner JJ stayed there until the IPO, was kind of chief architect.
And so again building there it was like shopper side.
So like building fulfillment, a lot of machine learning, operations research, you know, routing.
So basically the kind of hire to fire arc of a shopper.
Like how does, how do you join?
Also ran kind of the growth engineering team for a minute while I was there, but I'm with that and now working on AI.
So again, sort of, you know, kind of following that.
You know, if you think of the early days of like, you know, in the 2000s when I got out of college, it was like Internet.
Then we did mobile and we did kind of Web2 or Web2 mobile, you can kind of like, you know, interchange which one came first and then, you know, now AI, right.
And I think like, you know, it's constantly just looking for, you know, what's kind of the cool new tech, how can you apply that?
And I just, you know, love like sort of applying technology to businesses.
Yeah, we met in the email space based.
I'm trying to remember back.
I think that must have been one when you started doing angel stuff I would imagine because it was just after Zimbra got acquired I believe.
Right.
And were doing yippee move.
Was it yippee move or yippee?
And I was, I used your stuff to move like some, I was moving some email accounts.
I think it was moving.
I think I had a couple different small companies and I was moving a couple Gmail accounts like from like one legacy provider into that and I was moving them between Gmail accounts and combining them and I was like, man, this thing works.
And you know, I had a pretty, a lot of email.
Been working in email.
And so I think we ended up in support chats together, kind of met each other and then yeah keeping in touch I mean for quite some time now.
That must be like upwards was 10, 15 years by now.
I think it's been a minute.
Yeah, exactly.
So I've seen you and follow you from a try from afar.
But it's been exciting seeing that trajectory coming up and it's been really exciting.
And like let's go back to those early days at Zimbra and because you were like really early in the open source days, like that's like open source was not.
It was a thing but like it was one of the first like enterprise open source I want to say back in those days, right.
It was one of the earliest ones where this was freemium model with the idea it was, if you think about it today it's pretty common.
It's like take open source software and then do something interesting with it.
So we put together like a collaboration tool set.
So email calendar, contacts again store of essentially picking up the best of breed open source elements from like these different components.
But as you know, you've been in open source for a while.
Like typically the open source stuff does like their one thing really well, but it's not really well integrated.
It's not easy to get it set up.
There's a bunch of challenges you have to do.
And so the company was built around this idea of like hey, build a really interesting collaboration mail app.
That worked.
That was like, hey, if you're kind of a nerdy open source guy, this is the stuff you would have picked to kind of, you know, think of it as building your home PC but for email.
And then from that we built enterprise extensions around that, around disaster recovery support with the thing of like hey, if you want to do this and want to do this at your own company.
You're going to want like somebody to call.
Your boss is going to want somebody to call to sort of justify it.
And so we sold into a lot of like places where Microsoft Exchange was not strong, so international schools, education, government, those kind of cases, and ended up getting that company got acquired by Yahoo and then Yahoo.
Then were there for just a minute.
It was.
Yahoo was going through its own sort of turmoil.
So Brad Girlinghouse acquired us.
And then, you know, Carol Barts came in and she was like, oh, I want to move this thing.
And so she ended up.
We sold it to VMware.
So kind of sold it again.
And then at that point VMware sold it to another private equity kind of small startup.
And that was kind of my last part of that journey.
And went on into.
Is Zimbra even around these days?
It is, yeah.
No, you can go to the.
It's still there.
It's been acquired by.
It actually got acquired by one of the biggest early customers.
There was a big customer that was hosting them for like other service providers.
Right.
Cynicore.
So they were basically buying, they bought Zimbra and then they would host it for like tier 2 and tier 3.
Like so if you're like in a random small rural town and you had like somebody, you know, providing phone service or cable service or dial up Internet and you need an email, they would host the email for you because, you know, you didn't want to do that.
And so then they were using Zimmer to do that hosting.
So they were like a, you know, kind of an early SaaS provider of Zimbra for others.
Interesting.
That's funny.
And you joined as.
When you joined Zimbra.
Like how big was Zimbra when you joined?
Like, it's funny.
So I mean, talk about like opportunities missed.
I remember having coffee with the founders.
They, you know, they either just got the funding or just started.
And I would have been like employee number five something, you know, early.
And I was like, man, this is crazy.
Like, that would have been my first sort of startup because I was working.
It was a public company that were working for that, you know, kind of went out public.
And I'm like, that's crazy.
I'm like, I have a few thousand dollars in stock.
Like that'd be wild to like leave.
It's going to vest over the next few months.
And literally I turned them down.
And so I said, no, I don't want to do it.
And, and so I stayed at the company Open Wave for another year or so and they kept hitting me, hey man, come over.
And then.
So I think I ended up joining kind of around employee 25 or 30 and crazy stories to talk about again.
I got in there, I interviewed and at the time I had been doing like web stuff.
So I was kind of like, you know, as an individual contributor, like, I was stronger in like PHP and JavaScript in the early days, right.
And so kind of interviewed with the web team and they're like, this guy's, he can't code.
And they literally said no.
And they said, then they said, we can't hire you're just not good enough.
And I was like, okay.
And they're like, what could you do?
And I was like, well, I don't know, I can help out with like other stuff.
Like I can talk or whatever.
And so they ended up, I ended up taking.
My first job was developer relations.
So I was like the forum guy.
So I was Kevin H.
On the forums.
I posted thousands of posts on this open source forum.
So I was literally the forum guy.
And you know, it kind of came full circle, which is funny because I got in there, got to know the guys in the web team.
They're like, oh, you are actually smart.
You're just not an incredible engineer.
You can't write the code, you don't know how to code.
but you're, you're pretty helpful.
And so ended up running the web team.
Surprise, you know, became their manager.
All the guys that said, you, I can't be hired and like kind of blackballed me from getting into the company.
I ended up becoming their manager and then, you know, kind of running engineering as it went through the different kind of phases of the acquisitions.
All cool dudes, they're all, you know, went on to do other successful stuff.
But it was pretty funny to see the early days of like, yeah, just getting declined after being invited as an early employee because at that point, you know, when you found a company, you start to scale and build an engineering team, you're no longer doing just founder level hiring.
You're, you know, you want the team to absorb it, you don't want to force people in.
And so you had to kind of make your way.
And so I had to kind of earn my right.
And, and my thing with my view was like, look, I knew I wanted to work with those guys.
I knew I'd made a mistake by not going earlier.
And I was like, what can I do to get in there.
And like I said, they ended up bringing me in to do this kind of like evangelist type role.
And, you know, I was out speaking at conferences and talking to developers and things of that nature.
And then again, kind of leaned back into engineering and building the team as the startup grew.
That's funny.
And walk me through the acquisition into Yahoo, because obviously Yahoo is, I would say, can we say, notorious for acquisitions.
It's not really where.
It's not really where startups get absorbed and thrive, right.
That not really the track record of Yahoo.
To be honest.
I mean, a lot of acquisitions don't go well at broadly in the Valley, not just Yahoo.
I mean, like there's, you know, Cisco is, you know, notorious for acquiring lots of companies.
Most of them don't, you know, couple of them worked well, WebEx and things of that nature that, you know, became pretty powerful for them.
But I think a lot of them, they bring the team in, they take the technology.
It doesn't really go the way they want.
They promise things.
The promises are broken on both sides.
So I think, you know, Yahoo was no different.
I think, again, something I've learned, you know, as part of like this sort of acquisition of how to like, better.
I think were in, in one way to say it, like a terrible acquisition.
You know, our bedside manner was bad.
We kind of came in with this like, hey, were these smart startup guys.
We've built email.
You guys at Yahoo.
Mail are doing it wrong.
You need to kind of do it this way.
And that became like this crazy organ rejection where they were like, they hate us.
And they were like, wait, we bought this thing and we ended up getting Yahoo.
Calendar migrated to Zimbra Tech, but we never finished the mail migration during the time were there because there was just a lot of organ rejection.
The Calendar was really bad.
And so that one was.
And it's in.
Calendar is very hard.
And so.
And the number of users was much smaller.
Like, you know, 10 million people used Calendar where hundreds of millions of people used email.
Right.
But it's forced us to do this kind of like if you've seen the movie 300, where all the gladiators put their shields up and kind of hide.
Right?
Right.
Like that's the way we ended up.
We literally had our own area in the Yahoo office where the Zimbabwe guys would all kind of camp out away from the other male and collaboration team, even though were part of it.
So were kind of like this, you know, ugly stepchild thing kind of stored in the Corner.
But we kept our enterprise business.
We kept doing open source sales, like very.
On Yahoo stuff like they're a very consumer company.
We were doing enterprise sales smelling small businesses.
And because of that, when it became time for Yahoo to sort of unwind some of these things, they're like, oh, they're shutting things down, killing things, just laying people off.
They're like, oh, the Zimmer thing's actually worth something.
It's actually doing revenue.
There's millions in recurring revenue and there's real customers and their sales here.
And so then that's where the VMware acquisition came out.
And were able to kind of sell the company again into VMware.
And then because VMware was on this, they had been a lot of.
Palmertz was the CEO and he had hired a lot.
He was, you know, the guy that kind of invented the word dog food at Microsoft, like, hey, eat your own dog food, try your own software.
And he had brought in a lot of like the old guard from Microsoft that were in the early days of Windows and Office.
And their view was like, man, VMware has this like lockstep sales mechanism or motion that sells into it, obviously selling virtualization.
Could we also have an app stack that's a little higher, that's something akin to Microsoft Office but built on the cloud.
Right.
And so they acquired a bunch of These kind of web2SaaS, early kind of JavaScript driven collaboration tools with the idea of bringing those together and building like a kind of a, an app group.
And they picked up Bitnami around that era as well.
It's a bit later.
I think it was Bitnami.
Right, they picked up as well.
Right?
Yeah, they picked a bunch of companies.
And so it was cool.
We got to meet a bunch of really cool founders again.
Didn't really work like as you can imagine, the buyer of VMware and buying infrastructure software, the data center side, the, you know, the networking side, very different buyer than who bought Microsoft Office, right?
Yes.
And who bought Exchange.
And so like it just didn't fit.
And it was like this again, really weird thing.
And so as that started to unwind, you know, and they started to sell pieces of that and kind of unload that.
Similarly, Zimbra was one where a lot of companies, they just shut down what they had bought.
But Zimbra had this enterprise base of like recurring revenue.
Somebody would buy it.
And so again it kind of, you know, the price kind of went down, as you can imagine, in each sale.
Yeah.
Closer to what the revenue Is and less of like the.
There was less of a premium, if you wouldn't say for like the team and the innovation at that point.
Because it's like man, we're just buying it for what's the revenues there.
So another kind of company bought it and then eventually like I said, one of the early customers bought it because they were the ones that knew how to like monetize it.
Yeah.
And.
And it was basically just support revenue, then support contracts that you're monetizing.
Support revenue and a little bit of nre.
So non recurring engineering.
So like consulting type work around it installation, helping them, you know, go do and do migrations and things of that nature.
But the core of it was yeah what looked like support revenue but they actually got some code so they would get like an enterprise extension or a blessed build that had like some extra features on it around disaster recovery support for different architectures and things of that nature.
But it's interesting because that's an interesting insight into how open source revenue generation has evolved over time.
Right.
Because that was like if you go back to MySQL kind of from the same era, right?
In the sense that when Oracle acquired them that was support contract largely as well that they built their business around money.
Zimbra was built on MySQL we use my sequel and a lot of the databases underneath.
We ended up moving to like Berkeley B and a couple other sort of different technologies for scale reasons and other, you know, sort of like alternative architectures.
Because you can imagine like when you get to like carrier level scale with tens of millions, like comcast for example, AT&T kind of like really big scales.
We did.
So Xfinity mail ran on Zimbra like that was one of our biggest customers.
I know because we work with them at Screenly.
Sorry at Yippee Move.
Actually were working with Comcast as well, which is funny crossover.
Good stuff.
All right, so the biggest lesson for that acquisition that was really just like you kind of the organ rejection as you call it, right.
Like being kind of like not kind of embracing being absorbed I guess by a larger entity.
So walking forward then to the next big thing was a company, which is your next big venture, that then subsequently got acquired by Microsoft.
How did that experience with VMware and Yahoo kind of shape your worldview as you made your way into the next acquisition and how do you think about that?
So personally, I mean, completely different approach.
Right.
And so I think the approach that we described at Yahoo and to some extent at VMware but not as much like this organ rejection.
You're like, hey, we're the intelligent jerk that come in there and we're going to, you know, we're going to teach this big company how to be startupy and we're going to have this founder led, sort of like startup led way of going through it.
It just doesn't work for most of acquisitions.
And what I advise, like, you know, people that are getting acquired now or early founders or, you know, when you're going through these acquisition is like the day you sign the acquisition, you need to switch your hat from like founder leader, startup person to like advisor.
And advisor is a key thing because when you're an advisor, you can say all the smart things and give advice and you can guide and coach, but you can't ultimately actually do the thing typically.
And you're not.
And you should be okay with that.
Like, it's okay that like the person you're advising ignores 10% of what you did or ignores 90%.
It only takes 10%.
That's up to them.
And so when went into Microsoft, I had this kind of view that, hey, I'm just here to help.
I'm here to help scale their systems, give them advice.
So I went around and gave like lots of talks to other groups, did a ton of like more evangelist kind of work.
If you almost go back to my early Zimbra days, right, of like evangelizing like the way that we built software.
Hey, man, right?
You know, Microsoft had kind of traditionally always shipped every three years.
They were like, hey, let's go to every year.
They were really proud of their monthly release cycle with some of their apps.
And were like, no, no, we're going to ship every Friday.
The best way to do mobile is, you know, five star apps shipped every seven days.
And that's the way you iterate in mobile.
And you know, on Friday we would finish the build, we would test over the weekend, and then we would submit to App Store on Monday, fix any bugs, and then Tuesday we would release and then we'd do it again.
And that model and now today you literally look at it.
Outlook Mobile still ships like that.
They ship every week.
And if you look at that, so does all the Office apps.
They all have this release channel where they ship every week.
Because in the mobile space it's okay to have those updates.
They have to be clean, they have to work and you want to just keep taking shots on goal.
You don't want to have a bunch of unshipped Software that's sitting in like GitHub untested or whatever.
Right.
And so for us, like going into Microsoft, the acquisition was, you know, on a bunch of levels, way more successful.
Right.
The app is like, you know, hundreds and hundreds of millions of users use Outlook Mobile today.
That app is still very much the accompli.
Vibes are in there.
There's actually people that are still there from the acquisition, some that have left and come back actually that came to Instacart with us.
You know, one of the lead developers, Ogden, who's on the, you know, left and came to Instacart and then went back to Microsoft afterwards and taking some time off.
And so like really has like this, you know, much more glamorous story of like what Outlook turned into and how that not only transformed a lot of the stuff that was the way Office worked and the way mobile apps worked, but I think a lot of that stems from like us as the team and the founders thinking a lot differently than the way that what we learned from going into Yahoo or going into VMware.
And then our co founder, so JJ and I were the, you know, two of the founders and then Javier was the third founder.
He had actually also sold a company into VMware and like Zimbra, you know, it didn't go well and it was like a tough acquisition and like it didn't have a good fit and well, you know.
But the his was called Hyperic.
They sold into Spring Source and then Spring Source got pulled into VMware and there again like they were good, they had traction but didn't reach the like, you know, 10 years later, like we're now Outlook Mobile has been into Outlook, into Microsoft for 10 years, has like this incredibly positive reception.
People still love it's still wonderful and all those things.
And so I think that story was much more around us being just a better partner, coming in and thinking of ourselves as advisors and being helpful and there to be, you know, integration first.
Like silly things like the instant you get there, everybody starts using Microsoft email accounts.
We don't start keeping our like it Yahoo.
We literally kept our Zimbra email accounts even through the Yahoo transition.
We kept, oh no, we're Zimbra.
We're not, you know, we had our own business.
I literally have business cards still from VMware where you turn them over and they're printed Zimbra on the back.
Like we printed our own business.
Like we just mentally were in this.
Like no, we're the startup still.
And you're like, no, that's not how it works.
When you get to a big company, you want to become that bigger brand.
You want to be part of their flywheel.
And similarly, we saw some other acquisitions happen into Microsoft where founders came in and sort of was like it was their first time getting acquired and similar apps in the collaboration space and they had a much tougher time.
And those apps weren't, you know, ended up getting shut down or merged into other pieces because they didn't do Integration Advisor first.
Right.
They leaned into this like, no, no, we're going to continue to keep our brand and our ethos, which I think initially sounds like the right thing, but it's just not the way to become successful inside these larger organizations.
And it's no longer your baby.
Right.
That's the thing.
But you have to be okay with that.
Right.
And you're.
Yes, you're there to be supporting a bigger baby, a bigger family.
And the best way to support that big family, if you want to continue that analogy, is to be supporting of like, what are the main revenue drivers there?
What are the main goals of that business?
And get aligned with that and use what you've learned as an infant to support that rather than saying, hey, this infant is the way that we're always going to be and we're going to hold to those, you know, kind of older way of thinking.
Yeah, I mean, there's a lot to unpack there.
Like, one of the things that we've had a lot of conversations about over the years is like, building systems.
Right.
And I know you're a massive, big fan of building systems and this whole idea of like, we ship every Friday, it sounds like a silly, like, rule almost.
But by virtue of doing that, you build system because you force cadence and that cadence, in order to deliver that cadence, so many other things need to fall into place.
So I think let's talk more about that because there are so many.
There's a lot more importance in that than just, oh, we ship on Friday.
It's a cascading impact.
Maybe let's unpack that a bit more because I think there's a lot of insights from this.
Having that steady cadence.
Right?
Yeah, I think you're right.
I think the high level thing is easy to say.
Yeah, it's super hard to do and definitely takes a bunch of adjustments.
Right?
Yeah.
You have to think about, like, what does that mean to ship every week?
Well, you need to break things down into like two or three day tasks so that you're like those all fit inside of a week.
And so if they don't, you know, you can't have like a two month rewrite.
You're like, well you can, but you need to break it into three day chunks and ship a couple of those every week and make progress kind of hidden in the way like so that you're not doing this big bang sort of like release.
The other thing it sort of says is that like, you know, incredibly highly, you know, competent senior engineers, like the lead engineers on the team that know exactly what they're doing, make a small change, they can ship.
You know, we would cut the builds at like 6pm Pacific, typically at 5:58, they could check in a change, right?
Because they knew like, hey, I'm confident this is the thing, I know all the ramifications and you know, the chance that they're wrong is low.
Junior developer that had a bunch of new code, similarly, with a small change would be more comfortable checking in on Monday, letting that sit on the dev branch, have a few, you know, a few more days to settle people to look at it, catch ramifications.
And then you would learn like, what's that mean?
If you would check that stuff in, you're like, oh man, we shouldn't make changes to core data or the database on the last day because you don't know if the migration is going to work.
Right.
And so we'd start to learn those things.
And so those systems kind of backed into that like how we planned in Jira, like how we built our sprints, like how we worked through that, the kind of things when they got into qa.
And so like I said, we would test on Friday, they would test all weekend, kind of 24 by 7 for, you know, or 3, 3 by 7, I guess, you know, or 3 by 24 for those, you know, three days.
And then Monday we would have a report when we get to the office at 6:00am, you know, 9:00am New York and they would start to look through the issues.
And if there was major things, you would always just pull it out.
Like you wouldn't try to like patch it.
You would just be like, no, no, there's something wrong here.
Like this change is just getting backed out and removed from the build and let's try again next week.
And so that system of like knowing the entire release, just, no, you wouldn't skip the release.
You would pull those.
Yeah, you would not release with that change.
And if it was a small change, you'd like, oh, there was a small Thing with a, like sometimes you'd catch like a label or a translation issue.
But again, we shipped Outlook, I mean when we did a complete, we probably shipped in like 15 languages.
With Outlook we shipped in like almost 90 or something crazy.
Like you can go look in the App Store.
It's a huge number.
And those translations.
So the string changes had to be in by Wednesday so you could get the translations by Thursday so you could check them on Friday.
So they would make the build, right.
And so all those systems skating know that if you're going to make a string change and so developers would do this, right?
Hey, I'm working on a new chunk of tech.
Oh, but there's going to be strings.
So even on Monday or Tuesday they would have to define the strings that they're going to use so that those could be in even though their code may not land until Thursday or Friday.
Right?
And there, yeah, a lot of little things that sort of come together when you have that.
The craziest one was Microsoft.
When we got there, it took them seven days to build and sign a release.
Oh shit.
They had a team that was like the Apple build signing team.
And we're like, okay, wait a minute.
Like the way we used to do it is like you'd check it out, the iOS developer would click Sign and it was like 17 seconds on their, you know, MacBook Pro to sign the build and they had the keys and Microsoft had like a lot of structure where it was like, no, it was signed on certain servers.
Those servers were in Puerto Rico.
There was like a lot of like, you know, restrictions around how we had to build it and it had to be, you know, as you can imagine, it's Microsoft.
So it's very tricky.
But I'm like at the end of the day somebody's clicking sign on that build and it's taking 17 seconds.
It was just like you had to submit this form and give it to this team.
And I was like, we need to go back to 17 seconds.
And so we did, we worked with that team.
It took a bit of pulling, a little bit of carrot, a lot of stick to say, no, we're going to do this and keep our seven day release process up because we can't have a seven days to sign the build if we're going to ship every Friday.
And what was cool is that we did make those changes and then that team ended up not having build signing anymore because now it's like you would just go to sign the build and we automated it by building a system where it's like, when we're done, each of the individual dev teams on those apps could say, sign the build.
And it would just get done in, you know, less than a minute.
Where the old days, it was this whole, like, manual process of people.
And I think a lot of that maps today's world of AI, that if you do put automation and AI in the case, that one individual can have much more power, but you have to trust and put the systems in place so that one individual can't make a bunch of mistakes.
Right.
Because now that you're saying, hey, there's no longer a gatekeeper for signing mobile builds, you're like, well, 25 people can now sign mobile builds because they're all like, on these individual app teams, how do you put the right systems in place to make sure that's correct?
And how do you build that in code so that even if a new person comes in or if they, you know, make a mistake, it catches the mistake automatically versus that mistake going out?
Because now it's a automated system.
But with those, like that signing process, I presume that was done in a CI CD pipeline, not like literally on somebody's desktop, right?
Yeah.
So at Microsoft it was, right, it was done in a CI, but it was not a fully automated CI cd.
Like, so that was the thing.
It was.
It was like, oh, you had to file a request and they would go into the form because if you can remember, the way to sign an Apple build was still, it wasn't like you couldn't.
There wasn't like build bots and things like that.
Like, you had to go into the Apple Portal and do stuff and pull down the certificates.
There was a lot of manual things that had to happen.
And so you would literally sign them on a laptop, you know, in the of like, pull it down and signed it.
But we automated all and scripted it.
And some of that was tricky to script.
Now, of course, that seems silly because you can just go to GitHub Actions or something simple and there's a hundred different ways to like fully automate it, the full process.
And so.
But I think that still holds true today, where you're like, well, I have to send this Gmail thing, or I want to make this post, or I want to do this thing where it requires a human or edit this podcast.
Well, how do you do that?
Well, there's no script to go edit podcast.
It's all tools and things on your desktop.
But if you wanted to fully automate it with AI building the AI agent, it would have to have some sort of human, like sort of interface or web browser sort of app level interface to make that work.
And so I think there's a lot of parallels today to the systems that trying to make something fully automatic from a system point of view needs you to think a little differently.
Right?
Because you can't just like, use the tools the way you're using it if you're sitting at the computer with a keyboard and a mouse and looking at the screen.
No, I think there are so much system thinking that goes into this.
Right?
Like doing it properly.
Like, you just.
I mean, there are companies out there that still not using like CI cd.
Like I've had people on the podcast, like, particularly in the IoT space, like people, like, they're still building like firmware on somebody's like dusty computer under their desk and like, oh, yeah, that I'm not sure you saw.
Like, I just read before we hopped on like Sam, I think it was Samsung, one of the sound bars was not Sonos One, but somebody.
They've shipped the faulty update and like brick the entire fleet of devices.
And it's just like, how is this happening?
Right?
So like these processes and like having those safeguards, which is why having that cadence of like, no, we ship every Friday really forces you to have trust in the system.
And I think that is the biggest, at least for me, that's the biggest takeaway of that.
Right?
Yeah.
And also that the system itself should be code.
Right?
It's this whole notion of like, terraform and like, you know, infrastructure as a service.
And how do you define your AWS environment?
Like, that should not be like, oh, it's just set up because we set it up the way we did.
It's like, no, there's code that you can go to a blank AWS account and generate your entire setup in your environment.
And again, that's hard.
It's easier now with more tools, but you have to put the work in to do that.
Where it's probably easier to just spin up an EC2 thing or a lambda instance and just upload your code just in the UI because it's faster.
But if you let that baggage pile up and you haven't like, clean slate, fully automated, someday something's going to fail or you need to recreate that environment and then you don't have it in code because it's not been defined.
And so I think, to me, I always look at all these systems and processes of like, well, if you Replace the human.
If you replace the computer, could you still run it completely end to end?
It's not tied to like Victor's login or Kevin's login because a lot of that happens.
We've let people go at companies and it was the individual build engineers or developers keys.
And so when the Cloudflare is exact is a huge for this.
Like we have a Cloudflare key and if you disable that account in Cloudflare their API keys are gone.
So you're like, you don't have.
So like.
And then you're like oh I can't recreate it.
And then you're like well where were those keys stored?
Oh, they're in some, you know, check in system or some script and then that you're, you know, the world breaks for some version.
Yeah, they're in, yeah, they're in a GitHub action workflow secret somewhere that we can't even read back and figure out which one it is.
Right?
Yeah, 100%.
And, and I mean, yeah, there's, yeah, it's really interesting to think about these things and when you were joined, well joining Microsoft, like I guess you built a team inside of Microsoft too to kind of take over where and scale what you guys were doing.
Talk to me about that experience of like going from startup to like big co and building like an engineering team in those environment because obviously they are very different from like almost every perspective.
Right.
How what have you learned like building a scale engineering both outside and inside a big company.
Yeah.
So I mean when you're going and hiring your first engineer, second engineer, like when we, you know, I mean it was like mobile was hard to hire when were building a complex.
Right.
So I'd, you know, I'd phone, screen, a hundred iOS engineers to hire one.
Right.
And you know, we had a team of really top level people going in.
It was like a team of 10 people, right that had built a complete roughly and then there was like a couple business person, a marketing person.
It was like a really small team.
And then you show up there and the team that had been working on what was at the time mail 10 for you know, kind of Windows 10, mail 10, universal mail they called it had been building it with the idea that they would cross compile that into like from Windows to Mac to iOS to Android.
And that was the idea and which is why like they had not shipped mobile apps and why you know, accompli became an acquisition and why they paid for it is because they needed a working mobile app and they didn't have one.
Yeah.
To ship.
And so there was like three or four hundred people on that team or some.
It was a much bigger team now.
There was like they were doing lots of other things.
It was a lot more complex.
And so, you know, accompli being a team of 10 was small, right?
And Outlook Mobile started to grow in a bunch of ways, right?
We had a small team india, in Pune, and then we had a team in San Francisco, but then we acquired Sunrise Calendar and those kind of joined our ranks.
And they were in New York and they also had some people in San Francisco.
And then.
And then we just started hiring and bringing teams from other.
The team in Mountain View was working on Outlook for the Mac and that was a completely different architecture, completely different thing that didn't match the Windows one.
It didn't match our stuff.
And that was a big project to kind of move that today.
A lot more of that code's unified across like Windows 10.
Like they actually had written their own database, right?
So like at Microsoft, like, it's not just like they don't use like the database that's built in, they actually have their own because it's so highly specialized for mobile, for email, which is crazy, right?
Because it designs the number of iops and down.
And like it's crazy level that they go to it.
But that database now runs inside of Outlook Mobile ON Android and iOS and that was a big project.
So it took, you know, tens or hundreds of engineers to kind of put together.
So as these teams started to scale, some was through organic growth where it was just like, hey, Kevin, can you reorg?
We're going to move the Mac team into your group.
Hey, can we move this team in?
Hey, there's a team that's working on this other thing that's kind of related to Outlook.
Can we move them in?
Oh, we're going to start a team in Sujo because big stuff, big companies are crazy, man.
So you hire people, right, like me and you hire, you know, off a job or from our network.
But at Microsoft, they're just like, hey, there's a big tax break in this town called Suzhou, which is a couple hours out of Shanghai.
We're building a building there and we're going to hire 2,000 engineers.
And then they're like, who wants engineers in Suzhou?
And so I'm like, well, okay, well I'll take 10.
And so you're like, and so then I take some budget out of my, like, you know, hiring budget that's, you know, for Rex in the US So I close some US Rex or I close some India Rex or whatever.
And then I say I'm going to take 10.
And then you.
They're like, okay, here's five.
They're just out of the new.
Because they're coming from new college grads.
They're like fresh out of college.
And then you're like, okay, well now I need a manager.
And you don't want the manager to be fresh out of college, so you start interviewing.
So like the hiring, the key hire was like hiring the manager for the team in suo.
So I spent all my effort on that, hiring that leader.
And then from that leader, we added the other five to kind of get to the full 10 team.
And then I would make trips over there to go visit.
And that team, you know, was like, really successful and working really good.
So we're like, great, let's scale it to 20.
And so you just, you know, the next class comes in and you get two more groups of five.
And you know, and then similar, like Microsoft's like, well, we don't hire in Pune, but we have a team in Bangalore, Hyderabad.
Let's go add 10 people there.
And so we started a team there, you know, and so you, and then you're like, what do you want them to work on?
And you're like, okay, well, there's this big project and you're going to assign a big chunk of that.
And then, you know, same thing with interns.
You're like, how many interns do you want this year?
And we're like, I don't know, we'll take 14.
And then you kind of negotiate or 12 or whatever it is, and you have to find 12 buddies for them and pair them up.
And so the scale that Microsoft does things and a big company does things is very different than the way that you hire at startups.
And so you get kind of.
Or they're like, hey, we're doing this REORG and there's 15 people that we don't have like budget for.
We're gonna, they were working on SharePoint, they're gonna get assigned to your Outlook team.
And you're like, okay, are they front end people, back end people?
You know, what do they do?
And what's crazy is like, they've made it through the Microsoft hiring process.
They've worked in Microsoft for a while, so they know a lot of the systems and they're very smart, right?
Like, they've passed this bar.
And you see this at Google, Facebook.
A lot of these companies are like, they can.
They can learn very quickly.
They know the system.
And then it's like, partly a culture thing of like, hey, man, are you excited to be here?
You know, they're like, no, man, I really like SharePoint.
I don't want to work on Outlook.
You're like, okay, well, maybe you should go kind of, you know, be a free agent and go find another job in the company.
And so a lot of it's like this kind of human resources of just talking to people.
And they're like.
They're like, oh, I'm super stoked about that.
And then the guy was like, oh, you know, woman came from, like, I remember this.
They came from the editor team on Word.
And I was like, they were like, you know, super dialed in.
We're like, you know, if you think about it, like, if you look at Office, right, there's like 15 things on the toolbar.
Like, they'll have a team of 10 people working on the print button.
But they're like, crazy.
Like, they know all the drivers and all the details around print and stuff.
And so we had this woman and this guy that came from the Word editor team, and they're like, great.
Well, you guys know all about, like, dealing with super complex layout.
Can you work on our Outlook Composer?
And they're like, yeah.
And so the Outlook Composer got crazy good because we had this, like, person that had, you know, that had worked on editing in Word, right?
Yeah.
And so you.
So you end up with these weird sort of acquisitions of people and how you find talent.
And then you're like, I need a really good person.
That's incredible at, like, debugging memory leaks on Mac.
And so you go and hunt for other teams and you'll make a post or you.
And a lot of it's through, you know, same way we hire on LinkedIn, but inside of a big company.
You're like, asking your friends or other managers, hey, do you know anybod?
Somebody who's good at debugging on Mac?
And they're like, oh, yeah, we have somebody.
Or whatever, right?
And so, yeah.
But a lot of it becomes this hodgepodge of how you got people, some from acquisition, some from internal teams, some from off the street, a lot of college grads.
And then it's like, how do you build the culture?
So you spend a lot of time, I think.
I mean, I had hundreds of engineers on my team, you know, across all these different offices.
So twice A year I would do this like 17 day trip where I would leave San Francisco and I did it both ways.
So I would go San Francisco, Seattle, New York to India, India to China back to San Francisco.
And then sometimes I'd go the other way.
I'd go San Francisco to China to India, India to New York, you know, Seattle to San Francisco and would visit all the offices, right?
And like I did this kind of every six months to kind of connect with people, figure out what's going on, learn about problems.
And sometimes you'd show up and the problems were silly, like you'd show up.
I remember I showed up india and they had changed the milk vendor and the kind of milk that they were bringing in the office was like super bad and the quality was crappy, but it was like the Microsoft approved milk vendor for that city.
And so they, you know, somebody in some random office had made the decision that we're switching milk vendors to save dollars or just unify.
And we had fired the guy that we'd been using forever.
And so I'm like, okay.
So I had to go and figure out like, okay, how much is this?
Oh, it's like a thousand dollars a quarter.
It was like super cheap, right?
And I'm like, okay, can we just pay that out of our discretionary budget and not out of the milk budget?
And we're just not going to use their vendor, we're going to use ours and they're go get approval and.
But that was a big thing because they were like, hey man, the milk in our cereal sucks.
Like we eat breakfast in the office.
That's a big thing.
We do it together.
And sometimes the problems you're solving are not technical at all.
They're very much like logistical and humans and cultural.
Or you'd be, you know, a lot of stuff in big companies around promo, leveling, titling, you know, hey, how do I get to the next level?
And so I became really, you know, you understand what the rubric is, but how do you coach people to understand?
Like, well, what are you good at?
Why are you not progressing?
Are you not collaborating enough?
Are you not working on hard enough projects?
Because some people would be like, well, I want to be a senior or principal or whatever.
And they're like, all they're doing is doing really like simple tasks.
They're not working on team stuff, they're not project leading anything.
They're, you know, they're only fixing bugs in their area.
They're not helping other teams.
Like there's just all these kind of like attributes of making a great engineer at a big company that they were missing.
And so you'd have to kind of help them identify that, help them build a plan to work on it and then just kind of coach them.
Right.
And then sometimes it would just be speeches, like I would just go to other teams and talk about how we're doing things and tell stories like I'm telling now about accompli and stuff like that.
And so all that sort of leaned into like, you know, running a big team at Microsoft was just very different than, you know, a startup.
But you also, I mean, it's almost like you're running a remote company because you don't have like 50 people in the same building or 100 people in the same building like that.
Or you do, but you have it like five times, right?
You have 100 people five times, right?
Yeah, right.
But it's like you almost have the same problems as you do with remote, which, like silo, like almost like problems of silos.
Right.
How do you like.
And it must be almost more difficult in an environment like that because you don't have like a documentation first culture like you would have in remote work.
Like.
Like there is no that.
You don't have that shared knowledge base.
Right.
Like, what is the experience with that?
Like, how did you solve, like, more than just obviously, oh, let's fly Kevin around the world three times a year.
Like, how do you solve like the silo and like the gaps around that?
Right, yeah.
So a lot of its systems and so I think one was kind of Org design.
And so you didn't want like, you know, two engineers in India working with two engineers in Suzhou in China and then two engineers in Seattle and one engineer in San Francisco, like on a as like the project team.
Like, you know, because it's just tough to collaborate, right?
Where you.
So you would try to assign like big chunks of projects to given offices.
Hey, we're going to go do, you know, a bunch of things around?
Or like you would have module ownership.
Like the Calendar was owned by the team in New York.
Right.
And so they would work on Calendar.
So all the people working on calendar on iOS, Android, you know, and Mac could be in New York as a simple example.
Or all of the, like, bug fixes from Support would come through Sujo.
So that way the support team only had to interview interface with the support team.
So you would solve some things with Org design and sort of project assignment.
And then some of it was Trying to integrate the same systems.
And so it's like, hey, each of these teams had different sprints.
We were all shipping weekly, but we all should be using the same tools and making sure we're thinking about it the same way and using the same tools.
You're, again, you're unifying it through the process of people working this in the same way.
And that created this culture of like unity.
And then you would travel, right?
That was a big thing.
You would have people from the China office visit India visit us and all, you know, you would pick a couple people, like not just me going there, but it would have the reverse happen where two or three people from a core team and we'd try to align these around big design sprints, big roadmapping sprints, other events at the company to kind of make that connection, to make those sort of interfaces a little more human.
And to your right, this was pre Covid, right.
So weren't, we didn't have like, we obviously had video conferencing and all that kind of stuff.
And we would do that because these offices were remote.
But it wasn't like now where it's like, you know, almost default every, you know, meeting has a video conference or somebody's not in the office like in most companies.
And so I think that was a big thing.
But it was sort of a mix of like project assignment, good strong systems and unification of how things worked.
But then also understanding that there's got to be some cross pollination between the teams to sort of like work on stuff together.
So a lot of time I would imagine you spent on like writing sops essentially.
Like, how do we do things?
Right?
Yeah, I mean, you.
I spent a lot of time doing PowerPoints and I tried to stay away from it.
I tried to do.
I'm way more of a verbal communicator than a, you know, build a amazing PowerPoint to talk through.
You know, how I thought about it.
But a lot of times, you know, I remember you'd get to these offices and you just.
My calendar with my admin would have me stacked with one ones.
I'd be doing like 20 minute one ones with like the team, the leaders.
And I would try to do it like an order where you'd meet with the leaders, understand what they're hearing, then meet with a bunch of the sort of team and then you'd follow up and have dinner or meet with the leaders again at the evening or the next morning to recap what you heard.
And hey, how can we Work on this.
Are these themes that we're seeing, Is this what you're seeing?
Kind of a skip level type of implementation?
But yeah, it was when you're running teams that are in the hundreds, it's way more of a human resources HR type of job than it is like solving technology problems.
Like you do get into some things, but most of it when you're running large teams like that are very much human resource, sort of like culture, direction, vision.
But I think, you know, it also allows the technical leaders to sort of like, you know, kind of have their own sort of direction or drive without having, you know, sort of the managers tell them what to write or something like that.
Yeah, no, I hear you.
I have more about that.
But I want to jump into one thing that you mentioned that I am curious about, which is you mentioned that Microsoft brought their own database for searching emails.
Why is, because this is something I've read to myself a lot on.
Why is email search so fundamentally broken in every system?
Like you can never find emails, like maybe Gmail is all right these days, but like for the last 20 years, like email search has been so fundamentally broken.
Why is that?
Yeah, it's a good question.
And to be clear, like the databases that they wrote were designed to reduce iops and so actual number of writes to disk.
And so it was a structure of how it was core.
And here's the problem, right, Is the way that email was designed and the way it was used and the volume of email is very different today than it was back then, right?
Yeah.
And so if you think of the early days of Outlook and anybody who used Outlook 10, 15 years ago was it was all about folders.
And so you would create a bunch of folders and you would drag stuff into folders and that was your sorting mechanism.
Gmail came up with this idea that there's no folders, it's just labels and folders or this virtual overlay.
And so two different like approaches to email.
And so that's one is like how do people organize and sort of like tag their email?
Whether it's physically moving them into folders or virtually tagging them.
And then, but the next thing is like there's search and when you're searching it's like there's different intents for that search.
Are you looking for a keyword, are you looking for a person's name?
Are you looking for some combination and then what date, relevance, right.
And so there's these kind of like, is it, you know, you're Looking for an email seven years ago.
So I always had this test that Gmail is different in quotes is the first email you get when you start a Gmail account.
You know, and so I would always test when I would, you know, sign up to a new email service.
It's like, oh, we built this great email client for Gmail.
So the first thing I would do is search for Gmail is different in quotes.
And can it actually find the original email from my email box?
It's now 20 years old.
And almost all of them fail that test in the early days.
Right, right.
Accompli didn't because we used a combination of device search and server search to make that possible.
Right.
So there's some technical jargon in there, but to answer your specific question, and it was funny, it was the one thing that Bill Gates on me on is that when you do autocomplete and I type in like Victor, if I type in the letter V, what should show up, right?
Should it be like Victor?
Should it be like Victoria?
And so there's this notion of the ex girlfriend or kind of like your last, you know, sort of, you know, old partner type of problem where if you've been.
And maybe the girlfriend's not a good one because you don't email your girlfriend.
Maybe I did because I was an email.
But.
But if you think of the idea of like business partner and you're emailing the same person day after day, they're very recent and they're very highly, you know, sort of like relevant in your, you know, every time you type J, it's my partner JJ Right?
But let's say I need, I get a new business partner, I start working with a new company.
It's a guy named Jason.
Like, when does Jason show up above jj?
And so it's this notion like frequency and recency, right?
Came up with this thing where we just built an algorithm that said how many times have you emailed that person?
How many times have you replied to their email and how many times have you viewed their email over the last like three months?
And then you give more credit to the thing in the last month.
And when we demoed it to Bill Gates and I, you know, told him like, this is how we build it.
He's like, that's the stupidest fucking thing.
And that's his famous quote of like, that's not the right way to do it.
And I was like, well bro, like when you type Javier, which is my co founder or jj, those two came up first Right.
And I was like, you do this in Outlook and you get the First J like J1 Automotive or some shitty contact that you forgot about, right?
And I was like bro, but it works, right?
And he was just kind of annoyed that it was like not like the computer science perfect answer to like why that way it wasn't doing ranking, it was literally like a rules based system of frequency.
And it was just funny because I was like my first kind of like, you know, it was like a product review I guess were demoing it.
So it was like a product, it was something that existed.
I'm like, yeah, we should switch Outlook.
And of course if you look at Outlook today, it uses a version of that, probably smarter but you know, some version of that to fix it.
And so yeah, so I think the answer with search is this combination of like a, it's hard but it's also hard to know what people mean.
And people search for different things.
And you watch people use email, they use it very differently.
Some people look search for, you know, subjects, some people search for content, some people search inside of attachments which is also like, then you have to index them.
And so it's a lot of data.
And so the old days computers and phones for sure didn't have the capability to do that locally.
And so server search became the big thing.
And then it's like, well servers are slow.
So if I'm on my phone and I have a crappy connection, you know, you're not, you're going to do some device search and then you have to like at what point do you switch to server search?
And so again probably overly nerding out, but this is the nerding out with Victor.
And so yeah, the answer is it depends.
But yeah, because even today I think like Apple Mail is still like shit when it comes to search.
Like so Apple Mail only uses device search, right?
They don't use client, they don't have a server, right, because they're just a client.
So the Apple Mail search will always be somewhat, you know, restricted because they're doing it locally on the client where both Gmail and now Outlook do it with the server.
So they have like, you know, much more computing power.
They have a full like text index of all your mail and a bunch of intelligence of how you've used it and so that the quality of it's a little better.
I will tell you one thing with email which is interesting.
People always ask me like what email client, why do you use this?
And the Best email client typically is the one that comes with the email that you're using.
So if you're using aol, the best client for AOL is the AOL email client if you're using.
But okay, the best client for Exchange is Outlook because everything else is going to by definition have bugs.
Everything else is going to have some developer that's not the same developer that owns the client in the server.
And so yeah, typically you're going to run into issues even if you don't see them ahead of time.
Oh, when were doing Yippee Move, we saw, I mean the RFC for imap.
It.
It's an rfc, it's there the people who actually abide by it.
Not that many.
Yeah, a lot of loose.
Yeah, the nice thing that, you know, Yippee Move had to handle a lot.
I think these days you really, if you're building an email client, you really only have to do Gmail and Office or you know, Microsoft Exchange or Office365.
And back when we did it with Accompli, Gmail was pretty easy.
A lot of people had built for Gmail because it was like very modern APIs and very server driven and they had, you know, built a web client so they didn't have a native client where Outlook.
A lot of the logic lived in Outlook, the fat, you know, PC client.
It was a desktop client and Exchange did not have servers and they had very different versions of it installed on prem.
Today almost everybody uses cloud email and because of the accompli acquisition, the mail APIs got a lot richer.
And so now like to build, you know, you can thank Accompli for bringing in great APIs into the Office 365 exchange.
And so now people building email and calendaring apps can pretty much build them for Microsoft and for Google without a lot of work.
And most people just don't use other stuff.
Yeah, crazy side story about email, the very first prototype of EBU was actually a wraparound mutt, the email client where we literally like use PXPEC to like copy things between email boxes over imap.
Wild drag and drop.
You're like, yeah, you connect to, yeah, connect to IMAP accounts and basically, you know, shift.
That was basically it.
Yeah, that was basically it.
So it worked like talk about approved concept and blast for the past.
I like it, I like it.
All right, so we want to move forward now towards Instacart because that was, I mean that's.
I mean I hate to use the word but like blitzscaling right.
In terms of, like, building a team.
Like, you came in pre Covid, which I guess, obviously without knowing that Covid was about to hit.
I mean, how A, did you identify that opportunity and B, like, once you actually got on board, like, how the hell do you scale the company without, like, killing it in the process?
To the size that had to scale.
Yeah, there was kind of two things there, I think.
So how do we find it?
And were working on.
I left Microsoft kind of thinking about the new thing, working on something new, and got connected through a few friends and into a Porva, the CEO and ended up saying, like.
Like, I don't like to meet recruiters, but I'm happy to meet with the CEO.
You know, kind of this, like, slightly cocky approach to it.
But they finally said, yeah, Porville meet with you.
And I was like, oh, well, crap.
Like, I've used Instacart, like, for seven years they've come to my house and delivered groceries, and I've always been enamored with the other side.
So I'm like, I'm going to sign up for a shopper.
So I signed up to be a shopper.
And for the next seven days, on two different accounts, I just shopped every day, learning the app and trying it and delivering to all these people all over Silicon Valley.
And so I knew a lot about it.
So we got in the office, he's like, oh, tell me about Outlook.
You'd worked on mobile, and they were struggling with some of the mobile stuff at the time.
And I was like, man, let's talk about the Shopper app.
And the Shopper app was actually a test flight, kind of like an enterprise app.
So it didn't come through test flight, but it came through the enterprise build, which was not like a consumer app.
And so there's a bunch of, like, challenges getting it and setting it up.
And so that conversation led to, you know, us joining Instacart and initially was asked to work on fulfillment and kind of Shopper and the Shopper app and things like that, and started with that.
And, you know, hiring initially was tough.
It was because, like, I had a network and so were able to bring people from the network.
I think that helped.
And then once you kind of go through your first level of connections and like, the people that were great, you start, you know, doing the classic recruiter and LinkedIn and, you know, selling people on why they want to join.
The world changed when Covid hit, right?
Because I think two things happened.
I think, one, the world froze for A minute.
But Instacart's demand went to unlimited.
Like, literally unlimited.
Like we just you everybody want was afraid to leave their house, like for those first few weeks.
And so if you think of that, where most companies shut down, Instacart had unlimited demand.
And so we didn't have time, so we didn't have any recruiting because were like, we're so.
We don't have time to recruit to interview people.
We're so busy keeping the systems alive and working.
But we did have to hire a lot of shoppers.
And at the time we had just got the app into the app store and kind of had this couch to cash thing that we had worked on where it's like, how quickly can you get onboarded as a shopper, use an Apple Pay or Android Pay to load the credit card that you had to buy the groceries onto your phone, do the background checks, all in parallels, you're going to the store.
Like a bunch of optimizations that are pretty cool.
And so we bring all these people in and we're literally hiring shoppers at this crazy rate, right?
And what's wild is that the shoppers were coming from all kinds of different, like longshoremen, like people that were traditionally, you would never think as an Instacart shopper because this was the only job, like where, you know, you're still hiring.
When so many restaurants and food service and entertainment and just, you know, most sort of jobs of this caliber shut down.
Instacart was like, no, you could open the app and same day be able to start working.
Right?
And so we had this crazy shopper push.
We hired, you know, millions and just tons and tons of people right during this peak.
And then come out of that, you're like, okay, you finally the world starts to open a little bit and be a little normal.
You're like, oh crap.
We, the business is much bigger.
Our engineering team is deeply understaffed.
And at that point the hiring shifted to like hiring a lot of people from like the Uber, the Facebook, Google, those kind of like traditional fan stuff in the Valley because a, we had remoted become a thing.
But also you were looking for experienced people that could jump in right away.
Right?
Right.
And so again, you know, sort of a factory of like, how do we hire, how do we optimize and how do we hire the best people?
Very quickly we had a lot more opportunity because the world had changed and Instacart had gotten so much bigger.
And the brand was known because most people have heard of or Tried Instacart, at least in North America during that time.
Right.
And then like, how, like, I would imagine the back end and the infra was held together by duct tape at this point in time, I'd imagine.
Right.
So like, how do you go from that to putting systems in place to like, okay, now let's actually build something.
Or like, what was the state when you joined?
Like, was like, what was it?
Like, this is pretty good.
Or like, oh, this is kind of an MVP level.
Like it kind of works, but not really.
Like, where.
Where would you start out?
Yeah, I think it's a good question.
So it was Ruby on Rails, mostly on postgres databases.
And so it worked well, but it was like mono repo kind of style.
Wasn't microservices.
So we moved some of the stuff to microservices.
I think on the consumer side, it was a much trickier transition because of the, you know, website integrated with the code in the back end.
On the fulfillment side, we had a lot more async stuff because a lot of the planning, we had the mobile app, a lot of the, like, traffic.
There was no website really, other than for hiring.
On the shopper side, it was the mobile app.
And the mobile app obviously gave us some ability to offload that load because a lot of the calculations and things happened on the phone and then a lot of the systems for like, planning and deliveries and things like that were a little more async, although strained.
But the thing that I got into this loop and probably infamous for during the COVID points was just literally screaming in the phone to my partners and team is like, keep the front door open.
How do we take orders and how do we deliver more orders today than we did yesterday?
And that what kept us from delivering more orders.
And it was, some days it was tech, some days that we, you know, the front page of the website went down.
So weren't able to take orders, which if we can't take them, we can't deliver them.
And then on the delivery side, we did all kinds of creative things of like, how do we increase the batches so the shoppers can shop for five customers and not just two or three?
How do we enable, you know, driving distance and rings and how do we open earlier?
So we would, went and negotiated with retailers.
We would actually have people coming in the back doors of Costco and they had to wear orange vests.
They didn't get hit by the forklifts because getting more people into the store, more shoppers into the store earlier allowed us to shop more orders.
Right.
Just physically hours of checkout and then other things around, like delivery planning and like, you know, hey, how do we make this thing?
Or there were certain stores where were tracking if the store was limiting the number of people to go in the store because there was lines.
And like Covid, we would stop sending shoppers to that store.
We would close orders at that store and be like, look, if I can't get into this organic grocer because they're being very aggressive about like not letting more people in the store, I'm going to send more orders to Safeway and just shut down that store and take.
Because again, the goal was how do we get more people, more food in the day that we had?
And so the scaling there was, you know, a lot more.
Honestly, there was tech involved for sure.
But to me, I think the big win was being able to strategically think about what was the limiting factor and just hyper focus the team on that limiting factor that day to solve it so that the next day that block was not the blocker.
And sometimes the same thing would come back up.
Other times it was different things where, you know, oh, these databases are hot.
How do we move away from, you know, more aggressive functionality that's eating up CPU or databases and just move to the basic thing?
How do we remove, like the perfect solution for the, you know, go for the good solution.
So that again, the goal was max throughput of the most number of orders delivered over the time.
Most number of shoppers hired, you know, had multiple background check providers and different kinds of things to look for issues.
You know, literally just wherever it was in the system that were backed up, you know, sometimes it was like, oh, courts aren't open.
And so in certain geographic regions, the only way to get people that worked or lived in that region certified is they have to the courts open.
So we couldn't hire shoppers in certain places.
And so then we would just overhied in the neighboring neighborhoods and then, you know, in a.
In the different county.
Right.
And then let those people come in and shop in a different county because they'll drive an hour and a half to come find more orders.
Right.
So yeah, it was literally all kinds of different things.
Probably one of the most fun sort of like business sort of solution, kind of founder mode things that I've done in a long time.
Yeah.
And so it sounds like you were basically doing like a North Star kind of approach to this.
Right.
Like orders out.
Right.
But number of deliveries.
Yeah.
How many orders can we take?
More orders today than we did yesterday and just repeat that.
And I mean I was on the phone with the founders on the business team, whoever it took, I would just get on calls and be like, this is what I need.
I need this person to do that thing.
How do we go make that happen?
We need this.
You know, again, salespeople that are like business development people that work with our grocers.
How do we get like, here's these five stores have a problem.
We need to go figure out why they're backing up.
Why are orders taking so long to deliver?
What can we do?
And you know, orders got bigger.
So credit card limits were getting max.
I mean just all kinds of different things.
And it was like, okay, somebody needs to get on with this vendor and figure out how we pre fund this account with another million dollars.
Because the float between that was keeping us from getting credit cards approved.
Like whatever it took.
Right.
Yeah.
Was looking for those solutions.
Yeah.
Because this is such a multidimensional problem.
Right.
This is not like your typical, like let's scale our backend to support more.
It's a foresight marketplace, like super complex.
Yeah.
Right.
So that's, I mean, and also like route planning and all that stuff must have had like a huge like.
Because these are complicated problems.
Right.
And traffic, right.
Like where's, you know, where's their traffic?
Working cars get.
Are there roads closed because police have something set up?
Are there certain buildings you can't get into?
Right.
And so we could, we would not accept deliverers at certain places where we couldn't get people into the building to do deliveries.
Like, and you know, because if you think about it, if a shopper goes to a place they can't deliver and they're stuck, now that shopper is prevented from doing other orders because they're stuck trying to solve some problem.
And so how do you know, get ahead of that so that you keep those resources maximally utilized?
Yeah, it's super interesting problem.
Right?
Let's go into war stories because I'm curious.
I mean there must have been like quite a few occasions where you're like, holy shit, we just missed a dodged a bullet there.
Like almost everything went down like, or like.
Yeah, give me some of the meaty details of like that operation.
Yeah.
I mean man, there was just again, during that particular time, during COVID Yeah.
Things broke in the most unexpected ways.
You know, on the technology side, it was typically some kind of load related thing, you know, Systems breaking, you know, things that used to have to plan, you know, eight or 10 orders was now planning 80 or 100.
Things that used to plan 100 are now planning a thousand.
Right.
So like the ultimate sort of 10x or more scale and seeing that happen day over day.
You know, I think other things that we did were just, you know, like I remember seeing pictures from some of these stores where like people had shopped full batches and then the app crashed and so they would just send us a picture of like they had this huge order of groceries and they're stuck and they can't check out.
And now the whole backup, you know, you've backed up the store because you can't check out.
You know, I'm thinking of other like wild ones around the, you know, some of the shopper things.
Right.
You know, just being able to help people in support.
Right.
Where it's like people are calling support and how do we deal with the load and support and adding automations and it's time, you know, we didn't have AI so were like, you know, manually doing this.
I remember one thing, we turned off phone because like when you're on the phone you can only.
The support person can only talk to one person.
And so we pushed all of the.
Because the support was so backed up we couldn't answer support tickets.
And so I'm like, we gotta stop taking phone calls.
And this was a pretty like big like controversial thing to turn off the phones because if you push people to chat, at least the agents could chat with four or five people at the time.
And so we got like 4 or 5x productivity out of the same agents.
Right.
And so again these are things that you're like, oh man, that's crazy.
You can't make those kind of changes.
But we kind of had to because it was super controversial and lots of pushback.
And I'm sure there's still people that were displeased and didn't like the way that I did things or pushed in those times because I was pretty aggressive.
Yeah.
The other thing I know you spent quite a lot of cycles on that.
We've nerded out before about while to write the instacart is SEO because you do.
You were obsessed.
Well because of your past and we haven't even covered like you have a pretty obsession with SEO, right.
Like talk to me about like landing page optimization because that was something you did was spent a lot of energy on and resource on.
Right?
Yeah, yeah.
I think for us it was always like we had this, you know, 60,000 grocery stores in North America.
And again your point, I've worked on a lot of websites and to me, it's always like, there's nothing worse than going to a website and seeing it slow and then having like, bad SEO or bad, you know, like people find things through Google or whatever, search engine, or even now with chat gbt, like, you're still finding stuff through search.
It's just that they're running the search for you and still bub those links.
And so to me, that's always something that I look at and I get annoyed when I.
When like, web tech is shitty because I'm like, this is a solved problem and we just got to go figure it out.
And so, yeah, obsess over, like, getting lighthouse scores to 100.
And so we did a ton with like, optimizing a lot of the front pages when I was working on growth at Instacart for a minute around, you know, how do we make sure that those pages are really well done, that they're fast and arguably built a couple layers in front of it because, say, look like we can just make those landing pages really fast.
And then once you get into the big, like, sort of, you know, kind of the fatter JavaScript app where you're actually ordering, then you can of course have all the functionality and take the time to load.
But how do you do that intelligently?
And so I think that was always something that, you know, made a big difference by having those, you know, really fast, sort of easy to get to landing pages to capture users and help people get to the site and sort of see what we have and see what we offer and then from there be able to, you know, navigate into the bigger app.
And even today with like, other companies, like, I obsessively, probably to a fault, push on like web performance and SEO just because I think it's like, it's just table stakes, right?
You have to have it right.
And like, most of the things that we're doing have some digital or web footprint and not having a great website.
And even like my personal blog, like KevinX.com, i've always.
It's like, it's not the fanciest design.
It's way more optimized for how fast it is.
And I'm constantly like, trying to tune it to like, oh, it's not a hundred.
What, there's an image.
It's too big.
And yeah, I just think it's something that's important to actually have another company in this space that's working doing web performance for that exact thing, which is like helping companies, you know, just optimize their web stuff and their landing pages.
Because you know again and we've seen all the stats right, you know, X number of milliseconds slower, it reduces checkout in E commerce.
But it's also just a shitty way to like have a digital company and not have like a fast website.
And so I'm always looking for ways to make it faster.
Yeah, that makes a lot of sense.
The last thing I want to wrap up with is I think well another thing we've spoken about a lot over the last few years is taking all this know how from like building and scaling organizations into like kind of like micro pe, I want to call it like or like these, like you start seeing more bigger wave of these.
Like well there's obviously a big, much bigger marketplace for buying small SaaS companies.
You say it's like you got flippa and you have blank Aquatic.
Com and like quite a few of these other ones, right?
You've been fairly involved with like buying these smaller like I was a smaller but like buying these companies like and like tech first them.
Is that a good way of saying or like re overhauling like the processes I guess is maybe a better capturing of that.
Like what talk me to like what you seen your thesis and like what brought you into actually doing that in the first place?
Yeah, I mean I've always like dabbled in just different things.
Like I've enjoyed starting things and trying things and understanding how you know, SaaS works and business works and just different organizations and good and bad.
And so to me like this idea that you can acquire a company or pick up a SaaS thing and be like just run it better, right?
And be like hey, can you apply some of these things that we've learned and so have acquired a bunch of different things, have bought some E commerce companies, have bought some small SaaS companies and more so looking at ways of like hey can you know again have a team that helps operate those.
And so I have a team of folks that like does operations and shared services for like you know, finance and some of the recruiting stuff and engineering and approaches like that and even now more so with AI.
There's a really cool company called Rocketable.
I think I shared you the link at one point but yeah, you can put it in the show notes but it's crazy.
The thesis is crazy, right?
It's like hey, I'm gonna go Acquire companies.
And I'm just going to replace every role with AI, an AI agent.
And so I think the idea that becomes way more possible today because I think we've both used AI a lot in our businesses and some of the other companies we're building around AI voice and chatbots and things like that.
In my portfolio, like is the idea that I can give you 80, 90% authority or knowledge on any topic.
Like you can literally top in, you know, the old days was like you'd Google something and get an article or list.
Now you can go to deep search and have it like read a report and be like, hey, teach me everything about this.
And it literally can look that up on medical, legal, corporate, really isoteric, small like things.
The ability for then to go from like kind of quick rip to 80% to getting to 100% is a lot harder, right?
That last sort of 10, 20% a lot trickier.
But I think that's going to get easier and easier of more of these tools, both code and no code.
And SDK is an open source stuff and been looking at a lot of different tools in that space to sort of play with this.
And to me the idea that just taking digital businesses that are already like computer, website, keyboard, like there's no physical thing, it's all digital.
And being able to like kind of AI and automate and apply systems to that is like pretty easy.
I think where it's really exciting is going to businesses where there's still a lot of like labor and a lot of human.
And how do you sort of like use AI to help accelerate their businesses?
And for some of these businesses that are already growing quicker, where we're seeing the results is we're like going in and saying, hey, well if your business is growing 34, 30 or 40% a year and you're having to add 30 or 40% new staff, can we use AI to just make your current staff more efficient?
And so your margins actually increase.
You can still keep growing at 30, 40%, but maybe you're only having to add 10% people, right?
In digital businesses we see this all the time, right?
Really small teams can grow really big because it's all digital.
But when the business is like medical services, you know, health care and things of that nature, it's like, well, for every doctor you hire, you have to hire two nurses and three front desk people or operations people.
Can we somehow make it so that you're still hiring the doctors and the nurses that are providing patient services but can you sort of reduce the number of like back office and front office folks and using AI to make those people more efficient?
And so I think that's a lot of the opportunities we're seeing today.
I think the thing that, you know, personally we're spending most of the time on my own portfolio is just like I said, buying like more digital first companies and applying AI.
But I think in some of the businesses that, where we're helping, you know, kind of what I would call traditional companies with AI, it's much more the latter where it's like, hey, how do you use AI not necessarily to replace humans, but to augment those humans so that the humans can work on the higher value sort of critical thinking solutions, design and sort of, you know, patient interface or customer interface stuff where they need to like have like, you know, you want to talk to a human, you're not going to walk in and talk to a screen or a robot and let AI sort of solve a lot of those other pieces.
How, how much of like your, I mean, when you look at these companies, I would imagine many of these companies, their tech stack, I mean that's large what you buy.
Like you buy the tech stack, the software and like I guess the go to market, I guess in some sense.
Right.
But customer base, potentially.
Yeah, customer base, yeah, of course, Yeah.
I mean, what's the crazy thing you've seen so far?
Like what?
Like you're like, holy shit, this is just, I could, we can solve this in like 15 minutes and like we can turn this thing around.
Yeah.
I would say in some of the bigger companies that we've helped, I think it's around like things that are still done on paper.
You know, it's like anything when you're printing something that ends up getting scanned, you're like, why did you print it?
And how do we like, you know, so it's almost like things like a Docusign or, you know, or Dropbox Sign can solve.
So I think those are just.
There's still a lot of processes that are not digital.
So I think that's like one big, so low tech.
Like I wouldn't even think of that like as innovation because it's so rudimentary to our life.
Right.
And part of that is that if you think about it, the old model is that by keeping it on paper, it never got into a computer.
So there's no SaaS, there's no form, it's not even in a database.
But the thing with AI, it's like, well now you can take that form exactly the way it is, not even have to rewrite the form or change it.
And AI can extract the value out of it and put it in a database or do the next thing without even putting it in a database.
And so I think that piece of it is where like AI is allowing you to like digitize things that in the process you're like, oh, if we digitize this paper thing, all we'd end up with is a bunch of scans in a Dropbox folder.
Not really useful.
But now if you're like, no, we can process them, categorize them, use them, do the next stage in the process.
I think pretty cool.
I think the other one where we're seeing it is just call centers with some of the voice customers we're working with.
You know, how can you help?
Like the first version of like AI voice and like IVRs people hate like you get on any phone call, you're like agent.
You know, we've zero.
Zero agent.
Yeah, you just want to get rid of the computer to get to a human.
But now some of the stuff and we've rolled out, people prefer talking to the agent, which is crazy because they're deeply empathetic, they're incredibly persistent and patient and that you can literally ask them anything.
They have every answer that's, you know, that is known to the company.
And I think as those kind of voice solutions start to get into more customers, people start to trust them more and start to be actually be okay with that because they're actually providing a solution.
Just like today, you and I, if I know there's an app or a website, I typically will prefer to use that than call on the phone.
Right.
100.
Even if the phone might be faster if you got the right person, the chance of getting the right person is so low.
So now imagine a world where just like voice to text.
If I could call the number and it was as good as the best mobile site or web or mobile app, I would actually do it because it's faster for me to call.
I can be on a run, I can be out, you know, my car.
I'm not tied to like being at a computer or an app.
I literally can be hands free and talk to the thing and it does the right thing.
And so I think there's a lot of value and we've seen this with our early customers already, that they're getting a ton of like savings, but also like they're actually providing a better solution to their End customers.
I think the voice idea is very interesting because, I mean, I don't think voice technology has changed that much, at least not for processing.
Voice has changed that much in the last like five years.
But what has changed is processing that voice.
Right.
So now like you can just talk and it, with the fault tolerance is kind of consumed by the LLM and contextual.
It can like compensate for that.
Right.
And that is a huge shift, I think, and makes it so much more usable than it used to be.
Right?
Yeah.
We don't have real time voice to voice yet.
That's scalable.
There's a couple people working on it.
So it's still like voice to text to voice.
Kind of like is where a lot of the real time stuff happens.
And that's what we're deploying today.
But we're going to see voice to voice in the next year.
That's going to start to get good.
And then the question is like, can we build enough of the intelligence in there to really see that as something that people can deploy at scale?
Because right now the stuff that we're deploying at scale is working, but there's still a lot, there's a lot of pieces to the puzzle.
It's not just like a one click.
And the latency is just enough for you to notice that it's not real time.
Right.
Like the start.
Whereas like Spotify did a study of like, I think like 300 milliseconds, I think for it to be like noticeable.
Yeah.
And we're still closer to one second.
Slightly more.
Right.
Some version of that for a lot of calls.
Right.
So some calls you get down to, you know, 500 milliseconds, but a lot of them are closer to one.
One second.
Kevin, this has been super interesting.
We've cut a lot of grounds.
Very pleased that you came on the show.
So thanks so much for coming on.
Any last words before we wrap up?
Any shout out?
I'm excited.
Thank you so much for having me.
And this has been a fun conversation and as always, yeah, look forward to continue to chat with you and you know, watch you and sort of things you're working on.
Awesome.
Thanks, Kevin.
Have a good one.
Talk soon.
Take care.
See you, buddy.
Found an error or typo? File PR against this file or the transcript.