Google would have been a lot more productive if it had hired people to work on one good messaging app instead of 13+ bad messaging apps.
Google has long had an attitude of "we hire the best so we can afford to have them stand on one leg and balance on a ball while holding a cane in their mouth and balancing a bunch of dishes on the end of the cane while typing with one hand on a chorded keyboard and looking at a monitor through a mirror." I've heard stories that range from "of course I am productive, I am shooting the s--t all day with the smartest people to" to "I have no idea of how what I'm doing impacts the bottom line".
Blaming the employees smells like a smokescreen for poor management IMO.
Who's to blame for lowered employee productivity: employees who are disconnecting from work more to avoid burnout thanks to corporate BS like paperwork and constant report filing? Or the managers who impose those requirements on employees but fail to empower the individual contributors beneath them in the org chart?
I recently left a large-medium sized tech company that failed to address massive structural issues in my department for years. It's not like these were a secret -- I brought them up constantly in my 1on1s, and tried to brainstorm solutions with my management chain.
When I left, the head honcho begged me to stay, and when I brought up those issues... told me he had no idea that was such a problem! But also refused to address it because he had to "gather information" about the issue.
I'm much happier at a smaller company without so much bureaucracy. At some point, managers are so disconnected from their underlings that they are completely incapable of improving work conditions. And when you need high-level approval to make a big decision... more often than not, the big decision just never gets made.
If you choose not to decide, you still have made a choice.
As a Google employee, the profusion of chat apps is caused by:
* a genuine interest in trying new things and trying to see if they'd stick, without the baggage of established UX & customers - Allo/Duo are like this. I don't think people give the company enough credit for this.
* leadership downplaying the cost to the Google brand of shutting things down all the time. When brought up internally, execs shrug saying that we must be willing to try and see if things stick. This makes sense, but why are people particularly mad at Google for doing this? It must be for a good reason, not merely a meme.
* org silos. The org behind Google Docs / Chat has a different reason for a chat app (chat as a checkbox for enterprise office suite sales) than the one behind Google Maps (you can chat with restaurants or whatnot)
* a lack of a good "design dictator", meaning our chat apps, as with other apps, falter for lack of great UX and don't gain traction. The biggest example I can think of is how Google Chat has a loading spinner for the emoji picker - this simple thing should be lightning quick, but it took a year for someone to even prioritize it.
* faulty marketing / branding. Taking the simple, beloved "GChat", which was the dominant chat app between AIM and FB Messenger, and wringing it though "Hangouts" and "Allo/Duo" and "Chat" - that's no fun for users.
I think the lesson here is that people want a simple, hyper-fast app that gets out of their way and slowly adds nice things on top. I'd say the apps that are most fun and fast to use are Messenger and iMessage. (I have plenty of problems with both - unremovable stories on Messenger, lack of archiving chats and general slowness on iMessage).
When I joined Google, I realized it was the same on the inside as the outside. There's a lack of direction. It's not just chat apps, and it permeates the entire company including Sundar. Maybe it's just too easy to lose focus when nearly all your income comes from one product and none of the others matter.
> leadership downplaying the cost to the Google brand of shutting things down all the time. When brought up internally, execs shrug saying that we must be willing to try and see if things stick. This makes sense, but why are people particularly mad at Google for doing this? It must be for a good reason, not merely a meme.
Because it doesn't actually make sense.
* Google has an audience. I suspect everything Google does is a good enough idea for a small subset of people -- or solves a problem for a lot of people but isn't profitable, like Google Reader -- and because it's Google doing it, a lot of people hear about it and use it. So the shutdown of Google's random ideas affects more people than the shutdown of some random startup.
* Google just kills the products completely instead of spinning them off or selling them to interested parties as earlier incarnations of Silicon Valley tech companies would have done. A company not bloated from search advertising revenue would have happily sold something like Google Reader for some money instead of just killing it.
Most of the problems with product @ today's Google come from "shipping the org chart." You touched on this in your third point.
This was one of the major factors that led to me walking away from there after a decade.
That, and it's just a slow boring place to work most of the time. One spends the bulk of one's time basically seeking permission to do the thing that needs to be done -- by this I mean: get in the right MDB groups, get the right sign off on design docs, be sure to be in the right team, be sure to have gotten the right people on your code reviews, made sure there's visibility to the right stakeholders -- and hope to god the thing you're working on isn't sexy enough that somebody better connected won't just steal it from you when you're halfway through it anyways. Or just take credit for it.
And the perf process and the culture around it produces terrible results on top of that.
Paid well, but was a terrible place to work. Especially once COVID hit and the free gourmet food and subsidized massages were a thing of the past.
The "while balancing on a ball while holding a cane in their mouth..." thing really resonates with me.
Something that really surprised me at Google is how many core services had very thin test suites. I'm the kind of person that sees 100% code coverage and thinks "that's a good starting point". If I don't have that, I'll definitely break something important in 6 months. There were a lot of people at Google, though, that definitely didn't need those guard rails. The entire team could read a changelist and know exactly what the consequences are; they could just read the diff and run the complete test suite in their head. So there was no need for them to spend the time actually typing in a test suite.
It wouldn't work for me but there were a lot of people at Google that absolutely didn't need to follow "good engineering practices" to do good engineering. I was impressed. A lot of people less smart than them try this and fail, but they made it work.
After 3 months at Google I've come to realize the high hiring bar is there because you need to be particularly smart just to get basic shit done in their environment. I spent 3 hours the other day trying to authenticate to one of Google's own internal APIs from within the Google network using their bespoke IDE. In the end the code necessary was pretty simple. But I'd tried many incorrect solutions before that. The API library itself is "deprecated" but the API is still very much in production and not changing any time soon.
1) Treat services you call like your own code. Familiarize yourself with the server code. Try running it locally and poke at it. If you run into problems in staging/production, go look at their logs and monitoring dashboards (if that's still allowed; I have a feeling that things have changed around permissions since I left). What I learned that there was never an error I needed help with as soon as I read the code and error logs of the app I was trying to call. "Oh, this deprecated field is actually still required, it's just IGNORED now", that sort of thing. In the real world, it really helps with open source libraries. There is never any useful documentation. So get used to reading the code, and you'll never notice it's missing. As you get good at it, it really becomes a productivity superpower.
2) Fill out all available forms. I wrote and maintained a monitoring system at Google. I remember going to some tech talk about how the network worked, and realized that I could be using a high network priority instead of Best Effort, just by filling out some form. In the unlikely event of a network problem, we'd probably still have monitoring! Fill out the form I did. And one day there was some network incident where a lot of consumer-facing apps were slow/down, and my service didn't miss any messages. No unnecessary outages or pages or a long night, all because I filled out a form that anyone could fill out. I honestly felt a little bad because I guess we could have lived without the monitoring if it would have saved GMail. But hey, victory goes to the team that's willing to fill out the form and maybe have a quick meeting about it. Not everything in software engineering is programming.
There is quite the ramp up time, and there is a lot of learning to do, but once you get a handle on it, you can really do great things at high speed. If you ever leave, you will miss it. As much as people complain about the tools/systems/libraries, it is all really top notch. The "real world" is a hodgepodge of half-baked systems that all cost $30,000 a year. (Whoever wrote Prometheus left too early and cloned varz instead of Monarch. Hurts my soul every single day.)
I most miss D, Spanner, Blaze, and Monarch. Spanner you can buy from Google, but I can't afford it. Bazel is open-source. The rest... you just have to settle for something not as good.
I like some of the tech so far. And I have a good amount of startup experience, so I know the world of paying for SaaS instead of having your own special internal solution. Sometimes paid SaaS is superior. It's built for users more so than developers. That limits your powers but also means it's meant to be used by someone that doesn't know how it works.
Blaze seems very nice. I'm deep in a special domain far from g3 - so I only came across it this week. But it has worked exactly how I want it to and has given me no trouble, only a good experience so far. Much better than the terrible world of whatever build system NodeJS is using this week.
And the perks are pretty nice. Not enough to make me never go back to startups. But I appreciate them. Extra days off that no one else would get. Free trips to amusement parks. Days off to go sailing. Good free food. Good free cappuccinos. Good free snacks. Free car charging. I'm shocked so many people living in Mountain View refuse to commute in after working from home for two years.
> The entire team could read a changelist and know exactly what the consequences are; they could just read the diff and run the complete test suite in their head. So there was no need for them to spend the time actually typing in a test suite.
I think testing at Google is excessively complicated for a myriad of reasons, and the unit-test-style "coverage" doesn't really map well to how things work together in a larger system. That system-wide thinking is where the "read a code change and know exactly what's wrong" intuition becomes invaluable. *Integration* testing is especially hard for some reason (probably complexity in the serving stack, at least for many teams I've worked with), so you end up getting this pattern where people get better at other production health stuff like canary systems, release management, etc.
Writing a messaging app is a fool's errand. You either build a chat app with someone elses money, invest in all chat apps (1/n) and hope you score a big one - e.g. like textbook publisher, or you wait and M&A the successful ones.
The barrier to entry to write a chat app is zero. Even if you are brilliant you will compete against hundreds other chat apps one of which will beat out with pure luck. Never compete against luck.
Google has Android, which is a lot better than luck. Apple made iMessage popular just by putting it on every phone. Google did that too, but they did it wrong.
Yeah so you compete against luck by leveraging your prior dominance in mobile OSes with a committed iMessage-like approach, instead of waiting for two former Yahoo! employees to eat your lunch then launching several competing apps that you kill off later.
We’ll a lot of their products come out if individual side projects, Google is an incubator of sorts so I’m not surprised that’s how their product gets made.
... There was that time that top management thought reverse imperialism was a good idea so they dumped a perfectly good Google Wallet in the U.S. for something that was big in India... No thought of cultural sensitivity. A few years later they reversed the decision, with no consequence for the people who made it.
If you are doing that for your products though you are never going to get long-term traction no matter how good or bad your engineers or marketing people are.
I don’t know what you’re trying to say? Are you saying they discontinued a product that was big in India? How is this reverse imperialism? What is reverse imperialism?
Google has long had an attitude of "we hire the best so we can afford to have them stand on one leg and balance on a ball while holding a cane in their mouth and balancing a bunch of dishes on the end of the cane while typing with one hand on a chorded keyboard and looking at a monitor through a mirror." I've heard stories that range from "of course I am productive, I am shooting the s--t all day with the smartest people to" to "I have no idea of how what I'm doing impacts the bottom line".