The Leader-Leader Framework

How to Implement the Leader-Leader Approach in Your Engineering Team

In the previous article, we explored David Marquet's Leader-Leader approach and how it shifts the mindset from permission-seeking to intent-driven leadership. Based on the lessons from "Turn The Ship Around", I brought some examples from my engineering leadership practices.

Today, I want to take a step back and explore a simple, actionable framework for finding practical steps to apply these principles in your engineering team.

Leader-Leader Model: Core Concepts

David Marquet discovered a fundamental truth: simply "empowering" individuals doesn’t do much without the proper supporting mechanisms.

A famous quote says:

"Leadership is communicating to people their worth and potential so clearly that they are inspired to see it in themselves."

Sure, that makes sense when elevating talented people who face self-doubt and are at the beginning of their careers. But there is no shortage of self-confident people among software engineers, who are sure about their skill set.

With that in mind, what's critical are the systematic changes to how the organization functions. Marquet identified three critical mechanisms that enable this transformation:

• control

• clarity

• competence

These mechanisms form the basis for an effective Leader-Leader culture by redistributing authority, clearly defining purpose and context, and continuously building expertise within the team.

Side note: In the book, "Wiring Winning Organizations" there is a similar emphasis. Instead of focusing on individuals, tools, instrumentation, or technicalities, the author concentrates on improving "Social Circuitry". That is - the layer that includes the processes, standards, and communication patterns that guide how people work together. Read more here.

Control, Clarity, Competence

Let's briefly introduce each of these core mechanisms before we dive deeper into the practices:

• Control Mechanisms: Shifting from external control to intrinsic motivation by pushing decision-making authority to where the information lives. In Marquet's words: "Don't move information to authority, move authority to the information." On the submarine, this meant no longer requiring permission but instead using the language of intent: "I intend to..." This signaled both ownership and forethought.

• Clarity Mechanisms: Ensuring everyone understood the organization's purpose and how their decisions served it. As Marquet puts it: "We achieve excellence not by telling people what to do, but by letting them take action based on the guiding principles and goals of the organization."

• Competence Mechanisms: Building the technical excellence needed to handle that control effectively. After David Marquet: "Control without competence is chaos." The Santa Fe submarine implemented technical competence programs to ensure every sailor had the knowledge to execute their authority responsibly.

What makes a transformation remarkable is not any single practice but how these three mechanisms reinforce each other.

Control without competence leads to errors; competence without clarity leads to wasted effort; clarity without control leads to frustration.

9-grid Leader-Leader Model

Each of these mechanisms has three actionable practices, creating a simple yet powerful 9-grid framework. Let's see how we can adapt it to the world of software engineering leadership.

Control Mechanisms

1. Delegate Control: Shift ownership by encouraging engineers to state intentions ("I intend to change proposed UI/UX...") rather than seeking permission ("Can we change UI/UX?").

2. Push Authority Downward: For example, create clear, documented decision-making levels. For instance, level 1 might allow anyone to decide test approaches, while significant architecture changes require broader consensus and involvement of Enabling Team (check the Team Topologies for more) of Software Architects.

3. Communicate Intent: Define clear success metrics instead of prescribing exact implementation methods. For example, "feature must handle 1000 concurrent users with response times under 200ms." For better clarity and alignment, you can use Non-Functional Requirements.

   

Clarity Mechanisms

4. Align on Purpose: Begin each sprint with clear "mission briefings," explicitly connecting tasks to business outcomes (e.g., by fixing issues we aim to improve customer satisfaction metrics; by adding changes to the flow, we will increase number of successful transactions; this functionality will open our platform to new market).

5. Share Organizational Context: Create dashboards linking engineering metrics (deploy frequency, bug rates) with business outcomes (revenue, user growth) to highlight the impact clearly. Don't see the connection? Finding it can be a good exercise for you when seeking the "WHY".

6. Improve Transparency: Maintain accessible logs for technical decisions, detailing context, options, and rationale to empower future decision-makers (Lightweight ADRs). It works two ways - publishing technical telemetry will help prioritize tech work in the product backlog. Showing product metrics will build understanding of why we do software engineering (Organizational Context).

Competence Mechanisms

7. Establish Technical Excellence: Develop internal certification paths for technical mastery in key areas (e.g., database optimization specialists achieving measurable performance improvements). Such certification can be a good way to develop Enabling Teams, like Data Infrastructure, SRE, AI Infra, etc.

8. Enable Continuous Learning: Set regular time (like "Exploration Fridays") for targeted skills development, including structured feedback sessions. Run "Post Mortem" practices. Do weekly reviews of SLOs/SLIs/KPIs and learn from them. It's also an excellent exercise to have mature discussions about data and facts. E.g., the team looks at crash rates not to blame anyone, but to identify root causes of spikes and drops.

9. Improve Knowledge Distribution: Adopt a "teach to learn" model where engineers share knowledge gained from solving complex issues or adopting new technologies. Running Engineering Guilds can be an excellent example of knowledge distribution.

A Simple "How Might We..." Exercise

The framework I'm sharing today is designed as a collaborative exercise you can do with your engineering teammates or with fellow technical leaders if you lead a wider engineering organization.

Here's a straightforward way to start:

1. Gather your team and present the 9-grid Leader-Leader framework.

2. Ask the team to identify the three most impactful practices that need immediate improvement.

3. For each selected practice, facilitate a brainstorming session around the question: "How might we...?"

4. Turn them into specific actions with owners and timelines.

5. Start small - implement one change per mechanism first.

6. Review progress after 30 days and iterate.

To do the exercise, you can use the FigJam board of Leader-Leader Framework from Practical Engineering Management.

Example Workshop Output

Here's an example of what the output from a team workshop might look like:

Selected Practice 1: "Delegate Control"

• "How might we" ideas:

  • "How might we shift from permission-seeking to intent-based communication?"

  • "How might we empower engineers to make more decisions without approval?"

  • "How might we build confidence in autonomous decision-making?"

• Next steps: Implement "I intend to..." language pattern in product-tech discussions. For example, instead of "Can we change the UI/UX approach?" engineers will approach UI/UX designers directly and say "I intend to simplify the navigation UI by using existing Design System components, reducing implementation time from 2 weeks to 2 days while maintaining consistent user experience."

Selected Practice 2: "Improve Transparency"

• "How might we" ideas:

  • "How might we make technical performance visible to non-technical stakeholders?"

  • "How might we connect technical metrics to business outcomes?"

  • "How might we build shared understanding across departments?"

• Next steps: Build integrated dashboards that translate technical telemetry (error rates, performance metrics, deployment frequency) into business-relevant terms. Present these monthly to senior management and other departments to create shared context.

Selected Practice 3: "Enable Continuous Learning"

• "How might we" ideas:

  • "How might we create structured knowledge sharing across teams?"

  • "How might we learn systematically from both failures and successes?"

  • "How might we build communities of practice around key technologies?"

• Next steps: Implement blameless Post-Mortem practices for all incidents, focusing on systems thinking rather than individual mistakes. Establish Engineering Guilds for key technology areas (Frontend, Backend, DevOps) that meet bi-weekly and present ideas and solutions from engineers across the organization.

Next Steps

Start small. Pick one or two practices to pilot, measure the impact, gather feedback, and iterate. This method aligns perfectly with Marquet's ethos of enabling competence through autonomy rather than demanding it beforehand.

Remember, the ultimate goal is not immediate perfection—it's about establishing a culture of proactive leadership and continuous improvement.

Stay tuned for the next article, where we will discuss key differences and common misconceptions in Leader-Leader vs. Leader-Follower Models.

Complementary Articles to Help You with the Leader-Leader Model

Here are more articles from Practical Engineering Management that can aid you in implementing the Leader-Leader model:

1. Top-down Leadership vs Center-out Leadership

2. Developmental Leadership vs. Transactional Leadership

3. Safety Leadership and Neuroception

4. Intro to Expectations Management

5. Simplification Through Linearization