I exaggerated to make a point. Of course you'd work with folks. Apologies for the hyperbole.
You have a good point, but consider this: the team is in the hook for whatever the code is anyway, whether there are disagreements or not. So the real question is whether or not you surface those disagreements (or bury them, in your example), or simply don't address them at all.
I'm thinking you surface them, even if the herd mentality moves in the wrong direction. Unfortunately, unless you can deliver the entire thing on your own, social skills count as much as technical skills. The bigger the team and the more people think "that's not my job", the more the team norming becomes more important than the implementation details.
Or -- to continue with the hyperbole -- if you get it wrong, and you all get it wrong? You did your best. If you do a great job and the team flops? The guy paying the bill isn't going to be so happy with "Yeah, but if they had only listened to me...." Your job is to make the team/project succeed, not be the best coder.
Mobbing is still in the hype cycle. I remain wary, but cautiously enthusiastic. It'll probably be another 2-3 years before all the warts come out.
Hey no worries, your perspective (as a breathing human who's actually done this before, whereas I'm very much being a couch referee or whatever that phrase is) is really interesting.
I think it's a cool idea. I'd still worry about people taking over, coasting, checking out or otherwise not getting to express themselves, but realistically that's a constant concern anyway, regardless of whichever development structure you take.
But I'd try it. I'd be exhausted, frustrated and very much in need of a drink after the first day, but that says more about me than it does the approach :-)
So the really cool question is this: if mobbing can bring a room full of BAs, testers, biz folks, and designers up to speed on the technical details of implementation (which it can), how far does that go? Could you take, say, two really good developers and five smart and enthusiastic people from the street and end up with a good team?
You have a good point, but consider this: the team is in the hook for whatever the code is anyway, whether there are disagreements or not. So the real question is whether or not you surface those disagreements (or bury them, in your example), or simply don't address them at all.
I'm thinking you surface them, even if the herd mentality moves in the wrong direction. Unfortunately, unless you can deliver the entire thing on your own, social skills count as much as technical skills. The bigger the team and the more people think "that's not my job", the more the team norming becomes more important than the implementation details.
Or -- to continue with the hyperbole -- if you get it wrong, and you all get it wrong? You did your best. If you do a great job and the team flops? The guy paying the bill isn't going to be so happy with "Yeah, but if they had only listened to me...." Your job is to make the team/project succeed, not be the best coder.
Mobbing is still in the hype cycle. I remain wary, but cautiously enthusiastic. It'll probably be another 2-3 years before all the warts come out.