From Leader-Follower to Leader-Leader: Engineering Management Lessons from the USS Santa Fe

Many engineering leaders find themselves in a frustrating paradox: the technical expertise that propelled them into management positions now makes them the very bottlenecks they once criticized. Teams wait for decisions, innovation stalls, and despite working longer hours, the leader becomes the single point of failure. This common situation leads many to question whether they're cut out for management.

The uncomfortable truth is that the very expertise that got us promoted can become our most significant liability. As Google's Project Oxygen discovered, "technical expertise" ranks last among traits of effective managers. What matters most is being a good coach who empowers teams without micromanaging.

The Illusion of Control

"All pull requests need to be approved by me." "Let me review that code before you proceed." "Before you push to production, run that deployment plan by me first."

These phrases, while seemingly good practices for quality control, create dangerous illusions of control. As leaders, we're no longer peers in the technical process, and our well-intentioned oversight trains teams in learned helplessness. The result is a decision bottleneck (you), disengaged engineers who stop thinking critically, and a fragile organization that collapses when you're on vacation.

Google's research identified eight key behaviors of effective managers, with technical skills ranking last:

1. Is a good coach
2. Empowers team and does not micromanage
3. Creates an inclusive team environment, showing concern for success and well-being
4. Is productive and results-oriented
5. Is a good communicator — listens and shares information
6. Supports career development and discusses performance
7. Has a clear vision/strategy for the team
8. Has key technical skills to help advise the team

The message is clear: technical expertise matters, but it's necessary rather than sufficient. Your ability to develop and empower others is the true differentiator.

The Intent: Shift From Permission to Purpose

When Captain David Marquet took command of the USS Santa Fe, the worst-performing submarine in the fleet, he made a radical decision. Instead of giving orders, he trained his crew to state: "I intend to..."

This small language shift triggered a transformation with stunning results. Consider the difference between permission-seeking and intent-driven approaches:

Permission-Seeking Culture:

Engineer: "I got mockups from the UI designer, which will take weeks to implement due to how custom they are. Can we simplify that a bit?" Leader: "What exactly do you want to change?" Engineer: "The sizing and default behavior of the navigation." Leader: "Let me look at it first and check with the UI Designer..."

Intent-Driven Leadership:

Engineer: "I intend to simplify the navigation UI/UX so we can implement that within 2 days instead of 2 weeks. I want to reuse components that already exist in our Design System" Leader: "What do you think I'm wondering right now?" Engineer: "You're probably wondering if this aligns with the Product team's vision of how UI/UX should look like" Leader: "Exactly. Convince me it's the right move." Engineer: "I've checked with the Product Designer and showed them existing components which look almost the same as their new proposition. I want to use them instead of the custom ones" Leader: "Is it the right thing to do?" Engineer: "Yes, because we will push it to customers a few weeks earlier, UX will be aligned with the rest of our application. We can always iterate over it later"

The intent-driven approach forces engineers to think deeply about the why, the how, and the verification. It creates competence rather than compliance. As Marquet puts it, "if you want your people to think, don't give instructions—give intent."

To implement this in your team:

• Ban the phrase "Can I..." from technical discussions
• Train your team to use "I intend to... because..." instead
• Resist the urge to approve/reject; ask clarifying questions instead
• Create clear guardrails (architecture principles, non-functional requirements) rather than checkpoints

The Competence Paradox

"But my team isn't ready for this autonomy," you might be thinking. Here's the thing: Competence doesn't precede autonomy; it emerges from it.

When Marquet first implemented his leader-leader model, his crew made mistakes. But instead of reverting to command-and-control, he doubled down on building the necessary knowledge. This approach rests on what Marquet calls "the two pillars" that support giving control:

1. Technical competence (Is it safe?)
2. Organizational clarity (Is it the right thing to do?)

For engineering teams, this may mean implementing deliberate action protocols:

• Code review policies that require explaining the intent behind changes
• Pre-deployment checklists that engineers go through before pushing to production
• Architecture Decision Records (ADRs) that document reasoning, not just decisions

One practical example comes from a mobile app team that pushed releases on Fridays. Initially, the leader was involved in all release decisions. Eventually, the team took complete ownership:

• Deciding whether to go live or skip the week
• Determining the rollout process
• Assessing risks independently

The technical competence elements that made this possible included:

• Pushing to beta channels or limited audiences first
• Using feature flags for critical features
• Having automated testing and deployment processes enabling hotfixes in under an hour
• Rich telemetry and monitoring for proactive issue detection
• Clear objectives and KPIs (e.g., SLOs) defining standards

Thinking Out Loud as Standard Practice

In traditional engineering organizations, senior engineers solve problems silently. When an incident is reported, you might hear "ok, I will check" followed by dead silence. In the worst case, the system mysteriously starts working again. In more optimistic cases, you eventually hear "ok, done. I've fixed the NPE in our app."

Less experienced engineers see the solution but miss the mental process that led there—the equivalent of showing the answer without the work.

When a senior engineer verbalizes their thought process—"I'm not sure why this is failing. Let me try looking at the logs first, then check if the config was updated correctly, and then verify the network connections"—they're demonstrating their troubleshooting mental model.

This verbalization of thought processes is what Marquet encouraged on the Santa Fe, and it's a powerful practice for software teams. This practice creates shared mental models faster than any documentation ever could. The goal isn't perfect solutions but visible thinking—because visible thinking creates learning opportunities that silent expertise never will.

The Control Shift: From Knowing to Learning

Most engineering leaders rose through the ranks by knowing more than others. Now you need to flip the script: your job isn't to know, it's to create an environment of continuous learning.

This means:

• Normalizing the phrase "I don't know, let's find out"
• Conducting blameless postmortems that focus on system improvement
• Budgeting time specifically for exploration and experimentation

This shift requires letting go of your identity as the expert. As Marquet notes, "It takes strength and confidence to give up control and say, 'I will be here if you need me, but it's your play.'"

Effective techniques include:

• When an engineer asks a question, resist answering immediately. Ask "What do you think?", "What have you tried so far?", "What else are you planning to do?"
• Creating safe spaces for discussing issues before presenting them to larger audiences
• Implementing knowledge-sharing practices like Engineering Guilds

The Leadership Paradox

On traditional engineering teams, one person gives orders, and everyone else follows instructions. As Marquet puts it: "On another submarine, there was one guy in charge, one guy giving orders, one guy thinking, and 134 people doing what they're told. I don't care how smart you are. On my submarine, I got 135 thinking, active, passionate, creative, proactive, taking initiative people."

When you stop giving answers and start asking the right questions, you don't diminish your impact—you multiply it across your entire team. The next time an engineer asks for permission, respond with: "What do you intend to do, and why?" Then, watch as they begin the journey from technician to leader.

Your greatest achievement won't be the code you wrote or the architecture you designed. It will be the leaders you created who continue to build and innovate long after you've moved on.

Implementation Roadmap

To transition from a leader-follower to a leader-leader approach:

1. Start with language shifts: replace "Can I..." with "I intend to..."
2. Create clear technical and organizational guardrails
3. Implement deliberate action protocols for critical processes
4. Encourage verbalization of thought processes during problem-solving
5. Shift from providing answers to asking questions
6. Create safe spaces for learning and experimentation
7. Gradually increase autonomy as competence develops

The transformation won't happen overnight, and there will be missteps along the way. But as Marquet demonstrated with the USS Santa Fe, the results—measured in both performance and team satisfaction—can be extraordinary.

As you implement these changes, remember that "you create the environment so that those people are out there making decisions as if the CEO were standing right behind them. And if it's not the same decision, it's actually a better decision because they have the information."

For further reading on this approach, I highly recommend David Marquet's "Turn The Ship Around" and Google's research on effective managers. The journey from expert to enabler is challenging but ultimately more rewarding—for both you and your team.