The Architect’s Real Job Is to Make the Room Smart

How to harness collective intelligence by design

In May 1968, the USS Scorpion, a US Navy submarine carrying 99 people, was lost in the Atlantic. Acoustic evidence helped narrow the search area, but the Navy was still looking across a large stretch of deep Atlantic water. After months of searching, the Navy still had no precise location for the wreck. Then John Craven, a Navy scientist on the search, tried an unusual way of combining expert judgement. He gathered people who knew submarines, salvage, and the sea, and instead of putting them in a room to argue, he asked each of them, alone, to bet on what had happened. How fast the boat was going. How steep its dive. What failed first. He kept them from hearing each other’s answers, turned the guesses into wagers, and combined them with a piece of probability maths.

Not one of those people knew where the submarine was. The combined estimate pointed to a location that proved remarkably close to the wreck. When a ship sailed to the spot it gave, the wreck lay about 220 yards away, closer than any single expert had guessed. Craven’s gift was not knowing where the submarine was. It was designing how to combine what a scattered group of people knew.

The corporate habit runs the other way. Organisations often assume that bringing capable people together will automatically produce a better decision. But that rarely happens. A room full of smart people becomes a smart room only under conditions that almost nobody sets.

I learned this by getting it wrong early on. Early in my career as a software architect, I treated being right about everything as part of the job. I ran the reviews, set the standards, and reached into decisions that should have stayed with the people closest to the code. I was trying to be the person with every answer. That approach did not scale for me, and I came to see it as a poor model of the architect’s role. When one person tries to hold too much of a system’s knowledge and decision-making, they can become a bottleneck. Over time, I gave developers more ownership of decisions closest to the code. The work got better the less I insisted on trying to control every decision.

Many people will recognise this kind of meeting. The room knew more than the decision that came out of it. Sometimes the most relevant concern is never voiced, while the most confident or senior voice carries the decision. You may leave with the sense that the group could have reached a better answer, without being sure what blocked it.

This is about closing that gap by design, building the conditions that let the knowledge already in the room reach the decision. For enterprise architects that is part of the work, even where it looks more like facilitation and organisational design than technical architecture.

Welcome to The Foresight-Driven Enterprise. A newsletter for chief architects and forward-thinking leaders building what comes next

---

Better decisions when the future is unclear, that's the whole point. As leaders, we know the hardest calls arrive before the facts do. If that's the seat you sit in, this is for you. There's a new piece almost every week. I write about how to think clearly about the futures ahead, and how to create the future, by which I mean building toward the one you want while staying ready for the others that arrive. It's plain language and real methods, the ones I use with the leaders I work with. You get applied foresight and strategy execution, no-nonsense mental models from the field. If you want to think like a futurist, plan like a strategist, and build like an architect, subscribe below.

A group has an intelligence of its own

The research goes beyond the usual ‘wisdom of crowds’ slogan. In 2010, Anita Woolley with colleagues studied 192 small groups. They found evidence of a general collective-intelligence factor, where groups that did well on one kind of task tended to do well on others and average individual intelligence was not the main predictor of a group’s score. What predicts it is how well people read each other, and whether everyone gets a turn instead of a few voices running the room. A later analysis pooled 22 studies involving 1,356 groups and 5,279 individuals. It found the same pattern: collaboration processes were the strongest predictor, ahead of individual skill and group composition.

I have written before that the architect is not the smartest person in the room. The room’s intelligence lives in the interaction, and interaction is something you can design.

The conditions, and how organisations kill them

In The Wisdom of Crowds, James Surowiecki described four conditions associated with wise crowds. First, diversity of opinion, meaning people bring different information, perspectives or interpretations. Second, independence, meaning they form judgements without copying the most influential person in the room. Third, decentralisation, meaning they can draw on local knowledge close to the issue. And aggregation, a credible way to combine individual judgements into one result.

Now watch what many organisations do to each. Hierarchy weakens independence when people anchor on senior views or fear the cost of disagreeing. Silos reduce diversity, because the relevant perspective sits in another function and never reaches the decision. Escalation works against decentralisation, carrying decisions away from the people with the most direct knowledge. And politics distorts aggregation when people share what feels safe rather than what they believe. A company with capable people makes poor decisions when its process suppresses information, diversity or challenge.

Whether people speak up at all turns on psychological safety. Amy Edmondson defines it as a shared belief that the team is safe for interpersonal risk-taking. Research links it to speaking up, to learning behaviour and to team performance. Google’s Project Aristotle identified psychological safety as the most important of five dynamics associated with effective teams, ahead of assembling the most talented or senior people. Often, some of the knowledge needed for a better decision is already in the room.

In an architecture review, one practical test is whether a junior engineer can challenge a proposed design in front of its author. If they can do that constructively, it is a strong sign that the review is functioning well. If they cannot, the review may be functioning more as a ritual of approval than as genuine scrutiny.

The trap of more collaboration

Craven elicited independent judgements before combining them, and that ordering is one reason it worked. Once people see one another’s answers, they converge through social influence or anchoring. People can anchor on an early or confident view, which reduces the diversity of independent judgement. More discussion helps only when it brings evidence, challenge, and genuine information exchange. Purely isolated judgement has the opposite limitation, because people miss useful corrections that emerge through well-structured discussion.

Joaquin Navajas and colleagues reported a relevant experiment in Nature Human Behaviour in 2018. They divided a large crowd into small groups, had each group deliberate to a consensus, then aggregated the group answers. The result beat the average of a much larger crowd of individuals. Sequence and structure of interaction can matter as much as group size.

So, collect independent views first, then deliberate. Collect what people think before they hear each other, then put them together to argue it out and resolve differences. If discussion begins too early, it reduces the diversity of views before the group has made use of it. For an architect facilitating important decisions, getting that sequence right is a meaningful part of the work.

Designing the decision, not just the design

A group also needs a common picture of how things work before one person’s knowledge can become the group’s. Peter Senge put mental models among the five disciplines of a learning organisation, and team researchers later developed the related idea of shared mental models. Without enough shared understanding, people reason from incompatible assumptions, making it harder to integrate knowledge effectively. Someone needs to help build, maintain, and revisit that shared picture as the work and context evolve.

I saw the difference when I shifted from optimising a design alone to designing the decision process around it.

Working for an e-commerce company at the time, I introduced ATAM, the Architecture Tradeoff Analysis Method. ATAM evaluates a software architecture against prioritised quality-attribute goals and exposes risks, sensitivity points, and trade-offs. I extended the analysis beyond engineers to include category managers and business owners with direct knowledge of what the system was for. I explained the quality-attribute trade-offs in plain language, translated technical concerns into business consequences, and worked through the choices with them. The decisions improved because people who understood business consequences and people who understood technical costs could weigh the trade-offs together. No one in that room needed to become an expert in every domain. The room solved the problem, and my job had been to design the conditions for the room.

Over time, my instinct to control every decision shifted towards enabling others to make them well. In my next role, I was the sole architect at a data-marketing company and built the architecture practice from the ground up. Being the only architect taught me quickly that one person cannot attend every conversation or review every decision. So the job stops being “do the architecture” and becomes “make the organisation able to do it without you.” The work was a shared language, the standards, and a way of weighing decisions, so engineers and business leaders could make sound calls on their own.

A similar pattern appears when an architecture practice is being built. A platform is rarely sufficient on its own. The work is making knowledge discoverable, current and usable beyond the people and folders where it started, and that is where adoption, shared practice and governance are won or lost.

What designing the conditions looks like

In ordinary architecture work, a small number of practices make a large difference.

Design participation early, alongside the problem and the decision process. Ask who holds knowledge that will not be represented, the business owner, the person who lives with the result, the engineer who disagrees, and get them in. In my experience, the bigger risk is an incomplete room rather than a room full of the wrong people.

Where independent judgement matters, collect initial views before senior people signal a preference. A senior view anchors others, so use a written pre-read, silent first vote, or quick initial round before open discussion. It is a low-cost practice that is easy to skip.

Make the trade-offs understandable in language everyone in the room can use. Jargon prevents people without the specialist vocabulary from engaging fully, and they are often the ones who know what the decision is for. When I introduced ATAM at that e-commerce company, I never called it ATAM. Many organisations use TOGAF without knowing they use TOGAF. Translate technical choices into business consequences, and business goals into technical constraints, so the group weighs the same trade-off.

Keep the team knowledge in one shared place. A decision that exists only in someone’s memory or a private folder is knowledge the organisation cannot find, challenge, reuse or maintain. One purpose of enterprise architecture is to provide shared language and usable maps of how business capabilities, processes, information, and systems fit together. Calling that documentation misses its role in supporting decisions. A model becomes shared when people can understand it, use it, challenge it and update it in their own work, which takes explanation, repetition and active sponsorship. A model that is filed away does none of that. Usable decision records and reference models help the next person understand prior reasoning and build on it rather than starting from scratch.

None of these practices is exotic, which is the point. Collective intelligence depends on ordinary conditions that are hard to keep. Participation, independence, psychological safety, shared understanding, and an honest way to combine views. And someone needs to steward them. Usually that person is the enterprise architect.

This remains a growth edge for me too. My instinct is still to jump to an answer and fill silence with my own perspective. The discipline I keep relearning is to pause, structure the conversation so other knowledge emerges, and accept outcomes I would not have reached alone.

Designing the conditions can make more of a group’s existing knowledge available to the decision. It does not create knowledge the group does not have. Where the required expertise is absent, a well-run process still produces false confidence, and consensus conceals the uncertainty rather than resolving it. So when critical evidence is missing, stop deciding, or treat the decision as provisional and say so. Or choose the option that is cheapest to reverse, and design the seams so you can adapt when the evidence arrives.

The real job

There is a new participant in the room now: AI. Used carefully, an AI generates alternatives, retrieves relevant material, and raises questions the group missed, but its outputs still need evidence, context, and human challenge. In a badly structured group, a confident AI answer becomes the anchor and speeds up premature convergence, because nobody inspects the evidence behind it.

The old line is that the whole is greater than the sum of its parts. But that phrase skips the difficult question of how the parts are made to work together. The whole outperforms its parts when someone deliberately designs the conditions for coordination, challenge and integration. Craven’s experts were a scatter of hunches until he built the method that turned them into an answer. The aim is not to be the smartest person in the room, but to help create a room that can think better than any one person can alone. For many architects, especially those working across boundaries, that is a central part of the job.

I write more about this in my newsletter, The Foresight-Driven Enterprise. It is about designing organisations that can think and adapt ahead of change rather than after it.

Further reading

Anita Woolley and colleagues on the collective intelligence of groups (Science, 2010), and the pooled follow-up by Christoph Riedl and colleagues (PNAS, 2021). Joaquin Navajas and colleagues on small debates beating large crowds (Nature Human Behaviour, 2018). James Surowiecki, The Wisdom of Crowds. Peter Senge, The Fifth Discipline. Amy Edmondson, The Fearless Organization. The Craven story is told in Sherry Sontag and Christopher Drew’s Blind Man’s Bluff.