News for hackers. Stuff that matters.
Re:GitHub staff are required to use Teams by Sep 1, 2023 by treesknees on Monday February 13, 2023 @01:45PM (#34778145)
From the quote it appears the goal is to save money. From the numbers I found, GitHub could be paying upwards of $35k/month in licensing for Slack users. In a climate where companies are trying to shed expenses, wouldn't it make sense to bring that expense in-house?
Re:GitHub staff are required to use Teams by Sep 1, 2023 by mgkimsal on Monday February 13, 2023 @01:52PM (#34778269)
To people only focused on short term dollars, perhaps. But what impact will it have? Certainly an impact on productivity in short term, perhaps longer? Are there equivalent replacements for all the slack hooks people have in place now? How long will it take to become 'just as' productive in Teams? 1 month? 3 months?

$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.

Re:GitHub staff are required to use Teams by Sep 1, 2023 by chaostheory on Monday February 13, 2023 @06:03PM (#34782227)
Long term, it will likely result in the improvement of Teams due to dog fooding. It may not be instant, but it will happen.
Re:GitHub staff are required to use Teams by Sep 1, 2023 by TylerE on Monday February 13, 2023 @01:53PM (#34778275)
So you save about 1 employee cost per year, and make the other thousands miserable and less productive? Definition of penny wise, pound foolish.
Re:GitHub staff are required to use Teams by Sep 1, 2023 by apnew on Monday February 13, 2023 @03:07PM (#34779559)
I 100% agree with you about bringing that experience in-house.

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?