Between design and engineering: what Team Topologies taught me

Earlier this year, my engineering leadership suggested I read Team Topologies by Matthew Skelton and Manuel Pais. It's a book about structuring teams so software flows smoothly. Three ideas stuck with me.

Conway's Law. A product ends up mirroring how the teams behind it communicate. I see it constantly. When design and engineering don't talk, it shows up in the product.

Facilitating. The book describes teams that help other teams get unblocked and learn. I'm not a team, but it's exactly where I fit. As an implementation engineering lead who also works as a UX designer, I see designs early. That lets me bring an engineer's voice into the conversation while designs are still in progress, before final sign-off. Then, during handoff and development, I can explain why the designs are the way they are.

Cognitive load. Every team can only hold so much, and as a lead, I try to protect my team's. In my experience, design and engineering friction usually comes from two things: unclear specs and a missing why. Both force engineers to fill gaps with guesswork, and guesswork is heavy.

To me, a healthy relationship between the two looks like:

• Constant communication
• A hunger to help each other, offered before anyone asks
• Teaching each other, so both crafts get better

Specs say what to build. Context says why. My job is to make sure both make it across.