5 ms·
Code and infrastructure must evolve, and Google excels at building secure, scalable, performant, maintainable systems that squeeze every last bit of signal fro
by danans 3y ago
Code and infrastructure must evolve, and Google excels at building secure, scalable, performant, maintainable systems that squeeze every last bit of signal from noise. Startups don't have the resources to do that, and Google can't launch a product built in the startup way.
For an example, anything/anyone that wants to access user data at Google faces an extremely high bar for access, with layers of access control, auditing, approvals, and enforcement, starting at the design phase through to implementation.
At Google that's a good thing. However it would be pretty silly at a 10 person startup.
What Google isn't great at is taking risks on new product ideas (for many good and bad reasons), and that's why they often acquire companies that do that sort of thing.
- nitwit005 3y agoBuying something, rewriting it, and abandoning it, is just squandering money. You can't change that reality by praising Google's way of doing things.
- pavel_lishin 3y agoIt's worse than squandering money, it's squandering people's time, effort, their lives.
- leoh 3y agoThe counterpoint to this is that individuals can decide if they want their firm to be acquired or not or to stay around after it has been acquired. I don’t mean to put blame or shame on said folks, it requires a lot of careful thinking and self-inquiry and attention to one’s emotions and body to weigh said decisions well; which is hard for many reasons.
- sumeno 3y agoPresumably they got well compensated for their time and effort. That's about the best you can expect at a large company. You're working on the company's products and priorities and getting paid to do so. What they choose to do with it is up to them.
- bitterspeak 3y agoThe founders know of (or can easily research) Google’s track record with products and they knew the risk going into this acquisition. Probably an unpopular opinion but the time and effort was compensated as part of the acquisition.
- kccqzy 3y agoPeople can decide that money is more important than the continued survival of the product they are working on.
- rasz 3y agoRewrite was like a training camp, you learn the company way of doing things on something low stakes.
- danans 3y agoThe abandoning part is the problem, not the buying and rewriting.
- crdrost 3y agoYes but that is a cultural thing. And this is a big theme at Google, and I can say from my limited personal experience working there that it probably stems from the perf process. Look at it this way: Let Π be $PERFCOIN, the currency that is evaluated at performance review time. - Buying the company, got some folks some Π - Rewriting the code, got some (other) folks some Π - Maintaining the code, was not a reliable way to gain Π - Listening to users, interacting with and surveying them, and implementing what they wanted, was not a reliable way to gain Π. I worked on an internal tool at Google so I didn't have to deal with the huge warnings about accessing user information,[1] yet topic (4), there was just no great way to contact your users, no great way to shadow them as they were using the product, there was a way for them to request features but obviously that would be dominated by 5-10 voices trying to use the product in ways it was never meant to be used... Point (3) I eventually figured out how to do at Google before I left, first off you have to call it “tech debt” and THEN you need to create metrics for your tech debt and THEN you need to set an ambitious goal for “reducing tech debt metrics by 80%” and THAT is worth some Π to some of the managers reviewing your perf.[2] 1. Well, I actually did, because I needed a signoff from a privacy team to confirm that our use didn't violate Google privacy standards, which the senior members on my team understandably didn't even want to do, “can't benefit us, can only hurt us if they say we do need to protect Googlers’ privacy from other Googlers”—thankfully the voice of reason mostly prevailed, with a long tail of making sure that we used opaque UUID identifiers to refer to our projects, and not, say, GCP project IDs... 2. Worth saying, they transitioned not just to a less frequent less painful perf review process at the end of last year, but it was also a more authoritarian one, Instead of your perf being evaluated by a faceless committee of your manager’s peers, it is now assessed by your manager directly. This is a huge win for transparency and resolving the problem where (3) and (4) don't give Π , because pleasing the faceless committee involves standards that are completely unknown to you, but making your manager happy is what people do at any normal job. So this was widely internally criticized, but to my view it's actually potentially able to resolve the systemic problem, not immediately, but as culture drifts to be slightly more normal.
- xyzelement 3y ago// Buying something, rewriting it, and abandoning it, is just squandering money. I don't see it that way at all. Everything we do with business carries risk. It's really all experimental. Nothing is a sure thing. When you acquire something, you obviously incur the risk of that thing not scaling as well as you think, or over-estimate the fit into your org. You obviously want to make good decisions when you can, but there's a limit to how perfect you can be. People are familiar with the VC model of betting on a small percentage of runaway hits. This might be similar. So you can look at each acquisition in isolation and say "dumb" but you have to respect the machine that this is a part of.
- josephg 3y ago> but you have to respect the machine that this is a part of. I don't respect the machine. I think it reduces innovation across our industry. The story of google acquisitions so often go this way. They start with a lot of promises - "Your product dreams will be so much bigger at Google! All the resources you need! We believe in you!". When they start at google, everyone eventually realises they need to rebuild their entire product on top of google's infrastructure, "the google way". Inevitably, the remade google version of the product doesn't have "google scale" numbers of users. Or its crushed by some other team within google. Or they're shoved within a product group who see the newcomers as an irrelevant distraction at best, or a threat to their own product at worst. The good people from the acquired team move on within google and the acquired product dies. It happens so often its become a meme. There have been some notable exceptions: Youtube. Android. Docs (Writely). In each of these cases, google didn't have a similar product at the time of the acquisition and the acquired product team was largely left alone afterwards. As I understand it, Youtube and Android are (still?) kept at arms length in some ways from the rest of the company. This is a machine of destruction. It destroys innovative ideas and innovative products. I get that they can't all be winners. But google's success rate amongst acquisitions surviving - let alone thriving - is ridiculously low. And I don't think the teams & products that survive do so because of the strength of their work. I think they survive because of luck and politics. Other companies do this so much better. Instagram, WhatsApp and Oculus are very strong products and brands years after being acquired by Facebook. Adobe seems to be taking good care of Figma. And so on. Sometimes I wonder what would happen if google went bankrupt, and all the smart engineers within their walls were suddenly forced onto the street, where they need to make interesting products people actually care about to justify their salaries. I bet there's all sorts of great product ideas that googlers dream of building - but never will, because of how cushy and comfortable it is there. Google does some great stuff. But I think their employees are capable of so much more.