Jane Street's been doing this for most of their existence. I interned there a decade ago when they had 300 people and maybe 100 engineers and they had already b

Jane Street's been doing this for most of their existence. I interned there a decade ago when they had 300 people and maybe 100 engineers and they had already built up an impressive internal infrastructure—including lots of in-house tools (eg a code review system) that were custom because they got value from building them in-house, not because of OCaml. At that point, they had been on this trajectory for a decade already, certainly well before they had a massive team of developers. I forget the exact details, but they started using OCaml in the early 2000s when the entire company had a single-digit or maybe low-double-digit employee count. Building internal tools, libraries and expertise was clearly a massive net gain in productivity for them—it did not "take away from feature development" in anything but the most superficial and short-sighted accounting. Most recently I worked at Target and the contrast was pretty extreme: on a lot of fronts, Jane Street had better in-house systems than Target had with thousands of tech employees pushed to use mainstream technologies and existing open source systems. It's obviously not a 1:1 comparison, but seeing how productive a relatively small organization like Jane Street could be despite (or, really, thanks to) building a ton of things in house really got me to question the traditional wisdom here. Of course, everything you've said is a real obstacle when that's how managers or other teams think, regardless of whether it's accurate! Dealing with perception and legibility is definitely one of the difficulties in trying to have a Haskell team in a big company. "Nobody got fired for IBM" isn't so much a cute aphorism as corporate gospel—even if they probably should have been.