Bob’s Algorithm: Working with Org Goal Conflicts

Craig crafted a powerful algorithm that helps address such conflicts in optimizing goals and teaming up with people like Bob. Everyone who had a chance to learn from Craig in his classes on system thinking in org design—Certified LeSS Practitioner—knows this well.

Let’s assume the organization’s primary goal has been set: to become more customer-centric.

There is Bob. He supports customer centricity in theory. When the change starts to touch his team, though, he pushes back.

“If we let developers talk to customers,” Bob might say, “That wouldn’t be efficient. If we let developers spend time with customers, they’ll lose precious development time.”

Our first instinct is to fight and prove we are right and he is wrong. But that will only turn up emotions and, in the worst case, turn Bob from a vocal proponent to a silent saboteur. That would undermine the whole change process. We need to act with compassion and wisdom.

Before we challenge Bob, let’s pause and take him seriously. Bob isn’t trying to sabotage the change. He cares about efficiency. He’s thinking about resource constraints. He has good intentions.

Here’s a simple algorithm to team up with Bob.

1. Don’t degenerate (Bob is not evil)
2. Appreciate the concern (Bob is right in his own way)
3. Remind him of the goal (separate primary from secondary)
4. Generate options (avoid false choices)

We start with:

“Thank you, Bob.”

Now we gently bring him back to the primary goal:

Bob, we really appreciate your perspective. You’re a thoughtful manager, and we know you’re trying to protect the developers’ capacity.

Bob calms down. Now he can actually listen. We continue:

Having said that, Bob, let’s try not to lose sight of what we’re aiming for here: building a

more customer-centric organization.

And now comes the question that breaks the false dilemma:

How can we increase customer centricity and stay efficient—without wasting developers’ time?

Note the “and”. We’re not choosing between customer centricity and efficiency. We want both, but in a way where the secondary concern does not quietly undermine the primary goal.

Bob pauses. He has never been asked to connect these two worlds: customer centricity, and “efficiency” as protecting capacity.

That “and” question has no off-the-shelf answer. It demands deliberate thinking. So we think it through together:

• What if two developers paired with a customer-experience specialist once a month for on-site visits?
• What if customers joined backlog refinement so engineers could hear feedback directly—no extra meetings needed?
• What if key customer interviews were recorded, and the top three insights were shared with all developers each week?
• What if we trained an LLM to summarize the most relevant customer comments on a given feature?
• What if…?

Now we’re not playing against Bob.

We’re partnering with him to co-create options that honor the primary goal while addressing secondary (and tertiary) concerns. Bob starts to lean in.

He’s not resisting anymore—he’s curious. He’s even a little excited. He’s wanted to explore GenAI, but he was optimizing for a different kind of “efficiency”: keeping developers’ distractions out.

This is what it looks like when a leadership team stays anchored to the org goal instead of letting it erode. It helps prevent “goal drift,” exposes competing commitments early, and turns resistance into design input. 

That’s how improvement efforts stop becoming a diluted compromise and start becoming a coherent path to performance gains—ideally, 10X.