Who Makes Decisions Around Here?

In many Product Development organizations, who-decides-what about the product is hazy, inconsistent, or not fully defined. This limits the ability to deliver good value reliably.

I see this in many organizations that have officially adopted an off-the-shelf process framework. Even if the framework comes with clear roles and responsibilities, the job descriptions and expectations for people with decision power remain unchanged.

For example, Scrum and some of its scaled versions assign responsibility for the product backlog very clearly, but many product owners still follow instructions from steering committees, VPs, and sponsors (who don’t always speak with a single voice).

This dynamic also happens on the technical side. At several clients, it wasn’t clear how architectural decisions got made. Sometimes it was by individual tech leads, sometimes by several leads in collaboration, sometimes by engineering directors.

The strategic solution: For every type of product-affecting decision, it must be clear and accepted who makes it.

Otherwise, people who need to make progress on something will play it safe and follow cultural norms. In some cultures, that means waiting for their direct managers to make the calls; in empowerment-oriented ones, they might go ahead with their own individual choices. For best value delivery in your context, neither may be a great option.

None of this implies that decision-making needs to be in the hands of single individuals exercising positional authority. Many decisions should rest with groups, who then need effective means to make them (synchronously or otherwise, with various forms of consensus, etc.)

Moreover, having clear decision-making arrangements does not mean they’re fixed for all time. I regularly see them evolve as a team matures or their conditions change. At one client, once the department reached a certain size that their regular consensus-seeking approach was slowing them down, they changed it to allow most cross-team decisions to be made by small, self-selecting task teams.

This strategy is quick and simple to implement, and the gains are substantial.