I posted in that slack thread. I’ll post here too.
A while back, I joined a company who’s plan was that everything new was going to be Elm, and my team was beginning an important new Elm project for the company. The company had three teams of 6 developers, and each team had 3 frontend devs. Eventually, by time 50% of the front end code was in Elm, the company made the decision that Elm was cancelled, and nothing new would be made in Elm. It was around that time that I quit, which coincided with a lot of other people quitting (for various reasons not related to Elm).
During my time there, I took an Elm project from nothing to completion in about 7 months. And I am very happy to say it is still maintained and in production! Thousands of people are still using it every day. Even though the company gave up on Elm, it seems Elm did not give up on the company 
.
Here are some details about the company dropping Elm.
A lot of our Elm developers didnt want to be Elm developers in the first place.
I joined the company to write Elm. A few others were really excited about Elm. But many didnt even know what Elm was when they were told their projects were to be written in Elm. Developers reacted in different ways. One quit, thinking that Elm was a big waste of time in his career. Lots of developers tried it out with at least some hating it, but most being ambivalent. I think “Its nice, but I am faster in React” was a common conclusion among those who were indifferent. The breakdown was roughly 35% Elm-lovers, 50% neutral, 15% Elm-haters.
Lesson Learned
These kinds of technical decisions need to be made “ground-up”. The odds that any random programmer is going to be excited about Elm after learning about it are low (which is the case for any technology) and programmers are more affected by these technical decisions than anyone else- even customers. So programmers are the stakeholder that is the most relevant to these decisions. If you want to become an “Elm company” you first need a lot of developers and teams who are interested in Elm. If you dont have that first step out of the way then you really just cant become an “Elm Company” without making a huge gamble that many people wont share your enthusiasm and thereafter dislike their job. Elm is not so amazingly good that you can just count on everyone loving it when they get exposed to it.
I was not allowed to help Elm newcomers
Since we had a lot of people who didnt know Elm very well, and I often felt like “the Elm guy”. I spent a lot of time reviewing PRs and coming over to people’s desks to help them out. At some point, management made a judgement that teams were not closely integrated enough. They felt that there was too much communication between frontend people on different teams, and not enough communication between frontend and backend people on the same team. Therefore, people like me were supposed to stop helping frontend people on different teams as I was.
The consequence of this, I think, was there there were some teams that had no Elm expertise, only mild Elm enthusiasm, and no in-house Elm support; and they were nonetheless supposed to be writing projects in Elm. Not very promising conditions.
Lesson Learned
Within companies, there develop natural communication networks. Some coworkers communicate with each other every day, others never communicate. My company reasoned “we need communication to follow the existing teams, therefore, we will mandate that that exact communication pattern”, but it really doesnt work like that. I think how people self-organize is a little bit more like an immutable law of the universe and less like a thing that can be dictated into existence. In practice, people communicate with who they need to communicate with; issues with shyness or confrontation aside. Management is also not omniscient; they dont fully understand the communication patterns inside their company. Therefore, management should be a little bit “laissez-faire” about teams: observe who communicates with who, and then draw team-boundaries around those natural communication clusters.
Elm arguments got really really tiresome
The road of project development is bumpy, and Elm was a younger language back then with more open questions about how this or that problem should be solved. In our company, there were always at least a few people who really didnt like Elm, and whenever we hit a snag, there was always someone to say something like “In React this is just…”, spawning a new discussion about whether Elm was fundamentally good or bad. I love these discussions and arguments recreationally in my own time, but on the job its a real drag. Development stops when fundamental arguments about technology are opened up. It got worse and worse over time. Difficulties with upgrading to the then-upcoming 0.19 release added fuel on that fire. Our CTO “switched sides” and lost his love for Elm, and kind of became an agitator himself in these arguments. I remember feeling like “I wish I could have spent this time solving the problem, rather than defending Elm in an argument. I could have just solved the problem, regardless to if they are ultimately right that its easier in React”.
Lesson Learned
You really should keep your eye on the prize at work: getting projects done. Your company has to pick which technology to use, and you have some choice in what kinds of companies you want to work at, but outside of that, if you just wanted to get projects done, why would you be wondering which technology to pick?
I have adopted a few morals about how to get past tech disagreements. One is “code is worth a thousand words”. If you have a tech disagreement, one or both sides of the disagreement should go off for a day and write up the best demonstration of their opinion so everyone can see it shine. Another is “let people be wrong”; just letting an opinion play out naturally is often the most cost-efficient way of getting better opinions. Putting an opinion into practice creates the best evidence that that opinion is good and the quality of this evidence is often so good that it is worth the risk of having to refactor or re-do the code later. If you trust your coworkers, you should expect them to learn from good quality evidence in a positive direction.