Leading a team is a design problem

Head of Product Design

Team of five, including a design lead

As Head of Product Design at a B2B SaaS platform company I had a team of five, a seat at the leadership table, and a design practice to turn into a real function. The part I think about most was none of that. It was a working relationship that kept breaking down, and how long it took me to look in the right place.

Where collaboration kept breaking down

The work of one senior engineer was not landing with the rest of the team. Meetings were tense. Points got cut off before they were finished. Over time the team learned to route around the collaboration rather than work through it.

Two-part diagram. Above, the order input arrived in: fastest to speak, loudest to hold the floor, whoever remembered it after, then the decision — with no agenda, no prep time and nothing written down. Below, three boxes: the discussion, a senior engineer, the decision. The link into the engineer is marked cut off and the link out is marked rarely arrived, and a dashed arc runs beneath from the discussion straight to the decision, bypassing them. View full size ↗
Fig. 01

The pattern I was actually looking at, once I stopped looking at the person.

Read the reasoning behind this decision

It did not add up. The engineering work itself was excellent, and the ideas, once there was room for them, were often the sharpest in the room.

I tried the conventional moves first. Feedback about how contributions were landing. Smaller meetings. Clearer expectations. None of it changed anything, and it should not have. Every one of those moves put the cost of the problem on one person and left the process that produced it completely untouched. That was my mistake, and I made it for longer than I would like.

So I stopped assessing a person and started recording conditions. When did this collaboration fail, and when did it work? The pattern was consistent. It failed in fast group discussion, on questions asked cold, and under time pressure. It worked one to one, in writing, and whenever the material had gone out in advance. Same person, same capability, opposite outcomes. The variable was the setting, not the individual.

Our collaboration ran on a single default: fast, verbal, loudest voice first. Nobody had chosen that default on purpose, which is exactly why nobody was accountable for what it filtered out.

What I changed

Five changed conditions across a band — agendas shared early, room to prepare, turn-taking on purpose, decisions in writing, coaching the design lead — and beneath each, the property it puts back: thinking time, processing before rather than under pressure, sequence instead of volume, one record instead of five recollections, and the same shift one level down. View full size ↗
Fig. 02

Five changes to how the team worked. None of them about anyone in particular.

  1. Agendas, shared early

    Every meeting got a written agenda in advance. No more "quick syncs" that turned into hour-long debates no one could prepare for.

  2. Room to prepare

    Context and material went out before group discussions, so thinking could happen ahead of the meeting rather than under time pressure inside it.

  3. Turn-taking, on purpose

    In group settings I made space for sequential input, instead of letting whoever spoke loudest set the outcome.

  4. Decisions in writing

    Important decisions were written down, not left to whoever remembered the conversation their way.

  5. Coaching the design lead

    I coached my design lead through the same shift: how to set up the conditions for a strained engineering relationship and work through it directly, rather than routing around it.

What changed

Within months the dynamic shifted. The bigger change was that the structured habits spread. Other people adopted the prep, the agendas, and the written decisions for themselves. They stopped being a fix for one situation and became the norm. The same attention I gave to one set of working conditions is the attention I give to product design: understand the real need, design for the edge case, check the assumption.

The collaboration
Tension, points dismissed, the team routing around the working relationship Contributions landed and got airtime, and problems got caught earlier
Team norms
Loudest-voice-first discussions Written agendas, prep time, and documented decisions became how the team worked by default
How the team thought about friction
People started asking what was wrong with the process before deciding what was wrong with a person

Want to hear more?

  • Want to know why my first three fixes changed nothing, and what changed once I stopped diagnosing a person and started recording conditions instead?
Get in touch