What changed
- The collaboration
- Tension, points dismissed, the team routing around the working relationshipContributions landed and got airtime, and problems got caught earlier
- Team norms
- Loudest-voice-first discussionsWritten 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
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.
What I took from it
Good leadership is not mainly about managing people. It is about designing the conditions people work within. When collaboration breaks down, look at the system before you look at the person, and notice how much more comfortable it is to do the reverse.
And you cannot build inclusive software with an exclusive team process. Human-centred teams are what make human-centred products possible.
Read the full case study
The role
I joined to make design a real function. The company was in the middle of a platform shift, and design needed to carry the same weight as product and engineering rather than sit downstream of them.
Most of that was the expected work. I managed a team of five, including a design lead. I built a planning process so design, product, and engineering worked from the same picture. The design system was mine, and I set up joint governance with engineering around it, a working group of four designers and the engineering team. I hired people, and when someone was not the right fit, I made that call too.
The part that taught me the most was not on that list.
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.
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
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.
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.
Turn-taking, on purpose
In group settings I made space for sequential input, instead of letting whoever spoke loudest set the outcome.
Decisions in writing
Important decisions were written down, not left to whoever remembered the conversation their way.
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.
The pushback
Not everyone agreed at first. "Why should we change how we work for one person?", sometimes asked out loud, sometimes through eye-rolls and foot-dragging.
My answer was that we were not changing it for one person. We were changing it because the process had a bias we had never examined: it rewarded speed of response over quality of thinking, and we had no idea what that was costing us.
I also made the plain business case. Good ideas were being filtered out before they were heard. That is a cost, not just a fairness question. And the changes were cheap, an agenda, material sent ahead, a decision written down.
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.