Leadership Misconceptions
Moving from Leader-Follower to Leader-Leader in Software Engineering
For the past two articles, I've been exploring what engineering leaders can learn from the excellent book "Turn the Ship Around" by David Marquet for our leadership practices.
It started with part 1 and some examples of shifting from the Leader-Follower to the Leader-Leader model. In part 2, I shared some exercises, The Leader-Leader Framework, that will help you to discover practices that fit your and your organization's needs related to this transformation.
Today, I want to explore one more thing from the book. Marquet not only shares great ideas for how to lead, but also the biggest misconceptions of leadership that draw us towards the classic leader-follower approach.
"Most empowerment programs are actually consistent with the leader-follower model. They are just less-controlling variants. Someone is still doing the empowering, and someone is still being empowered.
The result is a more respectful version of leader-follower, but leader-follower nonetheless."
"Turn The Ship Around", David Marquet
Misconceptions of Leadership
These misconceptions are dangerous precisely because they feel like good leadership. They're rarely questioned and often celebrated in engineering culture.
We regularly see leaders proudly displaying behaviors that reinforce the leader-follower model:
"We are super efficient. I approve every significant decision, even in the middle of the night, so the team can move on."
"I've mapped out exactly what needs to be built and how for the next three quarters."
"I can speak to any technical detail in our system because I keep an eye on everything."
"My calendar is jam-packed, so I can provide my advice to every single initiative we drive."
These badges of honor are actually red flags. They're precisely what keeps us from actual organizational effectiveness.
Let's identify the common misconceptions that drive us to the leader-follower approach and explore ways to shift to the leader-leader model.
Misconception 1: Good Leaders Know All the Answers
The Myth: Leaders must be technical experts who know everything about their domain and can solve any problem that arises.
The Reality: In complex technical environments like software engineering, no single person can know everything. Good leaders acknowledge knowledge gaps and create environments where collective intelligence thrives.
The Leader-Leader Approach: Ask clarifying questions, challenge assumptions first. "What approach are you considering for this problem?" "What areas of this solution are you uncertain about?" Build a map of the team's competencies. You don't need to know the answers, you need to know which of your teammates is the best to provide them.
The natural step in an engineering leader's career is to take responsibility for the team or domain where you have no needed expertise. It happened to me a few times - from mobile leader, I became head of frontend. From the frontend, I moved to platform/infrastructure leadership.
No matter how hard I tried - first I learned Angular, then React, then Design Systems and MicroFrontends, then Cloud environments, backend architecture, and others - I was no more than an engineering leader with some junior-level skills in particular frameworks or languages. Good enough to drive valuable discussions, way too limited to decide on HOW and WHAT.
There is no shortcut. You must rely on your people.
