A rule for work that has an owner, the larger pile of work that doesn’t, and what design leaders can do about shared problems without claiming them forever.
When work has a clear owner, the rule is simple, and a senior leader stated it well this week: you go through the owner. Part of owning something is keeping it clean and consistent, and living with the consequences of every change, so nobody gets to route around that. Then he described the second case, the large pile of things that aren’t clearly owned by anyone, and he said it plainly: that case is unsolved.
I think design leaders live in that pile. We’re usually the first to see it, because we look across the whole product, and the problems in it tend to be experience problems: a pattern that’s slightly different in 4 places, a workflow that crosses 3 teams, a shared component nobody has touched in years. I said it this way to one of my design leaders this week: anything that’s shared, or doesn’t have an owner, or doesn’t fit neatly inside one team, never gets fixed unless we do something different.
Here’s what “something different” has looked like lately.
Find a reviewer, even if they aren’t the owner. For the long backlog of small cross-product fixes, standing up a new process or a committee was never going to catch on. What’s working is smaller. A designer and an agent do the work with whoever cares about the change, and an engineering lead reviews it. That person may not own the area, and if they’re capable of reviewing it, that’s enough to keep things safe and moving.
Give shared work a way to rank itself. A platform team with a long backlog and no product partner has no way to decide what comes first. So the loudest voice in the chat channel wins, and the work connects to no goal. This is why I keep saying a product manager for a design system is a no-brainer. Someone has to own it end to end, weigh one request against another, and be able to say no.
Agree on “what” before “where.” A product lead made this point in a planning session and I’ve borrowed it already. First agree there’s an opportunity. Where it lives is the second question, and it’s a much easier one after the first is settled. A related line from the same week: everyone touching a shared system isn’t a reason for any one team to own a flow that runs through it.
Volunteering to define an unowned problem is different from claiming it forever. Most of the pile only needs the first one.
Send people to the right place, and share the credit. One of my design directors and I talked through the worry that an entry surface linking deep into another team’s workflow blurs who gets credit for the outcome. From a UX perspective, linking people straight to where the job gets done is the right thing to do, and we’re all pushing for the same metrics. The practical fix is instrumentation: measure completed flows so the owning team gets credit no matter where the person started. Once the measurement is fair, most of the turf worry goes away.
Let design do the linking, for now. Several teams are building pieces of the same pattern, and one of them doesn’t have a dedicated product partner. So it’s on design to keep those teams sharing what they learn and using the same language for it. That’s not how I’d draw it on paper, and it’s what the moment needs. (I wrote more about converging teams in Issue 24.)
An engineering leader said the thing I’d put at the top of this pile: someone has to make it a priority to go discover and define the problem, even if different teams end up owning different parts. That’s the role I’d encourage design leaders to volunteer for. You don’t have to own the fix or keep it forever. You can still be the person who writes down what the problem is and who it affects, and brings the right 3 people into a room.
One small habit helps with all of it. I’ve asked my team to celebrate wins and work anniversaries in the cross-functional channels, with the squad, before the design channel. The squad is a designer’s first team, and people fix shared problems faster with people they already celebrate with.