I recently read Turn the Ship Around by David Marquet, and a lot of it resonates with me. The idea of delegating decision-making authority to the people closest to the problem - the “leader-leader” model rather than “leader-follower” - has always made intuitive sense to me. It works especially well with competent teams who have a genuine investment in the outcome.
But applying this principle to software development companies raises some challenging questions.
Who is Closest to the Problem?
In a typical software organization, we often have Product Managers talking to customers and gathering requirements, while Engineers write the code that implements those requirements. The question becomes: who is actually closer to the problem?
- Is it the Product Manager who understands the customer’s pain points and business context?
- Is it the Engineer who understands the technical constraints and implementation details?
- Should these be two different people, or should someone span both?
The Information Asymmetry Challenge
There’s another layer to this. In many organizations, engineers at the rank and file level are almost never included in strategy meetings. They receive a spec to implement and are expected to execute.
In this scenario, what are the chances of a leader-leader model actually working?
The engineer implementing a feature often lacks visibility into:
- Why this feature was prioritized over others
- What the competitive landscape looks like
- How this fits into the broader product roadmap
- What constraints the business is operating under
Without this context, can they truly make informed decisions that align with organizational goals?
When Information Asymmetry Becomes a Tool
There’s also a darker dimension to this. Information asymmetry can sometimes be weaponized - intentionally maintained to create controlled chaos, slow down potential competition, or maintain the status quo.
If we’re serious about implementing a leader-leader model, what qualities should we look for in:
- Our peers: People who can collaborate across boundaries without needing hierarchical authority
- Those reporting to us: Engineers who can make decisions with incomplete information while still shipping quality work
- The organization: Systems and processes that enable rather than hinder autonomous decision-making
The Questions I Keep Coming Back To
- How do we decide who gets to be “closest to the problem” in a software context?
- Is it possible to bridge the information gap without overwhelming engineers with context that isn’t relevant to them?
- What organizational structures either enable or disable the leader-leader model?
- How do we identify when information asymmetry is a feature vs. a bug in our culture?
These are questions I’ve been thinking about, not problems I’ve solved. I’d be curious to hear how others have approached this in their organizations.