Hacker News Reader

Comment by apnew | Hacker News Reader

Literally sitting here right now trying to figure out how to get simple things going compared to slack after being forced to move to teams from slack (not GitHub).

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.

View on HN

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?

So you save about 1 employee cost per year, and make the other thousands miserable and less productive? Definition of penny wise, pound foolish.

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.

Long term, it will likely result in the improvement of Teams due to dog fooding. It may not be instant, but it will happen.

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?

Reply on news.ycombinator.com