Product development guiding principle: Enable autonomy with clear intent and technical excellence

Jason Yip
2 min readJul 17, 2022

Guiding principle in effective product development culture.

“Control, we discovered, only works with a competent workforce that understands the organization’s purpose. Hence, as control is divested, both technical competence and organizational clarity need to be strengthened.”

Marquet, L. David. Turn the Ship Around!: A True Story of Turning Followers into Leaders

Mindspring created a nice visualisation of this concept in an animation of a L. David Marquet talk on “Greatness”:

“Give control” on top of two pillars: “Competence” and “Clarity”
Giving control relies on the pillars of technical competence and organisational clarity

“Giving control” is essentially “enabling autonomy”.

Instead of “technical competence”, I usually say “technical excellence”.

Instead of “organisational clarity”, I usually say “clear intent”.

So, autonomy is enabled by clear intent and technical excellence. The more clarity and technical excellence you provide, the more autonomy is enabled.

Why?

Lack of clear intent leads to inaction OR incoherent action.

When there is a lack of clear intent, people generally respond in one of two ways:

  1. They slow down or freeze up. The lack of clarity is like trying to navigate an unmarked minefield. It’s unclear what path is safe or not;
  2. They act anyway but not with any kind of overall coherence.
Decision tree with root of Lack of Clear Intent. Branch 1: Most people “Uh, we’re not comfortable proceeding quickly without more clarity…” Branch 2: Some people “Leeeroooooy Jeeeenkins!”
Lack of clear intent leads to inaction/slowing down or incoherent action

There are no autonomous teams with an overly coupled architecture.

If every “autonomous” team has to coordinate with every other “autonomous” team because they’re all working on the same coupled architecture, they’re not actually autonomous.

Shared monolith in the middle with 4 “autonomous” teams linked to it
Teams are not actually autonomous if the architecture is overly coupled

“Everything broken all the time” is not the kind of autonomy we’re looking for.

Alternatively, if teams just do whatever they feel like on the same coupled architecture, causing the overall system to be broken all the time, the teams are technically autonomous but this is not the kind of autonomy we’re looking for.

Shared monolith with a lot of teams depending on it. One developer asks: “Will this change break things for other teams?” Another developer responds: “We’re autonomous! Leeeroooooy Jeeeenkins!”
Breaking everything without consideration of others is not the kind of autonomy we’re looking for

References

--

--

Jason Yip

Senior Manager Product Engineering at Grainger. Extreme Programming, Agile, Lean guy. Ex-Spotify, ex-ThoughtWorks, ex-CruiseControl