You typically need to convince multiple people & roles if you want to introduce new tech. People have already covered pitching to colleagues and engineers. New shiny is often (and rightly) seen as risky, unproven, hard to debug, changing fast, hard to get relevant skilled staff. What about the rest?
The thing that I see with erlang & elixir that is IMO the key feature is that they are platforms for building robust, reliable systems. This means -:
- systems that handle failure tolerantly and gracefully under extreme load or unexpected conditions. - easy to debug live in production without the need to recompile, or introduce complicated extra tools to do so
- systems that recover mostly automatically (when appropriate consideration is given during design) and that do not require manual intervention out of hours to keep operating
These are prized features that are core to the BEAM that are very hard, if not impossible, to retro-fit to other systems. I do not think that a couple of months is sufficient for a ruby or java developer to become proficient enough to design this sort of system, but they can easily start shipping modules and non-distributed systems code effectively. This needs to be kept in mind - robust reliable systems require a fundamental practical understanding of real world distributed systems.
In my experience of large systems software the above attributes are killer features both at scale and in production. See how your management feels about these, and you may find introducing OTP is a lot less complicated than you think.
BTW I highly recommend Francesco Cesarini & Steve Vinoski’s book https://www.amazon.de/Designing-Scalability-Erlang-OTP-Fault-Tolerant-ebook/dp/B01FRIM8OK its not lightweight but it is essential reading, and you should be able to find one of Francesco’s recent talks that gives a good overview of this, a great introduction for your more technically minded managers.