I think their point was that architectural decisions shouldn't be dictated by any one single engineer.
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.
https://en.wikipedia.org/wiki/Gish_gallop
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.
"The cure for this in the software simple and difficult"
"The cure for this, both in software development and
elsewhere, is both simple and difficult"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.
If there's someone with a proven track record of making sound decisions at the required level, often the team benefits from just following their lead.
Obviously, this can't be another case of the 4x engineer making everyone else 0.4x engineers. Fairly situational indeed.
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!
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.
1) Lack of focus - everyone had their own annoying part of the system they wanted to fix badly and were not aware much about what going on elsewhere.
2) Our group of ~10 people would cost 10x of senior salaries to the company to do such architecture work. No manager would ever authorize that.
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.
A group of 10 seems too large and counterproductive. I think a group of roughly 3 seems about right.