Murmuration for growing design teams
At Anduril, our software design and research team has been growing quickly, along with the rest of the company. When I joined, the team had fewer than ten people. Two years later, it had nearly thirty.
That growth has brought new ideas, new ways of working, and the ability to support parts of the business we simply couldn’t reach before. It has also brought organizational and structural change.
I lead a subteam within the broader team. I often think about what the team needs to support individuals and the business. I’m particularly interested in how smaller teams take shape within the broader design team, and how they stay connected.
Getting every designer into the same room or video call used to be straightforward. Coordinating thirty calendars and thirty sets of priorities is a different problem.
How does a large group share information and change direction? How do people stay aligned when they can no longer participate in every conversation?
I keep coming back to starling murmurations.
A murmuration is the shifting cloud of birds you might see sweeping across the sky before settling down to roost. Thousands of starlings move together, changing the shape and direction of the flock. Research on murmuration behavior suggests these displays help protect the birds from predators.
What interests me most is how they coordinate. Each bird responds to nearby birds, yet those interactions contribute to movement across the flock.
Birds aren’t designers, of course. But the analogy gives me a way to think about keeping coordination manageable for each person while helping the whole group respond to change.
Keep coordination local
In a field study of starling flocks, researchers found that each bird interacted with an average of six or seven nearby neighbors. The number of neighbors mattered more than a fixed distance between them.
I wouldn’t treat seven as a prescription for team size. The useful idea is that coordination can begin with a manageable set of relationships.
As a design team grows, it can be tempting to include everyone in every critique, decision, or discussion. We want people to feel informed and involved. But being invited to every conversation isn’t the same as having the context to do good work.
I’d aim for small groups whose members understand one another’s work well enough to make decisions together. Those groups should also have clear connections to the people outside them whose work they affect.
For example, a project critique could include the designers and partners closest to the problem. A decision that changes a shared interaction pattern should reach the teams that use it. The audience should follow the consequences of the work.
Give information a path across teams
Local coordination raises a question: how does a change reach the rest of the group?
Research on starling flocks found that correlations in the birds’ movement extended over distances that grew with the size of the flock. The researchers described this as scale-free behavior. A bird’s immediate interactions were local, but the patterns of movement reached much farther.
Suppose a research team learns something that changes a product assumption. The designers working on that product and related experiences need to know, with enough context to decide what to do.
That could mean a short decision record explaining what changed, why, and who might be affected. It could mean a regular exchange between teams that share dependencies. A person could take responsibility for bringing relevant findings from one group into another.
Subteams should have the authority to make decisions within their scope, along with a responsibility to tell others when those decisions affect them. Decisions with broader consequences still need broader coordination.
Establish shared rhythms
In a study of collective turns, researchers observed turns beginning with a few birds and spreading through the flock.
I’d want a growing team to have room for that kind of initiative. A researcher should be able to bring forward a finding that challenges a plan. A designer should be able to surface a pattern others could use. The people with relevant knowledge should have a clear way to influence the work.
Leaders still have a role in setting direction, resolving conflicts, and taking responsibility for decisions. I think part of that role is establishing the conditions in which people can act: a shared goal, clear boundaries, and a way to ask for help when those boundaries are uncertain.
Small critiques can give people timely feedback. Regular exchanges between related teams can surface dependencies. Occasional gatherings of the whole team can reconnect the work to the larger direction.
Each gathering should have a purpose people can name. What do we need to learn, decide, or resolve together? If the answer is simply to hear updates, a written note might serve us better.
Give teams room to move
The neighbor research also offers a useful correction to the metaphor: the number of interacting neighbors stayed roughly constant across flocks with different spacing.
People need room to do their work, along with reliable connections that help them notice when their work and someone else’s begin to diverge.
Too little contact can leave related teams solving the same problem separately or discovering a dependency too late. Constant coordination can consume the time people need to explore and execute.
I’d adjust the amount of contact to the work. Teams shaping a shared experience may need frequent conversations while important decisions remain open. Once the direction is clear, a brief written update and an agreed point for checking in may be enough.
I’d also make it easy for anyone to call for more coordination when something changes. A regular meeting should support that conversation without becoming a reason to postpone it.
These ideas could take different forms depending on a team’s size, maturity, growth rate, and the work it needs to do. I wouldn’t expect one arrangement to fit every team at every stage.
I’d start by finding where coordination is breaking down. Where does important information arrive too late? Which decisions wait on someone who isn’t close to the work? Which meetings leave people informed but unable to act?
Then I’d try a simple change: give a group clearer authority, connect two teams whose work overlaps, or make a decision easier to find. Give the change time to work, then look for its effects. Do people understand what changed and why? Can they make the next decision? Are they finding dependencies early enough to respond?
What draws me to murmurations is the possibility of a large group moving together through relationships each individual can maintain.
That is what I’d want to preserve as a design team grows: enough shared direction to act together, and enough room for each person to contribute what they see.