> Dozens of employees and executives have left the group
[...]
> more than 3,700 full-time employees, according to recent internal data viewed by Insider. Roughly half of those were previously overseen by Sengupta.
Do I read correctly that "dozens" out of about 1800 people have left since April? Is that an abnormally high number, especially right after things started opening up again after the pandemic?
Google has been rolling out an astoundingly aggressive anti-remote policy from what we've heard - and it's probably even more aggressive internally. I wouldn't be surprised if they're just losing a lot of the folks that realized quality of life matters to them.
All indications pointed towards no remote option, but that switched a few months ago. Most people in software engineering roles have decent access to full time remote options, especially if they are willing to change orgs. I don't know a single case in my org (hundreds of people) who had a rejected remote application.
I've always been confused by Google's reputation for pushing in-the-office work. I've met with... 3, I think, Google teams quite a few times over the years, and not once have I seen Google engineers in the office for these meetings. I even flew into the area for a meeting at Mountain View once, we got escorted in by a manager, and we sat in a conference room while all the Google engineers dialed in from their homes around the Bay Area. But yeah, everyone seems to talk about Google not being remote friendly (pre-COVID, that is).
[Also a Googler here, speaking my own interpretation rather than any official policy.]
They make the official policy in-office to set the expectation that that's where you'll be, and then they can negotiate exceptions on a case-by-case basis. I've never seen a high-performing Googler (meaning one who has successfully launched a project) turned down for remote work or office transfers. They don't want the non-performing Googlers (who possibly might outnumber the high-performing ones) working remote though. If you're meeting with engineers as an external partner or customer, it's almost certain those are high-performing engineers, because they wouldn't be put in that position otherwise.
I'd assume that verifying that non-performing Googlers are actually working, and correcting performance issues, is much harder when they're remote. Most knowledge workers pretty much have to be trusted to perform their jobs, but that trust is much harder when you can observe neither process, progress, or results.
In most knowledge work - not just Google - you're fine as long as you're either putting in effort or getting results. After all, software development has plenty of risks, it's possible to fail to deliver for many reasons other than being lazy. But when you are neither putting in effort nor getting results, that's when you're at risk of getting fired, because the company starts to wonder why they're paying you. Remote work makes it much harder to observe the "putting in effort" piece.
It's not just about the code, it's also about the culture.
Non-performing staff could be non-performing for different reasons - not just output - and it's often easier to spot those reasons (and address them) when you're working in the same office.
Source: I've been running a company with hybrid in-office + remote staff for 15 years. Would be happy to expand on the above if asked.
People who consistently deliver code and working features usually don't have a problem getting approved to work remotely. That's the case-by-case part. It's the people whose code is buggy or nonexistent and whose features don't work that are stuck in the office.
But what is there's no code or code that is not used in a working feature? Both ends of the performance spectrum comprise people who don't really code.
I can tell with certainty that slacking in office is extraordinary simple. You can even slack your way to massive overtime, as you chat with this or that person, hang around, procrastinated with actual work or just plain browse reddit.
Everywhere I've worked has had a policy of no remote work. Yet, if you got your work done, and your manager was OK with it (probably the case if you get work done), no one cared. I guess they could look at badge data (if your company has them) but I've never seen a company do that.
I don't think I've ever had a manager that could be convinced to care about this even if some level of management did in fact care. Who the hell wants to spend time taking attendance like a schoolteacher?
Yes, anyone can apply. But no, not all orgs will accept a remote application.
And if your org says no, there aren’t that many internal remote options yet. And some orgs will say no to remote transferees for the first N months or a year.
So it’s better than before, but some orgs are still stuck in no-remote, and for many a departure is the way to go remote.
Very few of the eng orgs have policies against remote work. Even TI supports it, despite whinging over Urs' statements. I'm also not aware of any manager who'd reject an internal xfer who had a record of good performance for remote work.
Would I like to see more to support remote work? Yes. It feels ridiculous to me that the folks in Sales don't have the same options. But from the actual data collected most people in a position to work remotely have access to it.
> "The company also turned down requests where organizations "made a commitment to invest in key growth sites and are working to build their teams and critical mass in those particular hubs," Google told Insider."
That reads like "if someone in your organization chain said they want to build a hub in your region, we'll probably deny your request because headcount need to be filled for those hubs"
Which is fair for the company to do but you can see why that can trigger attrition too.
Point taken, thanks for raising it. I could definitely see some newer sites have that issue that require local teams until critical mass is hit. I guess the sites I tend to work with are already very well established, so people I've seen apply have all been accepted (of the ones I know).
Some people aren’t even applying because their orgs have made it clear that remote won’t be approved, and some people are being denied for spurious reasons. (Best one I’ve seen is: personal reasons not strong enough for remote.)
10-15% annual attrition is normal. If this is ~36 total departures in a quarter (2%) its entirely in line. But if its 36 in addition to some unspecified baseline it would be a moderate problem.
Caesar leaving was interesting for sure, and he just announced a new fintech startup yesterday. https://www.arbo.works/
I can't speak to why he left or what he's doing now, but I wish I did know. :)
Also, it's important to remember how big Google payments is. As the article says, Bill Ready has 3700 people reporting to him that do a lot more than the Google Pay app (which lots of people are talking about here). We do a lot of things.
Your vp for payments is named "Bill Ready"? Ive seen this phenomenon enough times to believe it's not a coincidence, but some sort of echo of label theory. See also: Doug Bowser, head of Nintendo america.
Maybe I should write you directly, but there was a mystery error adding my new bank account so now Google Play owes me a little money. Google Pay support has been trying to fix the problem for 2 months and they kindly write me every few days to let me know they’re trying to figure it out, but does this issue have anything to do with brain drain in your group? I’m more curious about that than the money - how is it possible the Google Play Store can go 2 months without being able to add a developer bank account? (Clearly I’m more of a snowflake). I imagine this is extra complex because Google Pay is being used for various purposes by different sides of the business.
How do all these Google employees leave and then immediately announce competing startups? Is it because they live in California? Most job agreements specifically disallow this in a non-compete. I don't agree with the practice of non-competes, but I thought pretty much all companies had them.
Is there a reasonable explanation why the new Pay app doesn't work with custom domain / business accounts? I am guessing it isn't resourcing.
The old one did; luckily I can still use that with my personal profile until I upgrade my phone, unluckily I didn't install it in time on my work profile - which is where I pay for many more things.
[Don't mean to bash on you personally, it doesn't sound like you are even on the app team, just annoyed by the downgrade.]
It's nice seeing these well paid VPs of a comfy company choose to take the risk and go work at a startup but this company has too many "former VPs" so who's doing the actual work?
Because for the life of them, Google can’t seem to create a single messaging system that works well.
If they could simply make ONE system that works as a standalone product, has a decent API available to internal developers and external. That would be a start. But no. They have to make it part of something else. Always. And they always miss the target on usability.
That's not fair, gChat / Google Talk worked pretty well back in the day. I could even search my messages on mobile, which is something Hangouts never managed to offer in the many years after the migration.
Yes, Talk is clearly their best effort to date, but it wasn't great as a product. For instance it didn't have group chat that actually worked.
Also, in retrospect, they did the wrong thing by choosing to offer XMPP as a public interoperability interface.
I liked the idea of XMPP when it came out - or rather, the idea of having an IETF standard for chat. But XMPP had unnecessary problems due to poor design choices, probably informed by people who didn't have experience writing tidy and efficient server code.
If you are going to design a network protocol you _have to_ involve people who know how to write server code in at least a handful of languages so that you know how to design stuff in mechanical sympathy with how you typically implement various aspects. Any standard written by people who are non-programmers or mediocre programmers will suffer.
As a result of poor design choices, XMPP clients didn't turn out well. One example being that group chats were clumsy and ugly affairs in every single client. If they even supported group chat, which not all clients did.
So I can understand Google eventually ditching interoperability.
What they should have done is to just design their own protocol and open it, but at the time the choice was made to use XMPP a lot of people (myself included) really wanted it to succeed.
(I actually blame XMPP for successful chat systems ending up being closed proprietary affairs. It shows how dangerous it is when people get infatuated with certain ideas and do not pay attention to what it takes to implement properly. When you have a poor standard that costs a lot to implement but which people kind of want to succeed it doesn't leave a lot of room for other standards to emerge. I know a lot of people will react negatively to this. I'd encourage people to try to implement an XMPP server well. Not just something that kinda works and pisses away a lot of resources: do it well. That's an unreasonable amount of work)
As for Google: I'm not sure what was worse. Chat never being a goal in itself, but rather something tucked onto other services or the fact that to this day Google manages to make any form of chat or VC service confusing.
Whenever I have to use a chat that isn't part of a calendar entry I do the same head-scratching exercise. Where do I go again? Which account will I end up on now (it seems to have a talent for ALWAYS picking the wrong account).
At this point I'd rather not use Google for anything that has to do with communication. But it is hard to avoid. Unfortunately.
and the reason it works so well is because gchat is based on xmpp which makes it more open to interoperability and access to pre-made libraries etc. And you can use any clients supporting xmpp.
management at google must have decided that interoperability is a weakness and killed it.
Look at my comment above. Yes, at the time XMPP interoperability at the edges seemed like a good idea, but XMPP wasn't a good standard.
No, the reason it worked well was because Google made their own backend that could actually scale and which wasn't based on XMPP at all. (I actually spent a lot of time reading the code and talking to the people who designed Talk while I was at Google, because that project had a lot of really good lessons in how to deal with challenges in distributed systems).
The XMPP interop was nice, but it was just that: a client interface adapter. I can't think of a single XMPP backend that even comes close to working as well as the custom architecture Google used for Talk.
Actually, XMPP is the worst kind of standard you can have. Something that superficially looks like a good solution, but doesn't lend itself to clear, correct and performant implementation. And at the same time is seen as THE standard for chat. So people won't be inclined to "start over".
But if we're going to have chat interop, that's what we have to do. I'm not kidding.
If XMPP was any good you would see companies that do chat products at scale prefer it, at least in the backend. Imagine all the time you can save. But they mostly don't. Ask people who develop chat systems why not. (Zoom is the only company that comes to mind, but chat isn't the main focus of that product, just an aside)
Google killed XMPP interop because it was a pain in the ass and a technical obstacle. And then chat gradually became a closed affair because we, the developer community, just didn't come up with something that worked well enough to replace XMPP.
> Google killed XMPP interop because it was a pain in the ass and a technical obstacle.
Yet Talk/XMPP was, tied with Hangouts, Google's longest-lived chat system to date (officially, anyway - last I knew a few weeks ago, it was still accepting XMPP client connections).
XMPP has an open and diverse community, and I assure you there are many competent server developers involved in its development.
Disclaimer, I'm heavily involved in XMPP, though I wasn't around for its conception. I've implemented it from both a client and server perspective. I'm not here to claim XMPP is perfect, but it's absolutely a good fit for its problem domain (an interoperable messaging standard).
As a software engineer I've implemented many other protocols too. I assure you that all protocols have their quirks, XMPP included, but I've yet to see anything that would be a suitable replacement.
I blame Google's culture as an organization for their inability to succeed at messaging. I blame financial incentives for large companies choosing to build silos rather than interoperate/federate. Whether that uses XMPP or not I really don't care - all the big players have had plenty of time to propose an alternative (or participate in XMPP development, as Google did for a period). I think only regulation can save us at this point.
Yes, which is why the least skilled developers maintain the products, which is why they eventually get canned. This is not inevitable in software —- it is specific to Google. At business software companies, for example, maintenance is not career suicide, so you have very senior engineers who work on improving the engineering systems to detect and fix bugs, leading to a more effective long term software maintenance capability.
Maintaining and improving core systems is what entire large teams in Google's Ads, Search, Core, etc. teams do, and yes, they get promotion for it. It's often not very sexy work, but it is recognized.
It's really the consumer-facing & consumer hardware teams that have this novelty-seeking-promotion problem, IMHO. (I've worked on both)
Promotion rates in Core Dev are higher than normal across the company. The idea that you cannot get promoted writing tooling or making engineers efficient or keeping the codebase clean is simply not supported by data.
What it sounds like is that if you're maintaining things it needs to be something important to the business to get promoted, but if you create something new then it doesn't have to be.
I'd edit that to say that it is easier to incorrectly believe that something new is important to the business but that you really do need to make the same impact argument in both cases.
My guess would be that it's interesting and achievable work. It is probably being done by people who have never built a messaging app so there is lots to learn.
The messaging app is not about chatting, but it is about transaction documentation and history of it.
It is actually very useful feature, one can do pre & post transaction related chat - which captures the 'negotiations' or 'agreements' around that transaction. Subsequently the same becomes a proof of record, which later can be pulled up incase of any disputes.
They just repurposed their awful app that was entirely geared towards the Indian market and used it to replace their descent Pay app that respected privacy.
I’ve been pondering for a while why Google never tried to acquire PayPal, and/or perhaps most importantly Venmo (which is part of it). With Android & Chrome being the platforms that they are, the ultra tight integration of payment of PayPal/Venmo should be interesting to unlock more payment growth. Yes Google has the technical ability to build competitors to those, but the market of consumers/SMB’s don’t appear to understand the Google payment offering. Whereas with PayPal/Venmo as the frontend brand, it’d be hard to argue that the market would be confused given the already existing uses and brand appeal. Of course this sort of merger may raise all sorts of antitrust flags so maybe it’s just a thought experiment and nothing else for now.
Googl Pay is pretty popular here in the UK. The value proposition is simple: it's like a debit card, but it uses your phone, and thus can be more convenient in certain circumstances.
From my european perspective, where sending money between bank accounts is free and easy using their first party apps, the last thing I'd want involved is paypal who have a reputation for stealing people's money and generally being difficult to deal with.
So they take a working Payments app with browser access, and then replace it with a mobile-only payment app apparently geared towards the Indian market. Now, they want to gamify my finances and have me share my bank records with them so they can "reward" me. I'd leave too if I previously worked on developing something that was based off the "don't be evil" philosophy only to be replaced with something resembling evil.
Apart from the "evil" cliche you're right. It seems like all these executives are trying to do some growth hacking when a product hasn't gone viral.
This guy probably promised significant user growth to his manager by adding all these coupon and using "AI". I have installed the app and none of the new features appeal to me and I don't see why it would appeal to anyone else. Probably none of these executives even use this product themselves and just chase trends they've heard about.
None of them seem to have any intuition on what makes for a good product. All they are chasing is growth numbers to boast about in a presentation and get promoted/rewarded for.
Can't understand why these executives are paid so much given their track record.
What is “Google Payments”? Is this just where they save your credit card info and let you pay at various places? Why does that need thousands of employees?
I think anyone from the outside can see that Google has no central vision for is auxiliary products and as such, all of these products “boil” out of the company and evaporate into nothing.
All these half-hearted products Google develops and often cancels makes me think it's a great place for developers and executives to train themselves and gain street cred, kind of like getting an ivy-league degree, and then move on elsewhere to real jobs having a real impact. In other words, it's the best way to get a masters degree with the added benefit of being highly paid while doing it, as opposed to paying highly for it.
Best way to learn how to develop good products is to develop products everybody uses.
This option is not open to most people, though, and developing products nobody uses is a significantly better way to learn than not developing products.
Come on. You can have someone do a great job creating a tool that nobody uses. The experience acquired building that tool is independent of the subsequent market demand.
That's essentially what university is. Learning and research for its own sake or for the sake of self-improvement without worrying about applications or real world value.
Thanks, please upvote this to the top folks since I assume most don't have a subscription and can't read the article and will only comment on the headline title.
Yeah, I don’t know how these hard-paywalled articles keep making it to the front page. My understanding has always been that if there is no workaround, it isn’t allowed here.
It's not a "hard" paywall - their paywall is very easy to get around. I use the uMatrix browser extension, which disables JavaScript and cookies from third-party domains, and the full text of the article is displayed to me. This also works for many other sites, like the NY Times and Washington Post.
It's definitely going to get thrown out eventually. 100%. It can't hold a candle to Apple Pay and some exec is gonna convince the higher ups that they need to rebuild it from scratch.
I wouldn't put anything past the company that risked everything on Google+ and then basically abandoned it a few months later when they didn't see the mass exodus they were so delusional in expecting.
Am i missing something? To me google pay does contactless payments so i don't have to carry my card. Hugely useful. What does Apple Pay do that is better?
