Leadership#

Leadership in engineering is not about a title. It’s about influence, direction, and making others more effective. You can lead from any position — as a senior engineer, a tech lead, or even a mid-level developer who steps up during a crisis.

Technical Leadership Without Authority#

Most engineering leadership happens without direct reports. You influence through expertise, communication, and consistent behaviour — not by telling people what to do.

What Technical Leaders Do#

How to Lead Without Authority#

flowchart TD
    A[Identify a problem] --> B[Propose a solution]
    B --> C[Build consensus]
    C --> D[Volunteer to implement]
    D --> E[Document and share]
    E --> F[Others adopt it]
    F --> G[You've led without being told to]

Practical examples:

• Write the RFC for a recurring architectural problem
• Create the PR template the team didn’t know it needed
• Set up the monitoring dashboard that catches issues before users report them
• Document the tribal knowledge that only exists in one person’s head

Mentoring Juniors#

Mentoring is the highest-leverage leadership activity. One hour of good mentoring can save a junior engineer days of struggle and months of learning the hard way.

Effective Mentoring Behaviours#

The Mentor’s Toolkit#

Knowing When to Help vs Let Them Struggle#

flowchart TD
    A[Mentee is stuck] --> B{How long?}
    B -->|< 30 min| C[Let them work - struggle builds skill]
    B -->|30 min - 2 hours| D[Check in: 'How's it going? Any blockers?']
    B -->|> 2 hours with no progress| E[Offer guidance or pair]
    D --> F{Making progress?}
    F -->|Yes| C
    F -->|No| E

Leading by Example#

People follow what you do, not what you say. If you want a team culture of quality, ownership, and openness, you have to model it consistently.

What “Leading by Example” Looks Like#

The gap between what you espouse and what you practice is noticed. Always.

Decision-Making Frameworks#

Technical leaders make many decisions daily. Having frameworks prevents both analysis paralysis and reckless speed.

DACI Framework#

Decision Sizing#

One-Way vs Two-Way Doors (Amazon model)#

• Two-way door — easily reversible. Walk through it quickly, turn around if wrong. (Library choice, API design iteration, feature flag experiment)
• One-way door — hard to reverse. Take time, gather data, get input. (Database migration, public API contract, architectural paradigm shift)

Most decisions are two-way doors that teams mistakenly treat as one-way.

Delegation#

Delegation is not dumping work — it’s investing in others while freeing yourself for higher-leverage activities.

What to Delegate#

How to Delegate Effectively#

flowchart LR
    A[Define the task clearly] --> B[Explain why it matters]
    B --> C[Set expectations: what good looks like]
    C --> D[Agree on check-in points]
    D --> E[Give autonomy between check-ins]
    E --> F[Provide feedback after]

Delegation Pitfalls#

The Staff+ Leadership Shift#

As engineers grow past senior, the work shifts from writing code to multiplying others:

The progression is not about writing more code — it’s about creating more impact through others.

Key Takeaways#

• Leadership is influence, not authority — you can lead from any level
• Mentoring is high-leverage: invest an hour, save someone days
• Lead by example — the gap between words and actions is always noticed
• Size decisions appropriately — most are two-way doors that don’t need an RFC
• Delegate with context and check-ins, not with micromanagement or abandonment
• As you grow, your leverage shifts from personal output to multiplying others