What does it mean that choice architecture for teams?

The same principles that work for personal choice architecture work for teams.

Example: Your team adopts a new project management tool. Within a week, the tool's default notification settings have every team member receiving alerts for every comment on every task. Nobody configured this. Nobody chose it. But now every developer is interrupted an average of fourteen times per hour by notifications about tasks they are not working on. Two months later, the team's deep work output has dropped measurably, frustration is high, and someone suggests the tool 'doesn't work for us.' The tool works fine. Its default choice architecture doesn't. The team never designed its notification environment — it accepted the vendor's defaults, which were optimized for engagement metrics, not engineering output.

Try this: Identify one team process that currently operates on an unexamined default. This could be a meeting cadence, a communication channel norm, a decision-making pathway, or a workspace arrangement. Write down: (1) what the current default is, (2) who chose it and why (or whether it was never explicitly chosen), (3) what behavior the default encourages, and (4) what behavior you actually want. Then propose one architectural change — a new default, a friction adjustment, or an environmental restructuring — that would make the desired behavior easier without requiring anyone to exercise additional willpower. Present this to one colleague and ask whether they have noticed the same pattern.