Indrajit Khare, Sr. Engineering Manager at Google

In Season 2, Episode 9 of Lead Time Chats, Jean Hsu, VP of Engineering at Range, chats with Indrajit Khare on what it's like to be at a startup acquired by Google.

Indrajit was a lead engineer at Bump when it was acquired by Google, where he led the engineering team that built Google Photos and scaled it from 0 to 1 billion users.

Indrajit and Jean discuss:

• Only having a day or two to prep for a standard Google engineering interview
• The multiple factors, including clear purpose and mission, that led to a successful acquisition and integration of the Bump team into Google
• Startup mindset of doing things that don’t scale, and what that looks like at a big company
• Inner workings of Google’s acquisition of Bump, integration of the team, internal dog-fooding of Google Photos v1, and public launch.
• The vast difference of launching a product as a startup vs at Google

Additional Resources

• Growing a consumer product from scratch to 1 billion users - check out this First Round interview with Bump CEO David Lieb for more inside details about the Bump acquisition to Google Photos journey, including how he was fired twice from the team for ruffling feathers - and how he was able to speak his mind because if he was fired, they'd have to accelerate his vesting.

Takeaways from Indrajit

Codebases at Google aren’t as pristine as you might imagine

“There's this picture people have in their minds about, oh, it's Google, all the engineering must be  perfect. And then you realize, actually, people are people. They have the same constraints between deadlines and the features that have to build and everything. And you're going to be living in a similar place where the code will be messy here and okay here, pretty good there. And you kind of have to navigate all of that. So that was definitely a surprise. It shouldn't have been, you know, in hindsight, but it was definitely a surprise.”

Sometimes you have to do things that don’t scale

“One of the startup mantras is do things that don't scale because you know, bigger organizations will always focus on scale. So in my case, I was the default assignee for all bugs coming into Google photos from the internal Google-wide dog food.  Google's pretty big, so that means a lot of people were dogfooding the product, and the engineers are also very opinionated. So these bugs that I was getting were, you know, quite detailed. But I read everything. I was the default assignee. I read everything. I knew exactly where the product was at, where the state of the code was, and where we were in respect to the quality I wanted us to be. And I thought that actually worked out quite well.”

Build in a way that you can launch anytime

“I did what you're kind of supposed to do... build sort of the onion style, right? Fill the middle of the core first and so on and so forth. So that at any point, if anyone sort of above me, was like, we just have to launch now, we wouldn't have all the bells and whistles and all the features we wanted, but we would be in a place where it was feature complete to what we had built so far.  So I made sure we were always doing that, so I always had an answer to, "Hey, when are we going to launch?" My answer, you know, being all flippant was like, "We can launch now if you want," we just won't have X, Y, Z... and we just won't have these features.”

Launching a new product at Google looks vastly different than at a small startup

“A month or so before launch, our lead TPM who sort of owned the play store process within Google... he came by and he was like, "dude, You're screwed." And I was like, "why, what do you, what do you mean?"

He's like, "you're going to have 20 million people the first day, this thing better be rock solid." I was like, oh. So that was definitely, you know, one of those things that... I was just so heads down working and my team was just working, I didn't quite internalize that day one, this thing needs to be rock solid.

As with most product, once you launch, you have to kind of iterate a lot. So we were definitely in the mode where as soon as things launched, I was just on top of the bugs. I was like, I want to know exactly what's happening. And so the first month we were just, we released a few dot releases to just clean things up because even with the massive Google dog food, the real world is different.”

Enjoy Lead Time Chats?

Please leave us a rating or review on iTunes! It'll help these chats get in front of more engineers and leaders like yourself.

Don't miss any episodes!

• Subscribe to the Lead Time Chats podcast on Apple, Spotify, or wherever you listen to podcasts, so you don’t miss any episodes.
• Join Lead Time Community, where we'll post new Season 2 episodes weekly. Lead Time Community is a place to connect, share, and grow with other engineering leaders.

About Lead Time Chats

Listen in on unscripted conversations between Jean Hsu, VP of Engineering at Range and engineering leadership coach, and engineering leaders and other influential folks in tech.

Lead Time Chats is brought to you by Range. Range helps hybrid teams check-in asynchronously about what matters most. Know what's happening through status updates that pull from tools like Github and JIRA without scheduling yet another meeting.

Checking-in with Range creates more focus time for heads-down work, all while feeling a deeper sense of connection and belonging with your team. To learn more about Range, you can check it out here.