Teams doesn't have to be good to succeed. It just has to exist. It's not even very important how good it is. Given it exists, IT will make everyone use it on Microsoft's behalf regardless of how bad it is.
Or another way to look at it is that the real customers for Teams are IT departments. It makes their lives easier because they don't have to do anything and it meets all the compliance requirements they are supposed to enforce.
Which in turn reflects that the real customers of IT are regulators and auditors. Nobody with decision making power actually cares whether any of the software in use in enterprises works well or not.
Yup. It might even be that while the engineering team is aware of the faults, the MS exec team considers Teams to be brilliant.
At the senior level the role becomes a sales role - you are continuously selling your output, team, product, vision, etc internally to the other execs, board, etc. It's important therefore to present whatever you are producing as exceptional. So you look for indicators that support your pitch. Sales and forecasts are far more important than product. Product is only as important as far as it directly impacts these numbers. And with channels / vertical integration / brand like MS, a core tool like Teams is almost a guaranteed success on these metrics as long as the product kinda works.
And then it's very easy to fall into the trap of buying into your own pitch. When you are continuously repeating how great the product is you begin believe it and ignore criticism, including public opinion. "What matters is the markets opinion not the publics opinion and Teams has huge market share".
So MS execs likely believe Teams to be brilliant, which is probably partly why there isn't the internal urgency to fix the issues.
Also - its a golden goose! Its good enough, generates tons of revenue and fills a strategic product gap. Why take a big risk and refactor it? This could be a disaster.
Takes a very brave, product focused leader to push on despite the above.
It is the old joke. Dev says it is shit. Manager says it is dung. Senior manager says it has a strong odor. Director says it is powerful features. VP smiles in satisfaction.
Was looking for a good place to post this in the thread but I'll just drop it here. Microsoft Teams still lacks multi-account support on desktop.
As in, you can't sign on to several business organizations like you can in Slack. It's so dumb and disqualifying. Utter nightmare if you work with several organizations.
The fun part is that this functionality already has been added to teams (for over a year now), it’s just disabled and hidden by default. Might be worth enabling it if you use multiple orgs. https://techcommunity.microsoft.com/t5/microsoft-teams/track...
> As in, you can't sign on to several business organizations like you can in Slack. It's so dumb and disqualifying. Utter nightmare if you work with several organizations.
I think they were really hoping they could make that cross-tenant thing work where you only have one account that you can use as a guest in other orgs, but that really doesn't reflect how things work in the field (you have separate accounts at each organization).
This is a problem even if you work for one organization (e.g. govt or university) but have clients/collaborators in other organizations, and want to join their teams.
This. And the second reason is "We have KPI's with Microsoft about teams: they guarantee that it works in x% of the time, and they guarantee that it complies with our security guidelines". Notably the security is something that can never be beaten by any other application, be it on of off premises. No matter how brilliant it is. It can never beat Teams, because Teams is "good enough" and "free" at the same time.
On the top of my head, excel and all the features it has. There are probarbly lots of other things. But if Googl Workspace works then good for you. I just know there are tonnes of companies out there that just cant live without MS-Office
If you're the one in charge of the budget, paying $12.50/month for each employee does not make sense if you're already paying for an alternative. (Assuming Business is sufficient; Enterprise would be a lot more.)
I'm skeptical that even mighty microsoft can make anti-competitive claims go away by complaining to their favorite regulators. They were beat up by that. Can you provide more info?
While this is true - you have to look at the competitive space also (not just Slack). My previous employer forced us on a hosted HipChat. Absolute garbage. laggy; crashed often (sometime taking down my host) and worst of all randomly deleted chat history - so if someone sent you something (important) you may or may not be able to reference it later. Absolute garbage.
Left that company (a fortune 50) ~roughly when Teams began rolling out, and my coworkers complained to no end (Slack -> Teams migration happened roughly when i joined). I still complain about Teams - but outside of raw IRC Teams is by far the best messaging App I've used at work. (I do also run slack/discord for personal groups/projects, though nothing at crazy scale).
I used HipChat for years and never actually saw what the thing looked like. Any XMPP client just worked, no hassle whatsoever. When we later switched to Slack it was actually a downgrade from my point of view. :-/
Unfortunately, at least in my experience, if the company shows any signs of success then incoming Finance/IT execs will force a change to Teams to "enable growth". If they begin to struggle, then incoming Finance/IT execs will force a change to Teams to "consolidate and streamline". I've experienced both of these. Resistance is futile.
There's lots, but I think it comes down to two main things: It has bad defaults, and it can be customized to have really draconian workflow rules.
If you configure it to be reasonable -- keep the workflows very simple with few to no validation rules -- it can be fine to use. The temptation seems to be locking down admin access to managers, and then the admins going crazy building workflows like "these 19 custom fields must be filled out to start" "items must go through a QA step" "QA users are the only people that can approve that step" and "PMs are the only ones that can close a ticket". This quickly gets out of hand and makes it horrible to use.
It also depends on the people using it -- garbage in garbage out, as they say. If people write good tickets (concise titles, format the body, remove irrelevant crap, and properly fill out meta fields like fixVersion) it is much more useful. JQL is awesome, and embedding tickets and JQL queries of tickets into Confluence is awesome (hint: easy way to make release notes) -- but both of these require non-garbage ticket content.
Subpar at what it's supposed to do, extra features don't add a whole lot, mostly made and configured for managers instead of developers. Largely the same reasons people dislike Teams. Has even worse integrations with the Atlassian stack than Teams with the MS stack.
JIRA, just like Teams, is slow, bloated, still won't fix basic issues and largely exists to appease managers. You have to actively work to make JIRA a pleasant experience. It's too easy for most management to make it hell.
I personally find that the more I have to use JIRA, and the more magical ephemeral rules that are set up in it to take actions in response to my actions with it, the more terrible it is to use.
I've worked on teams where I just threw info into a card, and it was acceptable to use, and I've worked on teams where commits had to have a JIRA tag associated or the commit got rejected, including in instances where bitbucket was timing out it's call to JIRA. In the latter cases, I prayed for Atlassian's swift destruction, but alas, was never answered.
So like a lot of tools, it's how you use it, mostly. That said, as far as universal problems, cloning cards has to be one of the worst UX experiences I run into on the job with any frequency that I can't just fix myself. If the web app needs to await a successful or failed clone of a record (or series of them), I'm not sure why they can't implement a modal or a spinner or other component to tell the user that something is happening, then either navigate the user to the new card, or ask the user if they would like to view the new card. Shooting off a process that you say could take an indeterminate amount of time then dropping eventually a completion notification and link in the bottom left panel is just about the least helpful way to communicate that information.
edit: unrelated meta comment, but it's funny as hell to me that this question got 4 replies in the few minutes it took me to write this reply, all within 10 minutes of the original. People are really out here just waiting for a chance to complain about JIRA. Myself included it seems. Makes me feel a bit bad, hate to pile on to popular sentiment when others have already commented in a similar direction.
I'm trying to cleanup a Git tree right now where people haven't put JIRA tags in their commit comments, it is impossible to find out why a change was made, it isn't a totally stupid requirement.
"It's impossible to find out why a change was made" is a completely separate issue. Either the code is documented or it's not, completely polluting your history with JIRA tags isn't the answer - not least of all because like a sibling commenter said you're now forever tied to JIRA, or if you ever move off of JIRA, now get to choose between bringing JIRA tag information into the new ticketing system, or rewriting your entire git history again.
It's definitely a concern to rely on the ticket system, but the commit message and the comment can't (and shouldn't) contain every bit of info about a change.
Commit message: "Improved clarity and detail in error message"
Ok, that's obvious what's happening, and as a standalone change that's absolutely fine. But the question it doesn't answer is why did someone actually put that effort in?
If the commit message mentions a ticket, then you can go look that up, and now you can find out, for example: it was a ticket that was an unknown bug being experienced by one specific customer, and so the error message was being improved as part of tracking down the bug. You also see who the customer was, internally who reported/escalated it, how long this has been an issue for, and if the bug was found and eventually fixed or not.
I'd argue absolutely none of that belongs in comments in the code, and it's way too onerous for a dev to constantly put that level of detail into every commit message. It's a balance: it's only useful to lookup that info on a small fraction of commits; it takes a lot of time to figure it out when missing (especially if it was many months ago); and putting a ticket number in each commit message is very low effort.
The project has just moved to JIRA from Bugzilla. The original convention was to put the Bugzilla issue ID in commit comments, these IDs were carried forward when moving to JIRA so people can still search for them.
You can have both. Also, let's not pretend developers are wholly committed to writing comprehensive commit messages. A ticket number is useful if the change was relatively recent. If the organization moves to a different tool, chances are they are well aware of the potential history they are leaving behind.
and... I've never yet been in a team/project where being able to track/view/find issue/code pairings from years ago was ever remotely useful or helpful. If it was something in the last few months, sometimes people could dig in and try to understand a bit more by asking relevant people.
Finding a 'bug' introduced by someone from 4 years ago who doesn't work there any more, then finding the particular ticket that spawned it... this has never been high on the priority list of anyone I've ever worked with.
As an architect working on maintenance & refactoring, I find regular value in being able to understand the context (issue tracker ticket) in which a commit was made.
Also more than mildly useful for devs doing porting work.
Commit comments are rarely substantive enough, and "asking relevant people" is nice but not an actual substitute for keeping meaningful records.
I can recall multiple times I've determined why the current logic in the code should be not simplified as part of refactoring or fixing a bug after tracking down the original ticket associated with a commit. That original ticket is quite often a bug report, and sure enough, there was actually a good explanation for why the code is written the way it is, which is almost never going to be captured in commit or inline comments. While having an associated unit test is arguably a better way to capture the reason for such code changes, there are many reasons that's far less likely to exist than a JIRA ticket or equivalent.
So people put the ticket number in the message and then don't write a useful commit message. Congratulations, you just added one roundtrip per commit to the slowest website in existence to every single time you want to look at git history.
Did I mention that you can't look at JIRA from a mobile phone?
This assumes that writing a ticket causes people to explain their rationale better than a commit comment does. That might be the case, but it often isn't because tickets are filed by developers themselves, or by PMs who just write tickets like: "A system requirement is that users be able to do X" without further explanation.
Bullshit.
"Fix performance issue in listing page for customer support".
Which customer?
Is it the same issue as the one this other customer is reporting?
How does the support person know the fix has been released?
Unless you are expecting devs to copy paste a tonne of info into commit messages, it's way easier to just put the god damn ticket number in the commit title.
If you really need to commit something with no ticket, just have a dummy ticket placeholder like DEV-0000.
99/100 it's just laziness on the devs part... It's way easier to add a ticket number than write super detailed commit messages, and every case of missing Jira numbers of seen, there has never been a detailed commit message in its place... /Rant over
> Unless you are expecting devs to copy paste a tonne of info into commit messages, it's way easier to just put the god damn ticket number in the commit title.
Yes, that's what devs should do. Or link to an issue from the git provider. Commit messages shouldn't contain customer information, they should contain fine grained information why the change fixes a particular issue and other technical minutae.
What you doing here is conflating business information and technical information. Business knowledge has no reason to be in commit messages. The code base should be 100% understandable without specific knowledge about what customer wanted what. It would be a huge red flag for me to see those things talked about in the context of the commit messages as a regular thing.
I hate to break it to you, but code is usually written in support of a business objective and does not exist in a vacuum of technological purity... I say this as someone who's written everything from x86asm to python and everything in between for decades. If it really upsets your sensibilities to insert a reference to that business objective in a commit message then I don't know what to tell you...
A business objective is generally translatable to a use case, user story or requirement that can be understood without knowing "Mr. Smith from Company Thingamajig struggles to do x and is willing to pay sums of money to have it fixed". Your developers absolutely should NOT be knowing or dealing with business objectives.
As always there can be exceptions but if this is normal operating procedure for your company I would run far and fast.
> If you really need to commit something with no ticket
I'm of the opinion the only time this should ever happen is if it's a critical fix to allow ci builds to succeed. E.g. unit tests with hard-coded assumptions about the external world (current date etc.) that stop being true. Or errors in pipeline scripts that occur due to changes in a build agent.
The best thing about cross-linking between Git and an issue tracker is that when you have multiple commits for one ticket (very common), they can all link back to one ticket. Having the extra context from discussion is useful, but obviously that can be summarised in the commit message. So being able to instantly get a list of commits that link to the one ticket is the really invaluable feature that I don’t know of any good way of doing another way.
I'm a big fan of this personally, but I've also lived with the experience of completely useless commit messages, so I understand both arguments. Here's the most recent commits for a project I'm working on:
Counts
Counts
Counts
Counts
Log entries
missing package json
missing package json
ttl in seconds
cache back on
Still, I'd rather try to convince people to write useful messages than hard bind my remote code repository to my system for managing work, and often times (but certainly not always), single line commits are self explanatory.
Jira doesn't really work well out of the box. It needs a lot of work to configure. I love Jira now, but it's been hell in the other startups. It's probably why stuff like Trello and Asana took off.
JIRA implementations I've seen don't help people see what's ahead; they focus on what's been done to date. If you're on a single, small team that has minimal dependencies on other teams, that can work, but if the project has any significant dependencies on other teams, it becomes very hard for anyone to understand how things are going.
After my company switched to Teams, my IT department became much more productive because the amount of needless interaction with other people decreased.
And we were not affected by that shit, since we share the same office anyways. Who needs a messenger when you can shout ;)
It's not about the specific technologies a company uses, but rather how that choice gets made.
Teams is chosen in companies where the organization is so big that "unification" is seen as a big plus.
What you're out after, are smaller organizations where choices are made based on what people working with those things actually want to use.
So look for headcount rather than what chat program they use, because the headcount will affect more choices than just what chat program you'll end up having to use.
I've used both. IMHO Teams is by far worse than Slack.
This doesn't mean that Slack is better than anything else, it's just better than Teams. Truth be told, even sending a letter by mail is better than Teams.
My company uses both. That doesn’t improve things much but it does give me a good view of both.
- slack great for
- huddle collaboration
- chat threads
- searching chats
- focused chat layout
- teams great for
- sharing video of eachother
- taking control of screen share (no need to futz with asking someone to stop sharing when they already vocally told you to share, most sharers aren’t trying to steal the screen from you as devs)
- reactions / emojis when you want to react silently
Teams seems to consistently make me think I’m fat fingering things and I have to go back and type again when I open a new message and start typing. I seems like it’s storing something in a buffer then spewing it async out all at once in the wrong order when it catches up with my input. This happens multiple times a day on a 2017 i7 laptop.
Maybe Teams is an Intel make work program? Have it run slow on all but the most expensive new Intel processors?
It's also upsold as part of existing MS sales agreements which is why execs will buy it. Easier and cheaper than negotiating a new enterprise contract with an unrelated company eg Slack
Along the same lines, Googles Chat and Spaces are really close to becoming “good enough” that you don’t need Slack. Their threading setup is awful and they desperately need to let admins set sane defaults for notification sounds, do not disturb hours, etc.
But aside from that it’s really close to being a good enough chat option that Slack doesn’t feel necessary.
Google Meet is already good. Gmail is excellent and the calendaring system is best in class.
They fix the chat UX issues and it’s going to be interesting.
This is a bad answer. It's actually a non-answer. You can apply this to a lot of questions. Why does X ... Y (because X can get away with it).
There are real resources behind Microsoft Teams and a lot of people want it to be good. They may not get much of a signal about how well their product is doing compared to competitors because lock-in effects, but I can guarantee you the product managers and executives at Microsoft want the product to work well.
I understand why this sounds like a bad answer, but it's not half-bad in context.
Microsoft 365 absolutely is something of a buffet for companies/orgs with IT budget constraints and compliance-heavy objectives.
Just more stuff that sort of works and ticks boxes, starting with hosting almost everything in the EU for European customers. Compare that to Google, who flat-out refuses to guarantee EU-only hosting for Workspace customer.
All the bundled extra tools outside e-mail and the absolute core M365 Office apps just sit there, ready to use, easy to package and deploy to clients. All generated user data is stored in the MS environment every stakeholder has signed on to. From OneNote, MS Todo to Teams, everything's integrated without as much as configuring SSO externally.
A lot of what's included, Teams specifically, is shockingly bad. But these elements tick very important boxes. And very few people seem to care about the rest. UX isn't a compliance-mandated requirement.
I sort of know this, as I work at a company that has to punch above its weight in compliance, due to industry specific requirements.
If you need good single-sign-on for Slack, you end up paying the now Salesforce-owned company over USD 10/month, just for Slack. If you want decent data retention controls for Slack, you need their Enterprise Grid plan, the price of which is unlisted, but I've heard it's like USD 25/month/user(!). Just for Slack.
Same with Atlassian. The decent handful of dollars you pay per user only applies if you're ok with shockingly limited controls.
With Microsoft, you get a lot for just buying M365. You can get started building a soundly logged and controlled environment if you put everyone on M365 Business Premium (including desktop apps) and/or F3 licenses (web/mobile apps only) for about 20 and 10 dollars respectively.
Sure, you do pay through the nose for the really good logging capabilities with M365 E5 licensing, something close to USD50 per user/month, which is a lot, but it also includes everything from Defender antivirus, InTune device management, Teams telephony call-in support to a Windows Enterprise client license.
There's so much included with M365 in terms of compliance and bundle value that Microsoft absolutely can leave it absolutely terrible UX condition, so they do.
Because microsoft saw competitors that look scary and so decided they needed an all new project released in a hurry. If they have been willing to spend a few years before release they could have a good product, but instead they rushed things to production.
Lync (later skype for business) worked pretty good, but lacks a lot of features (others have mentioned various chat things before then). If they had invested in that all along they probably could have made a stable teams, but the temptation is to call something done and milk profits out of it until you are behind someone more innovated.
I would assume Microsoft is using teams in house. They should get plenty of feedback - the people writing the software should see most of the issues and have motivation to fix them. The admins are just down the hall and can talk to the developers if there are problems. The executives can talk to the project manager about the priorities they need...
They may not know how it works at my company, but it can't be that different.
> I would assume Microsoft is using teams in house
I wouldn't. But surely there's someone here that actually knows? It does seem hard to believe their own engineers would put up with all the issues it has.
Yup, almost everyone at MS is using Teams internally. When they collaborate externally they use whatever the partner prefers.
For example, there is a Discord server for ReactNative contributors and collaborators with a bunch of MS folks on it.
I guess it's also possible there's a Team for Meta folks to talk to MS directly but I somehow doubt it - or at least, I doubt it gets used very much if it exists :)
Really? With the exception of Office I can't think of a single microsoft product that could ever be considered "good". They have consistently crapped out sub-par products for decades. It would be perplexing if they could actually get any IM software to a good state. This is their 3rd one. They even bought arguably the best one in the world (Skype) in 2009. Which was "coincidentally" the year that Skype usage fell of a cliff.
Have you never used Visual Studio or VS Code? Would you consider C#/.NET or TypeScript to be products?
Having worked with various developer-centric tools across Windows, MacOS and Linux for the last 20 odd years, if I ever felt MS consistently dumped sub-par products on its userbase I'd happily walk away and use alternatives. Teams is one of the few of their products I regularly resent being forced to work with, and would never recommend it if I were in the position to (and yes, Skype for Business would be next on the list).
VS code is another crappy electron app. Why anyone would want to use electron for a text editor is beyond me.
C#/.NET are crap. Especially .NET. And a programming language that is not cross-platfrom is a joke. I know they have made some efforts to get it to work on other OS's but those are just as crappy as all their other stuff.
Nothing wrong with typescript, but I don't really see it as any kind of innovation. It's just JS with some guardrails.
I think usually the argument is that they're leveraging an _existing_ foothold to gain advantage in a _new_ market. So the existing foothold is MS Office and MS Office 360, and the new market is messaging.
How they gained this foothold in desktop productivity software is left as an exercise to the reader.
Hey, thanks! I don't know much about antitrust, so this is likely to be a dumb question;
Why is messaging a new/different market for Microsoft regarding O365? Microsoft has been including business-targeted messaging/collab tools in O365 for years. Skype for Business preceded Slack, let alone Office Communicator or Linc, not to mention Outlook.
the bundled packaging where they give it away for free to get market share is a well documented antitrust practice.
Lookup diapers.com for instance. Amazon sold diapers below cost to gain marketshare, took all customers from diapers.com, those guys went bankrupt, and Amazon upped the prices to higher levels than before.
I am not suggesting breaking up Microsoft and Teams, I am suggesting that giving away Teams for free should not be allowed, it needs to be fairly priced. But Microsoft has good lawyers of course.
Nobody with decision making power actually cares whether any of the software in use in enterprises works well or not.
^this just isn't true. There's three camps of people. 1) The people who use Teams today and think it works just fine, they even enjoy it and find it simple to use (these people exist). 2) The people who use teams but are annoyed by many small issues that together cumulate to a poor UX. 3) People who will never like Teams for many reasons but make a point about being as vocal as possible about their hate.
Decision makers and leaders care about 1 and 2, which imho is good. I do agree that Teams isn't perfect and I also agree that it plays best, for now, with IT ecosystems. That said, end user love is critical and I think fixing that for group 2 will only help to secure Teams' undeniable comp advantage.
The most basic of features, like freezing the screen while switching context in a presentation, is not available. A request for years by all users and available like for ever, in GotoMeeting or Webex.
Do you think that helps Teams or not? I mean, if you can make a shitty product and know that it will sell, why make a good one? If you know you have to make a good product to get sales then that's what you'll do.
Shouldn't there be a level where some people will find the pain of the shittiness so great that they'll step outside of the Microsoft ecosystem whereas other people will accept the shit in exchange for the ease of staying inside the Microsoft ecosystem.
If that's true - and I don't know if it is - it seems like the leg up that Teams gets for being part of Microsoft doesn't help nearly so much as it should. Though truthfully in order to compete with Microsoft's entrenchment you don't just need "not shitty" you need a product that's got something going for it that's weirdly compelling. See Linux on servers or Google Chrome on the desktop.
>Shouldn't there be a level where some people will find the pain of the shittiness so great that they'll step outside of the Microsoft ecosystem whereas other people will accept the shit in exchange for the ease of staying inside the Microsoft ecosystem.
This happened at a company I worked at. There was practically a war between IT support trying desperately to force people to use Teams and the people who had picked up Zoom and quite liked it trying to stay using it.
After a grace period where IT pleaded, whinged and begged, the Windows laptops were ultimately locked down such that zoom couldn't be installed or run at all and everybody was finally shifted on to Teams.
This was all done in the name of security, citing such high profile transgressions "Zoom's end to end encryption isn't working as advertised!" and "omg zoombombing sometimes happens if you don't password protect your room!" were cited. Stories like this were circling the news at that time.
Later on when Teams was bludgeoned by several zero days that were orders of magnitude worse, nobody batted an eye of course, and that story didn't get much airtime.
Microsoft had its claws deep into that company. I suspect they have a pretty good PR team as well.
I recall decades ago picking up a book on J++ as a teenager. I quickly realized the entire point of the language was to sabotage Java. Not to be useful.
Refused to use windows for rest of career after that.
I think its unfair to say the real customers of IT are regulators and auditors. But meeting their requirements is legally mandated. You have to meet that standard. In an imperfect world with deadlines, overhead, and limited resources that's sometimes all you can hope for.
As for Teams being awful. It has problems. But all non native desktop apps do and that includes Slack and Discord. I use both Teams and Discord daily and they are about equal in frustration.
It's illegal to transfer PII to microsoft under GDPR though, so wouldn't it be like setting up a minefield for your employees to consciously choose ms teams for daily communications?
no its not illegal, it just needs a lot of lawyers to workout the details. GDPR does not block a lot of things, it only requires you to work out the proper procedures and paperwork. And that is where Microsoft is good at, the compliance support.
How is is not illegal? The details are basically "PII EU resident data cannot be given to companies falling under legislation of governments not following due process regarding access of PII belonging to those residents" + "The US government regards itself above anything else and does not follow due process when accessing PII of EU citicens stored on premise of companies falling under its legislation" => "EU law does not allow transfer of EU residents PII to US companies". There's no "proper procedures" when it comes to protecting data stored by US companies from the US government.
From what I understand of the Schrems court rulings I think you're right, but the whole EU establishment is continuing to try to ignore the ECJ on this because cutting out US vendors is more disruptive than they want to deal with. From a realpolitik perspective, it's only as illegal as the fines and binding court orders (after exhaustion of appeal rights) will make it.
I also wonder what the Schrems court rulings mean about US citizens working in the EU for EU companies, since the US might feel free to give purportedly binding surveillance orders to such citizens; or for EU residents who visit the US while working for EU companies and receive a binding surveillance order while in the US, possibly even with their work equipment and remote access to company PII.
If cutting out US vendors is disruptive, avoiding travel to and remote work from the US, and avoiding hiring (or being subject to hierarchical oversight from) US citizens in Europe would be even more so.
As a US citizen who is about to move to Europe myself, my preferred solution would of course be for the GDPR to be followed strictly and for the US to change its laws. But I'm really not expecting the US to pass that kind of legislation now.
Or another way to look at it is that the real customers for Teams are IT departments. It makes their lives easier because they don't have to do anything and it meets all the compliance requirements they are supposed to enforce.
Which in turn reflects that the real customers of IT are regulators and auditors. Nobody with decision making power actually cares whether any of the software in use in enterprises works well or not.