Our 10 person startup gets acquired by Google, we rebuild our product the Google way, and begin to understand that amazing things are possible at Google, if you play the Google game. A follow up to What I learned at Venmo and What I learned at Socratic.
As we started to raise Socraticâs Series B in 2017, we quickly learned that our focus on getting usage at the expense of revenue was going to bite us. Our growth got us in the door, but every VC asked for a monetization plan, and in the process of figuring that out we concluded that an education app focused on credit-card-less high school students wasnât going to become a big business.
Around the same time, we were introduced to Evan Spiegel, the CEO of Snapchat. Evan suggested a partnership to integrate our camera-based homework helper into their app. But one of our advisors figured that if he introduced you to their Head of Corporate Development, he may be suggesting an eventual acquisition, and if so, we should get a competitive process going. So we did, and reached out to Microsoft, Chegg, Byjuâs, and Google.
My co-founder, Chris, had previously worked at Google and reconnected with his past manager to get an intro to Lens - Googleâs camera-first app. What we didnât know was that she had recently started an education effort of her own, along with the co-founders of Khan Academy and Android. We met and learned that we had hugely overlapping visions for a learning-focused, AI-powered tutor. Maybe it helped that we had just won Googleâs 'Best App' of 2017đ, but soon after that meeting, we kicked off a process that led to Google acquiring Socratic in March of 2018.
We merged with an existing team of the same size, composed of multiple long tenured Googlers. Chris and I became the product and engineering leads, tasked with building an AI-powered tutor and bringing those capabilities to Googleâs largest products.
Over the next three years, we rebuilt Socratic and relaunched it as âSocratic by Googleâ1, shipped Socratic features in Search and Lens, released a math solver and prototyped a step-by-step math tutor, and built capabilities that are being used across Google.
Some things I learned along the way:
Working at Google is like having a second passport. Go to any major city in the world and your badge2 unlocks a beautiful office with great food, desks, and a high speed link to every person in Googleâs 200,000+ person network. And like visiting America as a foreigner, everything you see inside feels oddly familiar because of its massive exported influence, yet is just slightly different.
Shockingly, you get immediate access to all of it. Access to their gigantic monorepođ with billions of lines of code covering almost all their products. Live statuses of their globe-covering data centers. Strategy documents spanning two decades of history. And direct access to legendsđ.
Google does things the Google way. Just about every piece of software and infrastructure used at Google was built at Google, a natural result of facing the hardest engineering problems earlier than most companies. At Google's scale, the external world ceases to exist and is only rarely and carefully allowed to enter their walls.
This meant that there was no chance of keeping our existing codebase. We would need to start from scratch, rediscovering our product insights with the new team, then rebuilding our app on Googleâs stack. Problems we had already solved, like our ML system to classify the topics in a homework problem, had to be re-solved using Search techniques and to Search standards, which needless to say were higher than ours.
One place we were able to break Google's mold was with âCeeboâ, our app mascot. Look at Googleâs collection of app icons and youâll see four colors and simple shapes. Works for them, but boring to us. They pushed (âwe donât anthropomorphizeâ), we pushed back (âyou do with Android!â), until we finally got our way because we were too small to matter. Ceebo lives on as our app icon, and has blossomed within Google, where dozens of variants have been illustrated, and Ceebo pops up in surprising docs and sites all around Google.
The usual Google app logos vs. Ceebo
Simple things done repeatedly feel magical. Re-building our query classification system alongside Search veterans was an illuminating peek into how Search itself was built. On the one hand thereâs the incredible depth of information retrieval tools, and the mind-boggling ability to calculate and add a new signal to every page on the Internet (e.g. contains_math, or subject:chemistry).
On the other hand there was the discovery that most Search improvements are manually reviewed by engineers through âside-by-sideâ comparisons between old and new results...on spreadsheets!
One may expect Google engineering to largely consist of implementing PhD level algorithms, and while that's sometimes true, much of a search or AI engineer's job involves looking at examples, spotting patterns, hand labelling data, and other non-scalable, in-the-weeds analysis. This seems to be generally true among the best AI teams:
"One pattern I noticed is that great AI researchers are willing to manually inspect lots of data. And more than that, they build infrastructure that allows them to manually inspect data quickly. Though not glamorous, manually examining data gives valuable intuitions about the problem."đ
Most problems arenât worth Googleâs time, but surprising ones are. Most 10-50 million user problems arenât worth Google's time, and donât fit their strategy. But theyâll take on significant effort on problems that do fit their nature, strategy, and someoneâs promotion goals.
One such example: computer vision is a big part of Socraticâs interface, specifically being able to read text and math in images. As a startup we used a 3rd party tool, but between exposing sensitive data, expectations of scale, and a complex vendor review process - using it within Google proved too difficult. Sometimes itâs easier to just buy the company to bring the tech in-house. Other times, as in our case, thereâs an AI research team thatâs interested in the problem, hires a top PhD talent to work on it, and delivers a world-class math recognition API within 6 months.
Of course, if youâve read Steve Yeggeâs classic blog postđ comparing Google and Amazon's platforms, youâll know that this world class service was not externalized.
Google is an ever shifting web of goals and efforts. Amazing things are possible at Google, if the right people care about them. A VP that gets it, a research team with a related charter, or compatibility with an orgâs goals. Navigating this mess of interests is half of a PMâs job. And then you need the blessing of approvers like privacy, trust and safety, and infra capacity. It takes dozens of conversations to know if an idea is viable, and hundreds more to make it a reality.
And thatâs the happy path. Amazing things are possible at Google, if the right people keep caring about them. Team goals can change in any given quarter, and entire teams can disappear in the face of a 'reorg', a phenomenon so common that Googlers can look past the tragedy and see the comedy in it.
Suppose you dodge all those bullets, you might still wake up to find that while you were working on your project, two distant teams were also working on the same idea, and the time has come to fight it out because only one can proceed. The internal users of the losing projects will find that the API they depended on is now âdeprecatedâ, but the replacement, well itâs not quite ready yet.
Googlers wanted to ship great work, but often couldnât. While there were undoubtedly people who came in for the food, worked 3 hours a day, and enjoyed their early retirements, all the people I met were earnest, hard-working, and wanted to do great work.
What beat them down were the gauntlet of reviews, the frequent re-orgs, the institutional scar tissue from past failures, and the complexity of doing even simple things on the world stage. Startups can afford to ignore many concerns, Googlers rarely can.
What also got in the way were the people themselves - all the smart people who could argue against anything but not for something, all the leaders who lacked the courage to speak the uncomfortable truth, and all the people that were hired without a clear project to work on, but must still be retained through promotion-worthy made-up work.
Top heavy orgs are hard to steer. Another blocker to progress that I saw up close was the imbalance of a top heavy team. A team with multiple successful co-founders and 10-20 year Google veterans might sound like a recipe for great things, but itâs also a recipe for gridlock.
This structure might work if there are multiple areas to explore, clear goals, and strong autonomy to pursue those paths. But if you want to work on one unified product, it needs a clear leader, with a clear direction, and more doers than thinkers. And counter-intuitively, adding more people to an early-stage project doesn't make it go faster.
Technical debt is real. So is process debt. Engineers are used to talking about technical debt: a corner that you cut today to save time and ship a feature; a loan from your future self that is either paid back in time or it slowly gets more expensive to deal with. Good teams regularly pay down debt by cleaning things up on quieter days.
Just as real is process debt. A review added because of a launch gone wrong. A new legal check to guard against possible litigation. A section added to a document template. Layers accumulate over the years until you end up unable to release a new feature for months after it's ready because it's stuck between reviews, with an unclear path out.
In some rare cases, process is rolled back: Google recently changed their onerous perf(ormance review) process, from twice a year to once, from a long to a short questionnaire, and hopefully from 30+% of a manager's year to less than 10%.
And sometimes an external threat either forces this change, or precipitates a company's decline. Google invented the technologies behind ChatGPT, but wasn't the one to release that product. Now it must resolve the growing tension between the builders that want to reclaim Google's AI lead, and the reviewers that want to guard against all possible troublesđ.
Amazing things are possible at Google, if you play the right game. Google used to have a set of internal values they called "The Three Respects": respect the user, respect each other, and respect the opportunity. The first two are somewhat easy to understand, but the third one confused most people. My interpretation is as follows: you're at Google, an insanely profitable, genius-filled enterprise. You're well-paid, well-fed, and live in the eternal spring paradise of Silicon Valley. What's the best thing you can do with this insane luck?
And my answer to that question echoes what Richard Hamming said in You and Your Researchđ: you must find the most important problem in your field, and play whatever games necessary to solve it.
Practically, what this means is to first do the work that is given to you. But once that's under control, to reach out into the vast Google network, to learn what's being planned and invented, to coalesce a clear image of the future, to give it shape through docs and demos, to find the leaders whose goals align with this image, and to sell the idea as persistently as you can.
To some extent I did this. One of my favorite examples was a demo for a step-by-step math tutor, built on top of our new math solver, made by three of us on the side over a few months. The demo gave our vision for intelligent tutoring a tangible form - it had a link, it could be used, it could be shared. It grounded conversations, gave people something specific to react to, and took on a life outside our team, being passed around, independently discussed, and leading back to us.
I also saw this go wrong. One of our leaders clearly saw the world we were heading towards, had designers make great demos, and would share them whenever he could. But he was trapped in the wrong part of the company, and his boss's goals pointed elsewhere. He eventually switched to a more compatible team, and his dream now has a chance of becoming a reality.
Many acquisitions fail. Socratic's story is mixed. On one hand, we managed to merge two vastly different cultures, our product lives on and has grown to serve ~5 billion queries a year, and careers across the Socratic team have bloomed.
On the other, both Chris and I left Google to found startups3, and neither the Socratic team nor Google as a whole have yet produced an AI powered tutor worthy of Google's capabilities. But a few Socratic Googlers might yet make it happen, unless they've been re-org'd.
Thanks to Avni, Shantanu, Rich, Harish and the entire 10x team for the opportunity, and to the Socratic team for being such great compatriots in this chapter.
14.9 stars with half a million ratings. Blows my mind. Socratic on the App Store
2Googleâs most visible class system is seen through their badges. White badges are for full time employees. Green badges are for interns. And red badges are for Temps, Vendors, and Contractors - TVCs - who do work ranging from the mundane to the critical, sit alongside the white badges, number over 100,000, but have limited benefits and access (a source of many issues) and often cannot publicly state that they worked at Google.
3Chris recently founded Granola, building AI powered workspaces, and I'm the co-founder and CTO of Maven, building the university of tomorrow. More here (we're hiring).
Lot of comments in this Hacker News thread.