We fired our top talent. Best decision we ever made.
Jonathan Solórzano-Hamilton

This story rings so many alarm bells for me, it’s crazy. Three salient points:

Rick’s product supported a dynamic workflow with over fifteen thousand permutations. In reality 99% of our use cases followed one of three paths. The team hard-coded the workflow. This removed over 30% of Rick’s work.

Why are you calling it Rick’s product? It’s your company product. Who is negotiating with customers to arrive at a minimal viable solution? Who is analysing customer needs and writing functional specification? Very few developers know how to do that.

Your solution was to release a small and simple product, and then build up form there—why wasn’t that the Plan A to begin with?

He created a cult of dependence. Any problem eventually became a Rick problem, a myth he encouraged. Developers learned to stop trying and just wait for Rick.

I cannot understand this—they are supposed to be trained professionals, not hamsters. What were the other developers doing for two years? Are they kids straight out of university? They were working on something, right? Was there no separation of concerns — I.e. the “genius’ works on the server and ‘mere mortals’ can work on the front end?

Second, he didn’t write maintainable code. He never documented or tested anything, and so failed in spite of his own intelligence.
Some of it was very clever, a lot of it was copy-pasta, it was all very idiosyncratic, and it was not at all documented.

This seems absurd — what made you / your team believe that he was a great developer? Code written by a good developer is not suppose to be hard to understand. Microsoft guys write perfectly comprehensible code.

Was Rick a terrible teammate? Maybe. I cannot possibly know. But the question I have reading in my head, the entire time I am reading the article:
What the hell was everyone else doing while this was happening?