Shift from a Leader-Follower to a Leader-Leader Approach

SubscribeSign in

Shift from a Leader-Follower to a Leader-Leader Approach<br>What a U.S. Navy Captain Can Teach Us About Engineering Leadership

Mirek Stanek<br>Apr 21, 2025

34

Share

Even though today we lead people, we've most likely climbed the engineering ladder through technical excellence. Our code was cleaner, architectures more elegant and scalable, and solutions we built did work.<br>Now, when we lead a team of engineers, we may feel that our efficiency has faded. The team waits for our decisions, innovation barely moves forward, and despite working longer and harder, we're becoming the bottlenecks we swore we'd never be.<br>This is quite a common situation that makes us doubt whether we are the right people for managerial positions. But here's what everyone misses about technical leadership: the very expertise that got us promoted is now our most significant liability.<br>Practical Engineering Management is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

Subscribe

"Turn The Ship Around"

When I asked various leaders about their book recommendations, the most common answer was: "Turn The Ship Around" by Navy Captain David Marquet. I even included this book in my Top 10 Book Recommendations for Engineering Leaders (as the community pick).<br>I have finally caught up with Marquet's story about taking command of the USS Santa Fe, the worst-performing submarine in the fleet. The book brought me this realization: Even though none of my teams was the "worst-performing," I often asked myself how it is even possible that sometimes smaller groups of engineers move much faster than we did.<br>Over the years, I went through multiple transformations:<br>From Quality Control to Quality Assurance

From siloed to cross-functional teams

From fixed big-bang releases to continuous delivery

From coders to product engineers

And I always wondered - what are the common points that made these initiatives successful?<br>These days, after reading "Turn The Ship Around," I'm pretty sure that Marquet's "Leader-Leader" model can be one of the frameworks that works well in engineering organizations.

The Dangerous 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."

Sound familiar?<br>Many of these activities are seen as good practices in software engineering. Peer reviews are the foundation of effective shift-left testing transformation.<br>But as a leader, you are no longer a "peer." You may convince yourself that you ensure quality. But what you actually do is train the team in learned helplessness.<br>Here's the uncomfortable truth: your expertise-driven micromanagement is creating:<br>A decision bottleneck (you)

Disengaged engineers who stop thinking critically

A fragile organization that collapses when you're on vacation

The data backs this up. Google's Project Oxygen found that "technical expertise" is ranked last among traits of effective managers. What ranked top? Being a good coach and empowering teams without micromanaging.<br>Here's the full list, by the way:<br>8 key behaviors of effective managers<br>Is a good coach

Empowers team and does not micromanage

Creates an inclusive team environment, showing concern for success and well-being

Is productive and results-oriented

Is a good communicator — listens and shares information

Supports career development and discusses performance

Has a clear vision/strategy for the team

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.<br>But if control isn't the answer, what is?<br>The Intent: Shift From Permission to Purpose

When Marquet took command of the Santa Fe, 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.<br>When I worked in a Permission-Seeking Culture , we very often had situations like this:<br>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?"

Myself: "What exactly do you want to change?"

Engineer: "The sizing and default behavior of the navigation."

Myself: "Let me look at it first and check with the UI Designer..."

After implementing Intent-Driven Leadership , the conversation was closer to:<br>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?" (This was D. Marquet's default question)

Engineer: "You're probably wondering if this aligns with the Product team's vision of how UI/UX should...