Google's payments team is seeing an exodus of executives and employees(businessinsider.com)
businessinsider.com
Google's payments team is seeing an exodus of executives and employees
https://www.businessinsider.com/google-pay-payments-team-seeing-executive-exodus-turnover-caesar-sengupta-2021-8
130 comments
https://archive.is/cYrEf
> 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?
[...]
> 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?
A 10% turnover rate in 4 months is pretty high, though I don’t know their baseline.
10% is 180. That seems pretty far outside of the expected range of "dozens".
True lol I misread. So it’s close to 1% in 4 months or 3-4% a year, which should be pretty normal
Yeah, let's say average tenure is 5 years. Wouldn't that indicate that each year 20% of workforce would leave?
It depends if you're including the tenure of all the people who have departed or not - AFAIK most places don't, which skews the numbers tremendously.
I heard that Google has decided to force everyone to get vaccinated before the end of August if they want to remain employed.
I don't know if people leaving has something to do with that, but personally, I would leave immediately.
I don't know if people leaving has something to do with that, but personally, I would leave immediately.
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.
Googler here.
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.
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.
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.
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.
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'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).
[deleted]
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?
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?
[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.
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.
> They don't want the non-performing Googlers (who possibly might outnumber the high-performing ones) working remote though.
Why not?
Why not?
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.
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.
> but that trust is much harder when you can observe neither process, progress, or results
I don’t get it. There’s code and working features. That’s the result.
I don’t get it. There’s code and working features. That’s the result.
If I may humbly weigh in on this...
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.
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.
15 years of experience with this kind of work puts you well ahead of most, so I’ll bite: please do expand on the above :)
I take it you're not a professional slacker. It's so easy to game all these tracking systems.
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.
You've just explained it yourself: there may not be enough code and/or working features.
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.
> They don't want the non-performing Googlers (who possibly might outnumber the high-performing ones) working remote though.
They don't want to increase the performance of the low-performers?
When Google got big, it got stupid.
They don't want to increase the performance of the low-performers?
When Google got big, it got stupid.
Googler, opinion is my own.
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...
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...
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.)
So it’s not as rosy as it seems.
So it’s not as rosy as it seems.
From the article
> "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.
> "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).
[deleted]
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.
Googler, opinions are my own. I work in payments.
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.
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.
Also head of Tesla’s AI and autopilot, Andrej Karpathy. Like car path. It’s crazy
Some examples here: https://en.m.wikipedia.org/wiki/Aptronym
Doug Bowser sounds like Kim Dotcom of Megaupload (except that Dotcom actually changed his name to match his business; he was born Kim Schmitz)
Another one is Rich Fairbank of Capital One.
I was pretty sure Bowser the character is explicitly named after Bowser the executive, so not exactly a coincidence.
Bowser only joined Nintendo in 2015. I'm fairly sure Bowser, the character, has been named Bowser far longer than that?
https://en.wikipedia.org/wiki/Doug_Bowser
https://en.wikipedia.org/wiki/Doug_Bowser
You're confusing Kirby (John Kriby, https://en.wikipedia.org/wiki/John_Kirby_(attorney)) to both Bowsers.
My favorite is the quantum computing researcher Toby Cubitt.
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.
Yes, California bans non-competes.
Non-competes are not enforceable in California.
https://www.callahan-law.com/are-non-competes-enforceable-in...
https://www.callahan-law.com/are-non-competes-enforceable-in...
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.]
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.]
Is there anything being built there that could dominate fintech? I haven't heard of anything. 3,700 highly paid individuals is a lot.
Google Pay is the most popular payment system in India, a country of 1,400,000,000 people.
PhonePe another payment app is bigger than Google Pay in India, and they are around 2000 employees but their feature set is order of magnitude more.
Not that more feature is better, but to build those one needs more employees.
Not that more feature is better, but to build those one needs more employees.
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?
There's a messaging app inside G Pay too.
I don't think anyone would be actually surprised at that fact.
I don't think anyone would be actually surprised at that fact.
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.
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.
There is a messaging app inside Google Maps and a different one inside Google Photos (I think).
I wonder if building a messaging app is the secret to promotion at Google. I cant think of any other reason they would have so many.
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.
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.
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.
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.
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.
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.
That explains why my 2008 BlackBerry had a Google-built Gtalk app. Almost no third parties were developing native apps for BBOS 6 at the time.
Building new useless shit is the secret to succeeding as a developer.
You either build some shit or end up not getting a promotion / new job.
You either build some shit or end up not getting a promotion / new job.
You mean the secret to being a developer is... developing?
Certainly it's not a career that rewards maintaining legacy systems or cleaning up technical debt.
That's for the new hires. The experts who created those things move on.
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)
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.
It’s obviously reductive and unfair to say so, but sometimes it seems like strategy is an emergent property at Google.
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.
Given the market, is there anywhere that isn't seeing an exodus?
If you don't like your employer for whatever reason, now is the time to go.
If you don't like your employer for whatever reason, now is the time to go.
Tempting, but I personally worry about a glut of talent. Truth be told though, I would probably have anxieties no matter what the market looks like.
It might be a nice boost to your confidence to apply at a time when everyone is looking for talent and you'll get more callbacks.
No reason you can't quietly explore your options.
Can you share more about how the current job market is different than usual?
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.
The real problem is, who wants to integrate/use something Google may shut down tomorrow, and, google is famous for no customer support.
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.
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.
A timeout and an automatic refund? Not giving back unspent money is something that no legal department on this planet would risk.
Edit: come think of it, I know counterexamples :(
Edit: come think of it, I know counterexamples :(
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.
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.
I don't know why they don't advertise more?
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.
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.
The whole payments team at Google has had a reputation as a terrible place to work for many years. Due to the leadership, culture, and the product.
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.
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.
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.
[deleted]
Stripe, Robinhood, Square are offering larger TC. An experience is relevant
This doesn’t seem to be the case for Square, at least.
[deleted]
[deleted]
[deleted]
Paywall splash modal is blocking content. Needs an Archive.org link.
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.
That's like saying the best way to learn how to develop good products is to develop products nobody uses.
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.
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.
So doing exercises that are ineffectual is better than not exercising at all. Got it.
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.
Except “nobody” here is often millions of people.
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.
We detached this subthread from https://news.ycombinator.com/item?id=28251905.
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.
"hard" as opposed to the "softer" ones that give you some number of free views first
Another workaround: https://github.com/iamadamdev/bypass-paywalls-chrome
Also for Firefox despite the URL name, which is the one I use.
Also for Firefox despite the URL name, which is the one I use.
are they shuttering this one too
Nah. I know the memes, but payments is far too core to throw out.
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.
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.
> It can't hold a candle to Apple Pay
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?
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?
If this org includes user payments for consumer-facing paid premium products, then the org is definitely way too important to ever be shut down.
Saving this for later.
Google hasn't fielded a commercially sucessful product since search, right? Youtube was an acquisition and lost money for years.