Not sure about that. Too many chefs spoil the broth. And in most cases, if this one single engineer has the proven track record, I'd give his opinions and decisions slightly higher weightage but at the same time, dictate that he run through his decision making process with the rest of the team. Think of it as forcing him to communicate/knowledge share so that the rest of the team can keep up, learn or simply be convinced. Otherwise, the session serves as a Q&A for the rest of the engineers to shoot. It makes this 'rockstar' a more wholesome engineer in the end, whether he buys it or not. Communicating well is more difficult than perceived, and it's definitely a critical competency to master if you want to really call yourself a rockstar/10x techie.
Yes, this is how it should work. Assuming your 1x engineers are smart, competent engineers with relevant real world experience under their belts (and are not recent code school grads)... they should have a great deal of input into architecture decisions. They should never have architecture level stuff thrust upon them. Too many cooks spoil the broth indeed but nobody should be doing this stuff in isolation and dictating it unless perhaps you’re doing truly bleeding edge shit and your 10x engineer is a true, Carmackian generational talent.
However.
Howwwwwever....
The ILLUSION of democratic (or at least collegial) meritocracy is how our faux-10x engineer pulled the wool over folks’ eyes. He gave the appearance of soliciting feedback. We had internal RFCs and everything. But in the end though he really did just push his ideas through unmolested, because he had management's blessing to do so.
Not sure how much was an intentional masquerade on his part. I think he really did think it was a meritocracy and his ideas were simply the best. It is certainly not unheard-of for folks to fail to recognize their own privilege. Whatever the case, management enabled it. He was not an awful guy in general, and I rather liked him, just not as architect-dictator.
One of his favorite tactics was to spend weeks or months coming up with something in isolation. If you raised objections he’d brush them off by demanding to know your alternative. Which was horseshit - how could you have a viable alternative when he’d had weeks to come up with his idea and you’d only had 10 seconds, especially when these "ideas" are his fulltime responsibility and your responsibility is to ship 40 or 50 hours' worth of software a week. And past experiences had taught you resistance was futile anyway, so why pour your heart into a doomed battle in this latest bit of asymmetrical warfare?
This tactic played well to management though. He looked like the brilliant idea guy and you looked like the negative Nancy. This is a very common bit of political and rhetorical warfare and you see it everywhere.
It is, essentially, a tactic that has much in common with the dreaded "Gish gallop" - you fling stuff at your opponent faster than they could possibly refute it.
The cure for this in the software simple and difficult. Managers "simply" need to be aware of this possibility. However, they also need a certain level of technical chops IMO. If they're too far removed "from the trenches" they can't accurately judge the situation.
I hate to be in your predicament. Software dev mixed with workplace politics is such a mess. Coupled with non-technical upper management that can be easily manipulated. I don't think the cure is simple and difficult, there probably isn't a silver bullet.
Luckily, I'm out of that predicament. It was actually really hard to see it for what it was when I was in it. That environment had all the trappings of a healthy engineering culture, and sometimes it truly was healthy, but only in hindsight have I realized some of the ways in which it was deeply screwed up.
What helped was talking with former coworkers, and going to work someplace that is actually healthy. It's not totally unlike finding yourself in a healthy relationship again after being in an unhealthy one.
I used the word "democracy" myself, but I probably should have used a different word.
I would agree that it certainly shouldn't be a "one person, one vote" style democracy that makes everybody exactly equal regardless of talent, dedication, experience, domain knowledge, etc!
There should be a single vision for how the software works.
This does not mean that vision should come from a single person. Ideally, it comes from the people who are able to contribute and critique that vision (other senior developers), with the acknowledgment of the people who don't have the information to contribute or critique (the junior coder).
This harkens back to the MMM and Mills's proposal.
> The surgeon. Mills calls him a chief programmer. He personally defines the functional and performance specifications, designs the program, codes it, tests it, and writes its documentation.
> The copilot. He is the alter ego of the surgeon, able to do any part of the job, but is less experienced. His main function is to share in the design as a thinker, discussant, and evaluator. The surgeon tries ideas on him, but is not bound by his advice.
> The success of the scaling-up process depends upon the fact that the conceptual integrity of each piece has been radically improved—that the number of minds determining the design has been divided by seven. So it is possible to put 200 people on a problem and face the problem of coordinating only 20 minds, those of the surgeons.
Chapter 4 is all about conceptual integrity of a project.
> Conceptual integrity in turn dictates that the design must proceed from one mind, or from a very small number of agreeing resonant minds.
I worked at one company which did design reviews for major projects where one person would present and everyone would pick at it until some semblance of a decent consensus was reached and then said designer would go off and build their stuff.
That worked pretty well and kept each review fairly focused.
And it was generally one of my favorite parts of the day from either end.
It’s really nice to be able to sit with a group of engineers, hear each other’s thoughts, find things you missed, and get away from the laptops for a bit to thing about new systems.
The Brooks model is to have a "surgeon", who calls the shots and owns everything about the development and process and tooling around it, with a support structure that assists and reduces risk, as he outlined in The Mythical Man-Month.