Coordination exhaustion: Why the friction is draining your team

This is the third post in my series on design capability as a system. The first introduced a diagnostic framework; the second explored why insights don’t land with the business. This one tackles something more immediate: why your team might be exhausted even when the workload looks manageable.

There’s something I hear quite often from growing design teams: “We’re not even that busy, but everyone’s exhausted.”

The workload looks manageable on paper. Projects are moving and people are delivering, but there’s a tiredness that doesn’t match the output, an underlying drain that accumulates over weeks and months.

When I’ve dug into this with teams, the exhaustion often isn’t coming from the work itself. It’s coming from everything around the work: figuring out how each team likes to operate, recalibrating to different stakeholder expectations, searching for information that lives in different places depending on who created it, solving problems someone else already solved six months ago but nobody knows about.

None of these things are individually catastrophic, but they compound. The cognitive overhead of constantly adapting, searching, and re-establishing how things work eats into the energy that should go toward actual design problems.

The frustrating part is that solutions often exist, but everyone’s too busy to implement them. No time to fix the thing that’s eating your time.

This is coordination exhaustion. And it’s a system problem, not a resilience problem.

In the first post in this series, I introduced five functions from the Viable System Model that design capabilities need to work well. Two of them, coordination and operational standards, are what can keep the day-to-day running smoothly. When they’re working, they’re invisible. When they’re not, the symptoms show up in your people before they show up in the output.

I’ve tried to take a practical look at where coordination tends to break down and what you can do about it. I want to avoid abstract advice about “improving coordination” that doesn’t help anyone. You need things you can actually try.

The hidden costs of poor information flow

Project overload gets a lot of attention, but there’s another driver of exhaustion that’s harder to name: the cognitive cost of inconsistency.

When designers work across multiple product teams, they’re not just context-switching between different problems. They’re adapting to entirely different ways of working and politics. One team runs two-week sprints with design a sprint ahead, another does continuous discovery with no fixed cadence, a third wants polished specs before engineering will engage, and a fourth prefers rough sketches and conversation.

Each approach can work well. The problem isn’t with the approach of the teams, it’s that designers have to hold all the differences in their heads and constantly switch modes. Every engagement starts with a re-learning phase: how does this team like to work? What do they expect from me? Where do things live? Who makes decisions?

This adaptation work is often invisible. It doesn’t show up in utilisation metrics or project plans, but it drains energy and attention that could go toward actual design problems.

The same thing happens with stakeholders. Different leaders have different expectations of what design involvement looks like. Designers learn to read these preferences and adjust, but each adjustment is effort, and it accumulates.

Then there’s the cost of not knowing what others are doing. A designer spends two weeks solving a problem, only to discover someone on another team solved it six months ago. The solution already exists, it’s just invisible. Work happens inside teams, and unless there’s a deliberate mechanism for sharing outward, it stays there.

The duplicated effort is the obvious cost. Less obvious is the anxiety of uncertainty: has someone already tackled this? Am I about to reinvent something? Should I be looking for prior work, and if so, where? The uncertainty itself creates friction, even when there’s nothing to find.

Gaps are the other side of duplication. A service spans multiple product areas, but no one has the full picture, so the joins are rough. Research done in one team could easily inform another’s work, but the connection never gets made. Everyone is busy with their piece, and the whole suffers.

The usual response is more documentation, but the ever-growing graveyard of abandoned wikis and unread Confluence pages is evidence that “write it down and put it somewhere” isn’t enough.

What can help:

You don’t need to force everyone into the same way of working, but you can reduce the cognitive load by creating consistent anchor points. Some teams have addressed the re-learning cost with short “team manuals”: a page covering how this team works, where things live, who to ask about what. It takes an hour to create and saves days of figuring things out. I’ve used a simple Notion template for this, but the tool matters less than the habit.

For visibility across teams, low-effort rhythms can beat heavy documentation. A 30-minute fortnightly session where each team gets 2–3 minutes to share one thing. No slides required. The point is pattern-matching and connection, not walking through detailed documentation. I’ve also used a dedicated Slack channel for “share before it’s polished” updates: no expectation of response, just visibility. The value comes from the occasional “Oh, we should talk” that would never have happened otherwise.

Ideally, you want people to be able to find things without having to ask around. If your team’s default way of finding past work is to ask around, that’s a sign the information architecture isn’t working. Consider consistent naming conventions, a clear folder structure, tags that people actually use. With the growing use of automation tools and AI, creating a consistent, well managed knowledge base is easier than ever.

Make searching easier than asking, because as soon as that one person who knows where everything is leaves, the knowledge goes with them.

Coordination without control

There’s a tempting solution to coordination problems: centralise everything. Create a single process. Require all work to flow through a defined pathway. Hold weekly status meetings where everyone reports in.

This approach feels like coordination, but it’s actually control. Control doesn’t scale. It creates bottlenecks and it slows teams down. People start working around the process rather than through it, and you end up with the worst of both worlds: the overhead of the central process plus the chaos of people ignoring it.

Real coordination is different. It’s not about controlling how work happens. It’s about ensuring the right information flows to the right people at the right time. The goal is shared awareness, not centralised authority.

This distinction matters because it changes what you’re trying to build. You’re not designing a process that manages work. You’re creating conditions where teams can manage their own work while staying aligned with each other.

In my experience, this can be one of the most challenging things to overcome in larger, more established organisations. The urge to centralise control when things aren’t going well is difficult to resist. Leaders have often only experienced a culture where this is the norm, and taking away control can be deeply uncomfortable. Making things more visible can help ease this tension, but it often requires close working with leaders and decision-makers to help them feel comfortable with not being in every decision, and providing them with evidence of success.

Coordination that works tends to share a few characteristics.

Ambient, not demanded. information is visible by default, not extracted through reporting. Rather than a project manager chasing people for status updates, they can check the shared board themselves.

Peer-to-peer, not hub-and-spoke. teams coordinate directly without everything flowing through a central function.

Asynchronous where possible , because meetings are expensive and don’t scale.

Structured enough to be useful, loose enough to adapt , because getting feedback from teams and watching for gaps matters more than getting the framework perfect upfront.

What can help:

Review your current coordination mechanisms periodically. For each meeting, channel, and ritual, ask: is this creating shared awareness, or is it primarily about control and reporting? If your main coordination mechanism is designers reporting status upward, consider what would need to change for that information to be visible without the reporting: shared boards, open channels, regular artefact reviews. These create visibility as a byproduct of work rather than as an additional task.

I’ve found journey maps and service blueprints useful here, not as deliverables for stakeholders, but as orientation artefacts for the team. When everyone can see how their piece fits into the whole, they make better decisions about where to coordinate and where to move independently.

And push back on coordination theatre. “I’m not sure this meeting is serving its purpose anymore, do we still need it?” can feel risky to say, but it’s often a relief to everyone involved.

Standards that enable, not constrain

Standards can get a bad reputation in design teams, the word conjures images of bureaucratic checklists, rigid templates, and approval gates. But the opposite of bad standards isn’t no standards, it’s good standards.

There’s a useful distinction here. Bureaucracy exists to manage risk and ensure compliance: “How do we make sure nothing goes wrong?” Enabling structure exists to make good work easier: “How do we help people do their best work faster?” The distinction shows up in how standards feel to use. Bureaucratic standards feel like obstacles you have to get through, whereas enabling standards feel like tools.

Think about preparing a presentation for a research playback. A template gives you the branded look and feel, consistent structure, and examples of how to display information, so you can focus on the narrative and key messages. The template frees you up. The same principle applies to standards for how work gets documented, how decisions get communicated, how handoffs happen, and how critique works.

Signs a standard has become bureaucracy: people work around it more often than with it; the effort to comply outweighs the benefit; only the people who created it think it’s useful. Signs a standard is enabling: people use it voluntarily even when no one’s checking; new team members find it helpful; removing it would make things noticeably harder.

The art is knowing what to standardise. Repeated low-value decisions (where to store files, what to include in a handoff) are good candidates, as are the interfaces between teams (“here’s what engineering needs from us to build confidently”). Creative and strategic decisions are poor candidates, as are processes that depend heavily on context or that change faster than you can update the standard.

What can help:

Start from pain points, not best practices. “Handoffs keep causing confusion” is a reason to create a handoff standard. “I read that mature design teams have a critique process” is not. Starting from best practice can lead to bolting on extra work that’s just not needed. Let your standards evolve from your own friction, then use best practice for inspiration on how to solve it.

I’ve found embedding lightweight guidance directly into tools works well: instead of a separate document explaining how to write a design brief, put the guidance into the brief template itself. This connects standards to the moment someone needs them, rather than burying them in a wiki that nobody visits.

Build in feedback loops. If a standard isn’t working, you want to know quickly rather than have people silently work around it.

The people in the coordination layer

So far, I’ve talked about coordination and standards as functions. But in many organisations, there are people whose job is to make these functions work: DesignOps, ResearchOps, project managers, programme managers.

When these roles are effective, they reduce friction, create visibility, and free up designers to focus on design. When they’re not, they become another source of overhead. The difference isn’t usually about the people. It’s about how the roles are positioned.

The core challenge is that coordination roles can drift toward serving leadership’s need for information rather than practitioners’ need for support. When that happens, the role becomes about reporting, tracking, and oversight rather than enabling the team. If the role is positioned as support for team effectiveness, with leadership visibility as a byproduct, it becomes an enabler. If it’s positioned mainly as eyes and ears on the team, practitioners will experience it as surveillance.

It’s worth noting that service designers can often end up operating in this coordination layer, whether or not that’s their job title. The skills that make someone good at service design, understanding systems, mapping flows, seeing how parts connect, are the same skills that make coordination work visible and improvable. If you have service designers in your team, their perspective on coordination is worth seeking out. The risk is that they get pulled entirely into internal optimisation and away from customer-facing work, so it’s a balance to manage.

Whether or not you have dedicated coordination roles, a useful exercise is to list all the coordination activities currently happening and for each one ask: who benefits from this? What would happen if we stopped doing it? Is the effort proportionate to the value? The answers often reveal coordination theatre that can be retired and genuine needs that are underserved.

What can help:

Protect the role from becoming a dumping ground. Coordination roles are vulnerable to scope creep. Because they sit adjacent to the work rather than doing it, it’s easy to add responsibilities: “Can you also track this? Can you own that meeting? Can you manage this stakeholder?” Each addition seems small, but they accumulate. Without protection, the role becomes overwhelmed, starts doing everything poorly rather than a few things well, and this has a knock-on effect for the wider team.

Treat them as allies, not administrators. The person in a coordination role is trying to make your work easier, that’s what the role is for. If you treat them as bureaucratic overhead, you’ll get a bureaucratic relationship. If you engage them as partners in solving friction, you’ll often find they have leverage and visibility you don’t.

Recognise the constraints they’re operating under. Coordination roles often sit between practitioners who want less process and leadership who want more visibility. They’re managing competing demands. Understanding this helps you work together more effectively and makes your feedback more useful.

Where to start

A practical starting point: pick one source of friction your team experiences repeatedly. Maybe it’s the re-learning cost when designers move between teams, maybe it’s the difficulty finding past work, maybe it’s a meeting that’s become coordination theatre. Ask your team and map it out. Understand why it persists, then try one lightweight change and see what shifts.

Over time, you can map out more points of friction and work on them. Coordination problems compound over time, but so do small improvements. You don’t need to fix everything at once. Start by noticing where the energy is going, then redirect it toward work that actually matters.

And if your team is experiencing that strange exhaustion that doesn’t match the workload, take it seriously. Remember, it’s not a resilience problem, it’s information about your system and the friction is telling you something. We want our teams to be able to be creative, to problem solve and to do their best work, not get burnt out by bureaucracy.

My next post will look at the shape of your teams: the different configurations design teams can take, how they interact with the wider organisation, and where common setups can create friction.