Brilliant post. Most of these points hit home for me. One of the things I've been honing in on recently - which you do as well - is effectiveness. Brilliant developers who don't ship aren't effective. People who don't distill a product down to just what's necessary aren't effective. You hit on this concept - and many others - in a number of spots. Thanks for sharing.
I've always referred to this as "realized output". The brilliant engineer might have capacity for greater realized output, but there is little value in the potential. After a certain point, the output must be realized.
This is closely related to the "Raw Technology Persona"[1]
A developer who can talk you through an entire stack and why specific tradeoffs were made on specific pieces of the architecture... yet hoards code on their box without committing, works on stuff without telling other people, and claims that things are progressed much further than they actually are. It's an ego and accountability problem.
Someone like this might prefer to refactor your entire stack multiple times, partly due to shiny-new-framework, and partly due to the lack of understanding that from a business perspective you often have to work with what you've got. I think it's less about perfectionism and more about inexperience with balancing business tradeoffs with technology.
There's a great series in Forbes specific to CTOs undergoing this "meltdown" [2]. In it, they mention a few warning signs including: never saying no, missing deadlines, low morale, and poor estimation of timelines.
Perhaps someone who is brilliant but perfectionist and not interested or capable of doing the work to glue/shim a canonical example into a working product.
Some folks are good at the former, others are good at the latter. The really good ones are comfortable with both.
True, and this is one of the harder lessons to act on. Brilliance in = brilliance out, right? At the most basic level shipping product can be the difference between fail-pivot-success and fail.
