Redesigning How We Work Together

The Situation

As Head of Product Design at a B2B SaaS platform company, I inherited a team with a problem. The work of one senior engineer—talented, experienced—wasn't landing with the rest of the team. Meetings were tense. Points got cut off before they were finished. The team had learned to route around the collaboration rather than work through it.

Something didn't add up. The engineering work was excellent. The ideas, when I took the time to understand them, were often the best in the room.

What I Tried First—and Got Wrong

I started where most managers start. Feedback about how contributions were landing. Smaller meetings. Clearer expectations. Nothing changed.

It shouldn't 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'd like to admit.

The Analysis

So I stopped assessing a person and started recording conditions. I asked a narrower question: when did this collaboration fail, and when did it work?

The pattern was consistent. It failed in fast-moving 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.

That reframe changed the question. Instead of "how do we fix this person?" I asked "how do we fix this system?"

The Redesign

I restructured how our team collaborated:

• Material in advance — Context went out before group discussions, so thinking could happen ahead of the meeting rather than under time pressure inside it.
• Written agendas — Every meeting had an agenda shared in advance. No more "quick syncs" that turned into hour-long debates nobody could prepare for.
• Explicit turn-taking — In group settings, I created space for sequential input rather than whoever-talks-loudest.
• Written decisions — Important decisions were documented, not left to whoever remembered the verbal conversation correctly.

The Resistance

Not everyone was on board.

"Why should we change how we work for one person?" This was the question, sometimes asked directly, sometimes implied through eye-rolls and foot-dragging.

My answer was that we weren't changing it for one person. We were changing it because the process had a bias we'd 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 case pragmatically: we were losing good ideas because our process filtered them out before they were heard. That's a business problem, not just a fairness problem. And the fixes were cheap—an agenda, material sent ahead, a decision written down.

The Outcome

Within months, the dynamic shifted. Contributions that had been getting lost started landing. Ideas got airtime. Code reviews caught problems others missed. The tension dissolved.

But the bigger change was the team. Other members started adopting the structured approaches for themselves. The prep, the written agendas, the documented decisions—these became team norms rather than a fix for one situation.

Most importantly, the team learned a new reflex. When collaboration breaks down, the first question is now "what's wrong with our system?" not "what's wrong with that person?"

The Broader Lesson

This experience crystallized my approach to leadership. The same empathy we apply to user research—understanding different needs, designing for edge cases, testing our assumptions—must extend to how we build teams. And it's worth noticing how much more comfortable it is to examine a person than to examine a process.

Human-centered organizations create human-centered products. You can't design inclusive software with an exclusive team process.