Google's payments team is seeing an exodus of executives and employees
businessinsider.com
businessinsider.com
[...]
> 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?
Says who? They are allowing people to apply for full remote, with an estimated 8500 so far approved.
https://www.businessinsider.com/google-approved-85-of-roughl...
> "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.
So it’s not as rosy as it seems.
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 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?
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.
Why not?
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.
I don’t get it. There’s code and working features. That’s the result.
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.
They don't want to increase the performance of the low-performers?
When Google got big, it got stupid.
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.
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.
I don't know if people leaving has something to do with that, but personally, I would leave immediately.
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.
Not that more feature is better, but to build those one needs more employees.
https://www.callahan-law.com/are-non-competes-enforceable-in...
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.]
I don't think anyone would be actually surprised at that fact.
You either build some shit or end up not getting a promotion / new job.
It's really the consumer-facing & consumer hardware teams that have this novelty-seeking-promotion problem, IMHO. (I've worked on both)
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.
management at google must have decided that interoperability is a weakness and killed it.
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.
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.
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.
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.
If you don't like your employer for whatever reason, now is the time to go.
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.
They own the internet's biggest advertising platforms, but I don't know 1/2 if their products.
I just said to myself I need to look into Google pay. Then I realized I use it on their domain registration app.
And by advertising---not the typical hip flashy "Street" horrid ads they are notorious for, but just a developer taking about a useful product.
Paypal is known for support issues, but Google?! That's a whole other level of support pain ..
I can just imagine my account blocked, thousands there, and... what? A wall of canned support answers, no recourse, misery.
This is Google.
Edit: come think of it, I know counterexamples :(
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.
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.
Also for Firefox despite the URL name, which is the one I use.
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?