Lighthouse

In one of my first jobs as a software architect, many years ago, my team had to deploy a big update to a banking system. I had been working overtime for three months straight and was going on a much needed Christmas vacation. Therefore, with much reluctance, I delegated the critical deployment to one of the other engineers on the team. But truthfully, I didn't get much sleep in the days leading up to the deployment.

"What if they forget to update the database schema?"
"What if they don't monitor the error rates?"
"What if they don't know when to roll back?"

The urge to grab the keyboard and jump in and do it myself was overwhelming.

A gem cannot be polished without friction, nor a man perfected without trials.
--Seneca

The deployment did go wrong, and I was called up in the middle of the night to help get the system up and running again.

But it was by no means the fault of the engineer, it was all on me. I hadn't set him or my team up for success.

That moment transformed my understanding of engineering leadership. It wasn't about giving up control - it was about creating the conditions for others to succeed.

The False Dichotomy

We often frame leadership as a choice between two extremes.

On one end, the commanding officer barking orders. On the other, the hands-off enabler who avoids providing direction altogether.

Neither works particularly well in todays engineering organizations.

Command-and-control creates bottlenecks, stifles creativity, and drives away top talent. Complete absence of leadership creates confusion, misalignment, lack of ownership and inefficiency.

The most effective engineering leaders I've worked with operate differently. They understand that building high-performing teams isn't about choosing between command and autonomy, it's about transcending this false dichotomy entirely.

Leadership Through Intent, Not Command

In the book "Turn the Ship Around", Submarine Captain David Marquet discovered something groundbreaking: the most effective military leaders don't rely on command authority. When he took over the USS Santa Fe, he flipped the traditional model by announcing he would stop giving orders.

Instead, crew members would state their intended actions: "I intend to... increase reactor power to 100%". This subtle shift created a profound difference. Crew members had to understand the context, consider consequences, and own their decisions.

The results were dramatic. The Santa Fe went from worst-performing to best-performing submarine in the fleet.

This approach, what Marquet calls "Intent-Based Leadership", offers a valuable blueprint for engineering teams. Not because we're running nuclear submarines, even though it sometimes feel like it, but because we face similar challenges:

Complex systems where no single person has complete knowledge
High stakes where mistakes can be costly
Need for rapid decisions without waiting for approval chains

What Marquet also emphasized was that a completely hands-off approach wasn't the solution. For intent-based leadership to work, he established mechanisms - deliberate structures and processes that created the guardrails for empowered decision-making. These included technical competence at all levels and clearly articulated organizational goals. Without these elements, delegation would erupt into chaos rather than controlled empowerment.

The key insight from Marquet's experience on the Santa Fe was that pushing authority down the chain requires simultaneously pushing competence and clarity down as well. This three-part combination – authority, competence, and clarity – created the foundation for true empowerment.

When I implemented elements of this approach with my own teams, I found the biggest challenge wasn't teaching engineers to take ownership - it was unlearning the reflexive command habits that all of us, myself included, had developed over years of traditional management.

Extreme Ownership: The Leader's Responsibility

There are no bad teams, only bad leaders. --Extreme Ownership

This uncompromising principle from former Navy SEAL Jocko Willink might seem harsh, but it contains a powerful truth for engineering leaders. The performance of your team ultimately reflects your effectiveness as a leader.

When deadlines slip, code quality suffers, or team morale drops, the accountability starts with leadership.

This doesn't mean micromanaging or doing everything yourself. Paradoxically, taking "extreme ownership" often means giving more autonomy to your team while retaining accountability for outcomes.

I learned this lesson painfully with the feature launch I describes in the beginning of this article; Because I hadn't created clear alignment around success criteria. My engineer had done exactly what he and I thought was needed, but we didn't plan for the edge cases and failure scenarios. I could have blamed unclear deployment procedures or lack of engagement or monitoring during the nighttime deployment, but the failure was ultimately mine for not establishing proper context and alignment.

Later in my career, when I stood in the same situation, I approached it very differently:

I communicated the strategic "why" behind the task
We established clear success metrics together
I remained available for guidance but gave the engineers decision-making authority
I regularly checked for alignment rather than implementation details

And the results were very different: faster delivery, better quality, and higher satisfaction within the team.

Building the Foundation: Wooden's Leadership Pyramid

John Wooden, famed basketball coach, approached leadership as a methodical process of building character first, skills second.

His Pyramid of Success, explained in the book "Wooden on Leadership" emphasizes fundamental qualities like industriousness, friendship, loyalty, and enthusiasm as the building blocks for achievement. Technical skills matter, but character creates the foundation.

For engineering teams, this translates to hiring and developing for qualities beyond technical proficiency. I look for:

A persistence and care when working through complex problems
Someone who works well with others and contributes to a strong, collaborative environment
A person that can be counted on to deliver on commitments reliably
Initiative in identifying and solving issues
Open to being nudged toward trying new ideas or approaches

I've found that teams built on these fundamentals outperform those assembled purely for technical brilliance. A senior engineer who communicates poorly and resists feedback can undermine an entire team, regardless of their coding abilities.

The Clarity Imperative

"What exactly is it you want me to do here?"

When an engineer asked me this question during a one-on-one, I realized I'd been failing at one of the most fundamental leadership responsibility: providing clarity.

Effective leadership requires absolute clarity in at least four dimensions:

Direction: Where are we going and why?
Roles: Who is responsible for what?
Authority: What decisions can team members make independently?
Standards: What does good look like?

Ambiguity in any of these areas creates friction, wastes energy, and undermines confidence. Engineers spend mental cycles guessing what's expected rather than solving problems.

Claire Johnson, in the book "Scaling People," describes this clarity as the foundation for scaled organizations. Without it, coordination costs skyrocket as teams grow.

I now treat clarity as a primary goal as a leader. Before any initiative, I will do my very best to ensure everyone understands:

The purpose and success criteria
Their specific responsibilities
Their decision-making authority
How their work connects to broader objectives

Providing this clarity doesn't diminish autonomy, it enables it. Engineers and leaders can move quickly and confidently when they understand the boundaries and expectations.

From Manager to Leader: The Critical Transition

The journey from individual contributor to engineering leader often begins with management skills: running meetings, conducting one-on-ones, providing feedback, and coordinating work.

These skills matter, but leadership requires something more.

Camille Fournier, in the book "The Manager's Path," describes this transition as moving from focusing on tasks to focusing on people and systems. Success is no longer measured by what you personally accomplish, but by how you enable others to accomplish more than they thought possible.

This transition rarely happens naturally. Many new engineering managers fall into predictable traps:

Continuing to code rather than focusing on leadership responsibilities
Micromanaging technical decisions rather than setting context
Solving problems directly rather than developing team problem-solving capacity
Measuring success by output rather than outcomes

I've made every one of these mistakes. The hardest lesson is learning that sometimes the best leadership action is to ask questions rather than provide answers, even when you know the solution.

Building Systems for Empowerment

Intent-based leadership doesn't emerge spontaneously. It requires deliberate systems that enable ownership while maintaining alignment.

In my experience, these systems include:

Clear decision frameworks: Explicitly defining which decisions require consensus, consultation, or can be made independently
Context communication rituals: Regular sessions to share organizational context and strategic priorities
Failure recovery processes: Clear protocols for when things go wrong that focus on learning rather than blame
Recognition systems: Acknowledging and celebrating ownership behaviors, not just outcomes
Knowledge distribution mechanisms: Ensuring critical information doesn't remain siloed

The most effective leaders I've worked with recognize that their job isn't to make every call, but to create an environment where good decisions happen naturally.

When Command Still Matters

Despite everything I've written above, there are moments when direct command remains not only appropriate but necessary in engineering leadership:

Clear vision: Setting a clear vision and providing guardrails for the company or department.
Crisis situations: During major outages or incidents, clear direction can be essential
New team members: Who may need more explicit guidance initially

The key is deliberately choosing when to be directive rather than defaulting to it out of habit or insecurity.

The Path Forward

Engineering leadership continues to evolve. The command structures passed down from the industrial era of management, are increasingly ineffective for knowledge work that requires creativity, adaptation, and specialized expertise.

Yet complete abandonment of leadership direction creates its own problems. The sweet spot lies in creating clarity of purpose, context, and expectations while giving teams the autonomy to determine how best to achieve those outcomes.

Be a leader that:

Takes full ownership of team outcomes
Create systems that enable distributed decision-making
Drive clarity in all dimensions
Develop people rather than directing tasks

This approach isn't easy. It requires humility, patience, and a willingness to invest in systems rather than heroic individual efforts. But the results, engaged teams, sustainable performance, and innovative solutions - speak for themselves.

The future belongs to leaders who understand that commitment can't be commanded, it can only be cultivated.

Leading With Clarity