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.
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.
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.
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).
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.
Over the years, I went through multiple transformations:
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?
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.
"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?
Many of these activities are seen as good practices in software engineering. Peer reviews are the foundation of effective shift-left testing transformation.
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.
Here's the uncomfortable truth: your expertise-driven micromanagement is creating:
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.
Here's the full list, by the way:
8 key behaviors of effective managers
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.
But if control isn't the answer, what is?
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.
When I worked in a Permission-Seeking Culture, we very often had situations like this:
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:
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 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"
Another case:
One more:
Notice the difference? The intent-driven approach forces the engineer 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 results can be dramatic.
How did the story end with the requested UI/UX changes?
It turned out that the UI designer didn't know that subtle changes would require the entire rework of navigation components. Once they learned we could push changes within the same week, it was already a huge win for them. For us, it meant no custom logic, no extra tests, and just reuse of existing components.
Win-win.
"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:
Technical competence (Is it safe?)
Organizational clarity (Is it the right thing to do?)
For engineering teams, this may mean:
On Marquet's submarine, sailors would touch equipment and verbally state their intention before operating it.
For your team, you can create similar 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 of the teams I led pushed things to production on Fridays. It was a mobile app, and the assumption was that Friday was always a nice closure of the week of work.
At some point, I disconnected completely from these releases. The team decided whether to go live or skip the week, what the rollout process was, what the risks were, etc.
Marquet's Technical Competence elements in our context were:
The app was usually pushed to the beta channel (or just to a few percent of the audience)
Critical and/or big features were hidden behind feature flags anyway, so the customer release was detached from the production push
We could push a hotfix in less than 1 hour (fully automated testing and deployment process)
Rich telemetry and monitoring informed us about any malfunctions proactively
We had a clear set of objectives and KPIs (e.g., clear SLOs) that defined standards the team had to maintain
Put together, it created a clear action protocol for the team so they could work autonomously.
In traditional engineering organizations, senior engineers solve problems silently. The flagship example is when you report an incident - "ok, I will check" and then dead silence.
In the worst-case scenario, the answer will never come back; the system will start working by itself. In more optimistic cases, after some time, you will hear, "ok, done. I've fixed the NPE in our app." In such cases, 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 says, "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.
Side note - thinking out loud is also a competence often checked during System Design interviews, where the final answer to the recruiter's question doesn't count as much as the thinking process that led you there. On that occasion, I recommend reading the great books by Alex Xu: System Design Interview
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.
Side note 2 - reporting an issue (and the rest of the process - acknowledging, fixing, confirming) is a subject on its own that can draw from Control Theory. If you want to check good practices and read about common mistakes, have a look at my article "Amplification - Make Signals Loud and Clear"
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:
Normalize the phrase "I don't know, let's find out"
Conduct blameless postmortems that focus on system improvement
Budget 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.'"
Here are a few of my favorite techniques at work:
When an engineer asks you a question, resist the urge to answer immediately. Ask "What do you think?", "What have you tried so far?", "What else are you planning to do?". Let them lead and build your answers upon that.
It's easier to say something is "blameless" than to make your team feel this way. What often helps me are regular conversations about issues within a safe space. So before you show your crash rate at the company's all-hands meeting, check it every week with your team, discuss all drops and spikes, and build confidence within your people. "Yes, we had a drop in stability last week. The root causes are performance issues in our services. The work is already well described and planned, but as a team, we highly advise setting a higher priority to avoid similar issues in the future."
In bigger organizations, one of the most effective knowledge-sharing practices is Engineering Guilds, which I recently described in this series of articles.
As Marquet discovered on the Santa Fe, the fastest way to improve results isn't to focus obsessively on results—it's to build a team capable of continually learning and improving.
When you shift from being the answer provider to the learning enabler, you remove yourself as the bottleneck and unlock your team's full potential.
On traditional engineering teams, one person gives orders, and everyone else follows instructions.
As Marquet puts it in his "What is leadership?": "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.
But won't that create chaos, with everyone going in different directions? No, because "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."
If David Marquet's leader-leader approach resonates with you, I invite you to check out the next article, in which I will share a practical exercise that can help you implement it in your team or organization.
In the meantime, I also recommend reading "Turn The Ship Around", as the book is a treasure trove of leadership practices.
Here are more articles from Practical Engineering Management that can aid you in implementing the Leader-Leader model: