That's overtly harsh take I think. Teams has issues; but asking employees of a company to use said companies tools internally isn't necessarily a bad thing. Hard to improve without dogfooding.
"Between different messaging boards (including the link above) this feature has been requested over 2000 times (1044 times as of this writing on the link above alone). Could Microsoft chime in to let us know if this is going to be on the roadmap? Thanks."
https://answers.microsoft.com/en-us/msteams/forum/all/pausin...
The tool will say you are in the meeting but won't let you have access to the chat. A bug hitting regularly hundreds of persons.
https://techcommunity.microsoft.com/t5/microsoft-teams/why-s...
https://techcommunity.microsoft.com/t5/microsoft-teams/probl...
I pity GitHub employees and would consider resigning :-)
It's a slow buggy resource hog that crashes frequently.
Features keep getting added but until they address the fundamentals, all they're doing is polishing a turd.
Have you tried the web version of Teams? It’s not ideal, but I have found it to be more stable than the desktop version.
Is the GitHub team working on Teams now? I doubt it.
I don't care at all about Teams. GitHub, on the other hand, is the host of many important projects. I would much rather the GitHub team be left alone to do their jobs.
(It doesn't have to be perfect, or course, just do something better than its competitors to be attractive to use. I struggle to think of a single redeeming feature of Teams.)
I don’t know if I’m misunderstanding how you’ve put this, but I’ve only ever understood dogfooding to mean that you use your own product to find the bugs, improve the workflow, and encourage feature suggestions.
Dog-fooding is not a reward for making the best product (though that makes life easier at work), it’s a commitment to improving your own product, and showing that you are willing to live with your own product in order to make it better for your customers.
So yes, dogfooding is there to get immediate feedback on technical flaws of an otherwise desirable product. Dogfooding is not there to fix a product--market mismatch. That needs to happen at a different level of development.
I've only ever understood dogfooding to mean this as well, but I like GP's point. If you're forcing yourself to use the product to find bugs instead of using the product because it's a great product, then you have problems.
You wouldn't want to eat dog food that wasn't prepared in sanitary conditions, so if you worked at a dog food plant and knew you'd be eating something that closed through that dirty grate, you'd clean it. You wouldn't want a program on your PC that regularly consumes an entire core while idle or that crashes when active, so you'd fix those issues if it was your software.
People naturally want to fix problems that affect them and add features that would improve their daily use of a product. At a small company or startup, where people can do this, you should use your own products as much as possible.
But if you are a Microsoft/GitHub employee with no access to the Teams code, not even access to a human being who works on Teams, there's no point. Use whatever meeting software lets you do your job best.
I am all for dogfooding here, but if the dog-fooding is not improving the product it shows that the goal is to eat market because of lopsided ecosystem monopoly. Screw MS and MS Teams.
eg. : We need a tag in a shared channel so that we can provide single point of support for other teams, instead of people having to tag the whole channel. Slack made is as easy as breeze to sync on-call person from PD -> a group.
$35k... that's... under $500k/year in licensing they're paying? Will they take more than a $500k hit in productivity?
By HN standards, $500k isn't even the loaded cost of one intern these days in SV, but... even in the 'normal' western business world... $500k/year is likely the cost of 2-3 engineering staff. Trying to eke that much savings in the short term seems short sighted.
My comment was reaction to the fact that there is a forced migration without 1:1 parity in feature set. Most large orgs/teams in my experience heavily rely on automation that has been added over the period of time reduce the cognitive load that is accidental/side-effect. Now if you are going to force them to move; give them a migration path.
Think of this in terms of API contracts. If half of the methods in your new version are not even available; why even make the new API public?
They've been dogfooding and I don't think most of us regular users have seen any measurable improvement for years. Apparently it's hard to improve with dogfooding too?
Azure: yes, all the major cloud providers should migrate all of their use to their cloud. If their cloud doesn't support something that's a problem for their users and they need to fix it ASAP.
O365: Same thing.
VSCode: Developer tools such as IDEs shouldn't be mandated (and weren't when I worked at MS) but if one is mandated it absolutely should be their version unless there's a strong technical reason otherwise (for instance, if they were using Java there are better choices).
Windows: Again, most good shops don't mandate what your desktop environment is
Mandating a single communication platform is absolutely the right move. And the fact that MS picked Teams as that single communication platform is beyond obvious. What else could they have chosen?
Is it, even if there will be productivity losses? Is making your teams less productive "absolutely the right move"?
From an outsider's perspective of MS and Github, I think it's the right move.
Issues like unable to switch teams without re-authenticating? Slack can do this, Discord can do this, both of them completely seamlessly but Teams just can't.