What leaders owe teams building the same thing in parallel, why working in silos isn’t what autonomy costs, and 4 moves for converging without slowing anyone down.
At my monthly AMA, a senior designer described how ICs across teams end up connecting the dots among themselves, and I pushed back, though not on him. I don’t think it’s okay for anyone to be working in silos. It would be okay if we had highly aligned teams, because that’s the only way you get highly autonomous ones. Without the first part, we’re asking everyone to do the connecting on their own, in the margins of their actual jobs.
Most product orgs building AI right now have more teams than owners. Several squads are building something that looks like the same assistant pattern, each on its own mechanism, each for good reasons, and the connective tissue between them belongs to nobody in particular. The instinct is to stop everyone and pick a winner. I’d rather keep everyone moving and give them a shared map. Here’s what that looked like this week.
Favorite, not default. The team furthest along keeps building, and nothing slows. What they’re building might become the blueprint the other teams inherit, and I said so. But I call it the favorite, not the default, because a product partner made a fair point: familiarity is a bad reason to pick a platform. It has to hold up against the problem statement. And I said the uncomfortable part out loud early: some teams will have to adopt a different way of doing things later, and fix some UI along the way.
Principles at the top of the doc. No matter who’s working on what, they read the principles first: we’re building one shell, anyone can hook into it with the skills they’re building, and here’s what switching context looks like. On the design side we were mostly in agreement already. It was in our heads, and it just wasn’t on paper. The artifact now has one designer holding the whole shell while squad designers build their entry points into it, story first and screens second, with a small checkpoint on Monday instead of one-shotting it.
Good components can shift shape. Two surfaces are fine, and two sources of truth are not.
Components that shift shape, and one source of truth. A debate about whether a to-do list should look different in 2 places settled on a line I’ll keep using: good components can shift shape. A dropdown can grow a search field when the list gets long, and it’s still a dropdown. What matters more sits underneath. If 2 surfaces read from 2 different task systems, no homepage design is going to save us, and it’ll make things worse. Two surfaces are fine, and two sources of truth are not.
Shorter toes. When a product partner worried about stepping on other teams’ work, my answer was that we all need shorter toes. Everyone is trying to do the right thing for clinicians. One squad designer described how they’re keeping pace with the shared vision in a line I loved: they’re married to it until a set date, then they split off to ship, knowing some of what they build will get overridden. That’s a mature way to converge while still delivering.
What do leaders owe the teams in that picture? The only way people move faster at the squad level is if the higher level is set up for them, and I’d much rather that come from the top down than leave ICs to negotiate it across teams. There’s a limit on design’s part of it, too. I’ll always argue for consolidating, because duplicated effort is expensive, but telling a team to stop belongs to the product leaders who own the roadmap. Design’s job is to bring them the proposal and an artifact worth deciding on. ICs will know things leaders don’t, leaders will see things ICs can’t, and meeting in the middle is the hard work ahead of us.