"When things are designed by 1 person (IME) they work better and have a more flowing work flow. Designing in a committee has been a freaking nightmare."
I completely agree. Yet in industry, being that one person (like I am) leads to great management consternation to the tune of "what if you're hit by the proverbial bus?" which leads to "you need an understudy", which leads to expending 2x the resources to achieve <2x results (the time spent selecting, training and guiding an understudy is definitely nowhere near 0, even when the choice of understudy turns out to have been a good one), and there can't help but be some feeling of "training your replacement". Industry loves interchangeable parts (people), and a one-man-band (domain expert or similar) grates against that ethos.
I hate the proverbial bus. It seems to assume that central employees should be completely dispensible.
If a key employee, being the architect or even the CEO, is hit by a bus, the company will take a hit. If employees are a central, strategic assets, you can't go around killing them off and expecting no impact on your business. Deal with it.
The important metric is whether the company/project can recover, if it is resilient. Just because one guy drives the decisions, it doesn't mean that the team filling in the details don't know the code and the motivations behind it, and there can't be a guy from that team who could take a promotion, or that the team couldn't be reasonably productive for a while, while a new architect is brought on.
In short, stakeholders should always be concerned with the potential discontinuity of (especially high) performance. But it's rather like technical debt (or any other kind); something that should be managed rather than avoided at all cost.
That's a bad way to think about it. You probably don't want to work on the same project forever anyway, and if you're so smart, teaching other people what you know is the most important thing you should be doing.
The bottleneck on many projects (especially those that are either poorly defined or particularly novel) is not coding speed, but rather learning speed. The faster the team learns about the problem it's really solving, the environment the solution has to live in, the people who will have to use the software, and what the possible solutions are, the faster you're done.
I completely agree. Yet in industry, being that one person (like I am) leads to great management consternation to the tune of "what if you're hit by the proverbial bus?" which leads to "you need an understudy", which leads to expending 2x the resources to achieve <2x results (the time spent selecting, training and guiding an understudy is definitely nowhere near 0, even when the choice of understudy turns out to have been a good one), and there can't help but be some feeling of "training your replacement". Industry loves interchangeable parts (people), and a one-man-band (domain expert or similar) grates against that ethos.