What's surprising to me is that it was allowed before. They have had their own videochat solution for years, so I would expect the usual "eat your own dogfood" approach.
With various levels of being merged or not.
It was banned as in it can no longer be installed on corp laptops.
Especially at Google scale, where the BeyondCorp system described in their papers could automatically see when an endpoint was doing something naughty, block the user from accessing corporate resources, and give the user information on how to fix it, instead of blocking them from installing anything (even if what they want is perfectly harmless).
I have no idea how I know this. ;)
There's also that zoom free tier creating a 'Shadow IT' situation. Slack used this to great effect and everybody on HN was very impressed. It should be no surprise that Zoom is finding its way onto random employee laptops, that is something tech firms are trying to do on purpose now.
Many (most?) companies are perfectly fine with you using your corporate machine for typical home-life stuff and side projects as well.
Reduces waste of having to buy two devices.
Seems nothing wrong with it to me?
I really want to know what goes on within Product Management at Google, because looking from the outside in I cannot imagine anything other than sheer incompetence.
A friend was managing a project on a shoestring budget. Upper management (C-suite) had reviewed the idea and green-lit it. He had been told Larry and Sergei in particular had voiced support. He got it done ahead of schedule and under budget by managing a stream of off-cycle interns. The week it was scheduled to go live, someone in middle management killed it. My friend and his team got zero credit for a job very well done, a big setback for him. He and I were working on an internal tool for datacenter management as a 20% project when I left. I asked him about it later, and our 20% project met a similar fate: enthusiastic support from management, including giving us some resources, all the way through completion, followed by cancellation shortly after completion. My friend left less than a year later.
Another friend started a modest improvement to chat as a 20% project, which later got expanded to a full-time project for several engineers. I forget the external name, but the internal code name was "Taco Town" after the SnL skit. Walkabout / Wave was a skunkworks project that used its separate repository, which was very rare at Google. People knew something mysterious was going on down in Australia, but we really had no idea what it was, other than the Google Maps guys were running it and it was named "Walkabout". When Walkabout / Wave came out of skunkworks mode shortly before external launch, the Taco Town team realized they needed to launch very soon or their project would never launch because its functionality was subsumed by Walkabout / Wave. Taco Town rushed its launch, was a bit buggy and had some scalability issues that they knew about, but expected to be able to improve shortly after launch. I think Taco Town's botched launch a few weeks before Walkabout/Wave contributed to initial confusion around Wave and some of Taco Town's problems colored perceptions of Wave's launch.
Shortly after I left, Google publicly announced they'd be putting "more wood behind fewer arrows", which was a step in the right direction.
I get it that management doesn't want to discourage engineers or stifle innovation, and they know they don't have a good handle on what will be successful and what won't, but keeping around zombie projects gives engineers false hope. The "throw mud at the wall and see what sticks" style of project management can be soul-crushing for talented junior people managing small projects, unless they're properly supported and really get proper credit for doing a very good job engineering something that fails for non-engineering reasons.
We're using MS Teams and it seems to be pretty great for us (team of about 15), we use Skype to contact the remaining 20ish more junior staff who don't need Teams licenses just to be able to keep in touch with their work and keep the face to face communication going.
> They have had their own videochat solution for years, so I would expect the usual "eat your own dogfood" approach.
If an engineer from Microsoft has to speak to an engineer from Google, and you think they should both be dog-fooding their own video application... how do you see that working? Just both dig their feet in and never talk to each other? Seems silly to me.
One or both are going to have to install a video application that isn't their own aren't they?
They could use a telephone. (Yes, they still exist.)
Edit for response:
Neither Google nor Microsoft forbid their employees from using telephones, and neither would even consider it. The assumption that they'd dogfood their own video chat platforms is obviously not a supposition that they'd ban telephones. Your comment frames the matter as though a third party video chat service is the only pragmatic option. Video chat was a fringe concept not very long ago, considered mostly to be in the realm of science fiction. Even today, inter-company telephone meetings are still common. Tech-fetishists working in this industry often seem to lose sight of the obvious time-tested solutions that still work today. I think a lot of people are earnestly forgetting that telephones still exist.
Well that's example of what I suggested they'd have to do - use someone else's service.