In 2011, I left Google to join a startup after five years of working as a software engineer (I’m back, btw). I had helped build some great things and collaborated with some wonderful people, but it was time for me to try something different. Having been employed by three different startups—ranging from six people to almost 1600—since leaving Google, I’ve had to heavily adjust my own approach to product and engineering.
Being more involved with the startup community, I’ve also noticed patterns amongst former Google engineers who have joined or founded a startup. Every story and person is different, of course, but if I saw it more than once it’s on this list. So sit back and get ready for some very broad generalizations.
This is what people who worked at Google should know when they start their own thing or join something small.
1) Your technology will not save you
A superior technical implementation will not guarantee your success. Conversely, even demonstrably inferior technical implementations running on demonstrably inferior infrastructure can go on to become billion-dollar companies with very impressive metrics. Your focus on user experience and product story should be equal with your engineering effort.
What was Wave’s product story? The closest thing that resonated with non-engineers when I was tasked with explaining it to wave after wave (yes, I know) of people at a Google for Business event I volunteered for was “uh… it’s like Gmail, but everything is mutable.” Was the lack of a good story the reason it was discontinued? ¯_(ツ)_/¯ I’m not certain but I’m pretty sure it impeded its growth.
2) User acquisition: It’s really hard™
Googlers have to worry about handling scale events because when something new is released, there is a very good chance that millions of people will flock to see the new Google product on the block. I have some good news and bad news: The bad news is that there’s no good news, and the other bad news is that millions of people will not flock to your product even if you get a nice write up in TechCrunch.
Building communities is a long, arduous process and requires things that normally can’t be done at the scale at which Google operates. Most Xooglers (ex-Googlers) don’t understand how to go about building one around a new company and product. There are so many resources to learn about building communities so I’ll leave it as an exercise for the reader. One major takeaway I want to emphasize is do not rely on some algorithm or outside agency as the primary mechanism of engaging with your customers. As a startup, you can leverage your initially small scale to create intensely passionate users by providing them with amazing, personalized customer service that simply cannot be matched by a larger company.
3) Big things have small beginnings
If you roll into Sand Hill Road with a potential solution to a problem that will take more than two dozen engineers and $20 million in funding to show progress on, the VC you’re pitching to will probably say something like “how can I help?” while dying a little bit inside…
You are not at Google anymore. You have extremely limited resources and limited runway, so find a way to get there incrementally. Want to replace phone carriers? Start with a product that solves the first problem of addressing a market where they don’t exist. Otherwise you’re asking to get married on the first date. Slow down, cowboy (or cowgirl).
4) Don’t be precious with your code
If your product takes off, it’s going to be rewritten anyway (multiple times). Step away from the 12-page design document you wrote for your new mobile photo-sharing app backend and spend that time getting your product validated and asking for feedback. Eat the cost of maybe not being able to handle a billion simultaneous users.
At a startup you do not have the luxury of time to be precious with your implementation.
And if you’re sitting there thinking about pushing back on a request from a potential customer who won’t sign a contract until you implement their pet feature that requires a hack, stop and realize that—like the free food you used to enjoy—you no longer have the Google perk of time to be precious with your implementation. If you need the customer, and you probably do, hack the feature together and close the contract.
5) Sometimes the dirty, hacky, or simple thing is the right thing
There is a propensity for Xooglers to lean towards complex solutions when the problem simply doesn’t warrant one. This is likely a cultural side-effect of Google’s problem domain. After all, there isn’t a simple solution to mapping the entire world or storing the Web in memory.
There are some problems out there that don’t require a CS Ph. D., or a solution that fits better as a candidate’s dissertation than a product implementation. A simple solution doesn’t necessarily mean a hacky or dirty one, but it may not be the engineering catnip you fed on during your prolific career implementing large-scale storage systems serving petabytes of data. Sometimes a good product is plugging existing components together, and that’s OK. Find what works for your customers and do anything to keep them.
At a startup you will be faced with decisions and timelines that will most likely require you to hack something together, eschewing your Googley training. You need to rewire that part of your brain that thinks of hacks as always a bad thing. If a customer is at risk of leaving, and the quick and kludgey solution is the way to save them, lose the propeller beanie hat and get ready to feel gross about what you’re about to do.
Startup is just another word for kludge. Welcome to #kludgelife. Nothing is going to be perfect, so be ready to exercise some pointed imperfection for the sake of success.
Andrew Bonventre is a product engineer based in New York City. He’s designed and built all sorts of neat stuff for Google, Stamped, Poptip, and Palantir. You can follow him on Twitter at @AndyBons.
A version of this story originally appeared on Medium and has been reprinted with permission.
Photo via Marcin Wichary/Flickr (CC BY 2.0) | Remix by Max Fleishman
