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.
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.
https://feedbackportal.microsoft.com/feedback/idea/c9995dc8-...
I've bookmarked that page and I check in on it regularly, as Microsoft claims multi-account support is due for late 2022.
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).
Yeah well somehow that got silenced real quick. Microsoft is evil under the surface, with extreme close ties to governments, regulators, ...
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).
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.
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'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.
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.
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.
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.
Did I mention that you can't look at JIRA from a mobile phone?
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
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.
As always there can be exceptions but if this is normal operating procedure for your company I would run far and fast.
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.
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.
See https://www.atlassian.com/migration/assess/compare-cloud-dat...
You better start scheduling your migration.
Same as any other product in the world.
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 ;)
> And Teams performs by far the worst at that 90%.
is exactly the reason for:
> the amount of needless interaction with other people decreased.
Simply put: nobody wants to touch teams, so they only do this when absolutely necessary (and even then chances are they will just send an email).
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.
But sometimes specific products are simply less than ideal no matter how they're used. I consider Teams to be one of those.
I would rather just go back to IRC.
This model is not by any means entirely accurate but it's been an extremely effective heuristic.
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.
- 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
Maybe Teams is an Intel make work program? Have it run slow on all but the most expensive new Intel processors?
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.
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.
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.
> executives at Microsoft want the product to work well.
IMO, everyone wants the product to work well (except probably competitors).
So why doesn't it?
I'm aware this is not an answer either :-)
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.
They may not know how it works at my company, but it can't be that different.
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.
Edit: the only evidence I could find you're right was at https://www.microsoft.com/insidetrack/blog/new-microsoft-tea.... But whether it's the primary tool their devs use for communication I don't know.
Really? So they have to know how awful it is. That makes its continued awfulness even more perplexing.
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.
MS cannot even work out there messenger strategy properly. We have/had MSN messenger, Skype, Skype for business, Lync and now Teams.
What makes you think the execs in MS really care about messaging?
It'd be similarly difficult to argue they're acting anti-competitively when Slack is thriving.
How they gained this foothold in desktop productivity software is left as an exercise to the reader.
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.
Is Slack profitable?
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.
^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.
Enterprise sales calls these days.
Lots of rules.
https://answers.microsoft.com/en-us/msteams/forum/all/freeze...
https://answers.microsoft.com/en-us/msteams/forum/all/pausin...
https://techcommunity.microsoft.com/t5/tech-community-ideas/...
Thinking about it, what offers from Microsoft are not used just because somebody must use it...Or their company got it for free?
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.
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.
Refused to use windows for rest of career after that.
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.
There are a bunch of regulations these days. GDPR is just one of them. A lot of tools are just not compliant.
IT departments have to take those into account. Especially at public companies.
Microsoft does a good job at that and tends to make it easy for the IT departments, too
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.