Redesigning How We Work Together

The Situation

I inherited a team with a problem. One engineer—talented, experienced—had been labeled "difficult" by colleagues. Meetings were tense. His input was dismissed before he finished speaking. The team had learned to work around him rather than with him.

The conventional response would be performance management, coaching, or eventually managing him out. But something didn't add up. His code was excellent. His ideas, when I took time to understand them, were often the best in the room.

The Insight

I started paying attention to patterns. He struggled in fast-paced group discussions but thrived in written communication. He needed time to process before responding. His "interruptions" were actually delayed responses to topics we'd already moved past.

I recognized neurodivergent patterns—not as a diagnosis, but as a design constraint. The problem wasn't him. The problem was that our collaboration systems were designed for one type of mind, and his didn't fit the mold.

This reframe changed everything. Instead of asking "how do we fix this person?" I asked "how do we fix this system?"

The Redesign

I restructured how our team collaborated:

• Pre-meeting 1:1s — Before group discussions, I'd meet with him individually. He could process ideas, prepare contributions, and flag concerns without the pressure of real-time response.
• Visual agendas — Every meeting had a written agenda shared in advance. No more "quick syncs" that turned into hour-long debates.
• 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.

This became a teaching moment about equity versus equality. Equality means everyone gets the same thing. Equity means everyone gets what they need to contribute. Different minds need different systems—not special treatment, but appropriate accommodation.

I also made the case pragmatically: we were losing good ideas because our process filtered them out. That's a business problem, not just a fairness problem.

The Outcome

Within months, the dynamic shifted. The "difficult" engineer became one of our strongest contributors. His ideas got airtime. His code reviews caught bugs others missed. The tension dissolved.

But the bigger change was the team. Other members started adopting the structured approaches for themselves. The pre-meeting prep, the written agendas, the documented decisions—these became team norms, not accommodations.

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.

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