The context

Owen was asked to roll out a new development approach across more than 100 scrum teams at a large enterprise. The directive from leadership was simple: teams need to move faster. What nobody could tell him was what success would actually look like.

He was already building a metrics baseline with an engineering partner, but the initiative sat in product strategy, the executive sponsor was unclear, and he was getting pushback for wanting to measure before changing anything.

The advice

Owen talked it through with four product leaders from healthcare, fleet management, and enterprise software, all of whom had led large-scale change inside complex organizations.

• Get the baseline first. Then ask honestly whether this approach is even the right fix. The real issue might be too many priorities or org design.
• “Shipping faster” isn’t the goal. Tie the work to outcomes and time to value.
• Find who will take credit. Whoever claims the win is the real stakeholder. Align with them.
• Don’t weaponize metrics. Comparing teams against each other creates political fights fast. Show how pilot teams improved against their own baselines instead.
• Start small. Pilot with one or two eager teams and let them become champions. One coach watched a single pilot team spread the approach across her org.
• Map the whole process. Show stakeholders the path from idea to shipped code and ask, “Are these the points you want to improve?”

The outcome

Owen left with a clear plan: take the remit question to his manager, and within two weeks land on a focus that reduced friction instead of absorbing it. Underneath that was a bigger shift. Much of the friction he’d been fighting wasn’t his to fight, and the work itself might belong somewhere other than product strategy. Naming that gave him a way to reshape the role instead of just pushing harder inside it.

Why it worked

The coaches helped him separate the assignment from the actual problem.

They gave him a low-risk path forward: execute, pilot, and let results make the case.

Hearing it from peers outside his company gave him permission to question the setup.

The broader point

Sometimes the most useful thing a peer can tell you is that you’re working hard on the wrong problem.

The advice might seem obvious now. Having peers to act on it with is what made the difference.

“Shipping faster” isn’t the goal. Tie the work to outcomes and time to value.