How could we avoid this? The article says it should be the one who is better at self criticism. But how do we unbiasedely pick this person? You imply non-commercial development is different. How so?
Let me give an example of LSMB's newer architecture which is still being refined.
One member says "Hey, we should use stored procedures and here's why." I say "No, we shouldn't and here's why." We argue back and forth. We end up using stored procedures in a way that avoids my objection. We both win.
One member says "Hey, we should ditch LaTeX for Docbook XML." I say "No we shouldn't because then I have to spend time I could be spending programming learning a new toolchain and documentation master format." He says "No worries. I am sure someone else can maintain the docs." I say "Great." But nobody does so we stick with LaTeX.
The goal outright has to be to ensure that everyone's legitimate objections are met to the extent possible....
A better approach would be for the architect to make the first proposal. "Here's what I am thinking. Any objections? Any criticism?" And then fire off a discussion as to what the shortcomings of the approach are. These can then be the subject of a second iteration or where the architect really is wrong he can go back to the drawing board. Ideally this is done before going to upper level management.
The only problem here is that opening up your ideas to such criticism takes a sense of security and confidence that is lacking in most management types in corporate America today. People's whose primary skills include playing politics don't tend to be confident standing on their own...
Now, here's an example. In LSMB we added the ability to store files as attachments to transactions. I sent off a proposal and a few people liked it and one person really didn't. He talked a bit about how to detect and reduce file duplication in the database. There were some low-level I/O problems with his proposals, but he had other substantive objections which were correct. So we went back and forth on this a while and the end result was that I came back a week later with a new proposal taking a lot of that into account.
Picking great leaders? That's a tough one. An easier question is to ask "What prompts a Lead 'Hat' stick with an idea though it doesn't seem to be the 'best' idea?"
Developers/designers using OP's two-way criticism style are really removing their own egos and emotions from the discussion and letting ideas honestly fight for themselves. I suspect that the Lead "Hat" is a conduit between developers/designers and executives and it's naturally difficult to convey, let alone objectively discuss corporate objectives in a development/design meeting.
The takeaway for Lead Hat lurkers on HN would be to (unfortunately) expose developers/designers to a wider scope of the project when the ideas are fighting, so they can understand where you're coming from.
Productive self-criticism is a hard thing to select for. It shouldn't be that hard to determine if someone has really thought through the ramifications of their own product design, but it can be much harder to determine if they've really thought through someone else's. Organizing people across teams any larger than a few people is a also hard problem, one for which I unfortunately don't have a ready solution. In small teams, this kind of thing is much easier to spot and, hopefully, correct.
One way would be to do some prototype and demo your idea.
At the same time it is no guarantee that this would work all the time. It depends on factors like how cohesive the team is, whether there is openness to listen to conflicting thoughts, ideas etc. Otherwise your prototype might get as well shot down with some specious argument.
