Technical Leadership

Technical leadership—the ability to influence technical direction, raise the quality bar, and multiply team effectiveness—is the defining characteristic of senior+ engineers. Understanding this path is essential for advancing beyond mid-level roles.

What is Technical Leadership?

Beyond Writing Code

Technical Leaders:

• Set technical direction
• Mentor and multiply others
• Make architectural decisions
• Represent team to stakeholders
• Improve engineering culture
• Navigate ambiguity
• Build consensus

NOT (necessarily):

• People managers
• The most senior person
• The best coder
• Extroverted or outgoing

The Leadership Ladder

IC (Individual Contributor) Progression:

Junior → Mid → Senior → Staff → Principal → Distinguished

Leadership Scope:
Junior:     Tasks
Mid:        Features
Senior:     Projects
Staff:      Team/Domain
Principal:  Department/Product
Distinguished: Company/Industry

Time Allocation Shift:

Junior:   100% coding
Mid:       90% coding, 10% mentoring
Senior:    70% coding, 30% leadership
Staff:     40% coding, 60% leadership
Principal: 20% coding, 80% leadership

Core Leadership Skills

1. Technical Vision

Setting Direction:

• Identify technical debt priorities
• Propose architectural improvements
• Champion engineering practices
• Drive technical initiatives

Example:

Problem: Slow deployment cycles (2 weeks)

Vision:
"We should implement CI/CD for:
- Faster feedback (minutes not weeks)
- Reduced deployment risk
- Increased developer velocity

Approach:
Phase 1: Automated testing
Phase 2: Staging environment
Phase 3: Automated deployments

Timeline: 3 months
ROI: 10x faster deployments

2. Influence Without Authority

Not: "Do this because I said so"

But: "Here's why this approach benefits us..."

Influence Tactics:

Data-Driven:

"Switching to TypeScript could prevent 15% of bugs 
(Microsoft study). In our codebase, that's ~30 bugs/month.
At 2 hours/bug, that saves 60 hours/month."

Risk Framing:

"Without refactoring this module, we're accumulating 
technical debt that will:
- Block feature X (requested by top customer)
- Require 2x the time to add features
- Make onboarding harder (3 weeks vs 1 week)"

Proof of Concept:

"I spent a spike exploring GraphQL. Here's a working 
prototype showing 50% less API calls and better type 
safety. Would this be worth adopting?"

Social Proof:

"Companies like Airbnb, Netflix, and Spotify have moved 
to microservices for similar scaling needs. Here's their 
documented learnings..."

3. Mentorship and Multiplication

Multiplier Mindset:

• One senior engineer coding: 1x impact
• Senior engineer mentoring 5 others: 5x impact
• Senior engineer improving systems: 50x impact

Effective Mentoring:

Pair Programming:

• Junior drives, senior navigates
• Explain reasoning out loud
• Gradual reduction of support
• Focus on problem-solving process

Code Review as Teaching:

❌ "Use const instead of let"
✅ "Using const here signals that this value won't 
   change, which helps readers understand the code 
   and prevents accidental reassignment bugs. 
   
   Rule of thumb: Default to const, use let only 
   when you need to reassign."

Creating Learning Resources:

• Internal tech talks
• Documentation wiki
• Architecture decision records (ADRs)
• Onboarding guides
• Video tutorials

Delegation:

Level 1: "Do exactly this"
Level 2: "Research options and propose solution"
Level 3: "Own this problem end-to-end"
Level 4: "Identify and solve problems in this area"

4. Communication and Writing

Technical Writing:

• Design documents
• Architecture proposals
• RFCs (Request for Comments)
• Post-mortems
• Technical blog posts

RFC Template:

# Title: [Problem/Solution]

## Context
What's the background? Why now?

## Problem
What specific problem are we solving?

## Goals
What are we optimizing for?

## Non-Goals
What are we explicitly not doing?

## Proposed Solution
Detailed technical approach

## Alternatives Considered
Why not approach X, Y, Z?

## Trade-offs
Pros, cons, and risks

## Open Questions
What needs discussion?

## Timeline
Milestones and dependencies

Stakeholder Communication:

Technical → Non-Technical Translation:

❌ "We need to refactor the monolith into microservices 
   using event-driven architecture with CQRS"

✅ "We're reorganizing our code to enable:
   - Faster feature development (2x speed)
   - Better handling of high traffic
   - Easier to add team members
   
   Trade-off: 3-month investment upfront"

5. Technical Decision Making

Decision Framework:

1. Gather Context:

• What's the actual problem?
• Who's affected?
• What are constraints?
• What's the timeline?

2. Generate Options:

• Brainstorm 3+ alternatives
• Consider doing nothing
• Research industry practices

3. Evaluate Trade-offs:

Option A: Microservices
Pros: Scalability, team autonomy
Cons: Complexity, operational overhead
Risk: Distributed debugging
Cost: High

Option B: Modular Monolith
Pros: Simpler, easier to maintain
Cons: Scaling limits
Risk: Coupling over time
Cost: Low

Decision: B (because team size < 20, traffic manageable)

4. Document Decision:

• ADR (Architecture Decision Record)
• Why this option?
• What did we consider?
• What are the risks?
• How will we know it's working?

5. Communicate Broadly:

• Share with stakeholders
• Explain reasoning
• Be open to feedback
• Commit to decision

6. System Thinking

See the Big Picture:

Feature Request: "Add user notifications"

Junior thinks: "I'll add an email service"

Senior thinks:
- Delivery channels? (Email, SMS, push, in-app)
- Scalability? (1M users, 10M notifications/day)
- Reliability? (Critical vs nice-to-have)
- User preferences? (Opt-in/out, frequency)
- Analytics? (Delivery rates, engagement)
- Failure modes? (Rate limiting, retries)
- Cost? (Sendgrid pricing, infrastructure)
- Privacy? (GDPR, data retention)

Ask Deeper Questions:

• "Why are we building this?"
• "What problem does this solve?"
• "How will we measure success?"
• "What could go wrong?"
• "How does this fit our strategy?"

Leadership Styles

The Four Archetypes (Will Larson)

Tech Lead:

• Scope: Single team
• Focus: Execution excellence
• Activities: Architecture, unblocking, quality
• Impact: Project success

Architect:

• Scope: Multiple teams
• Focus: Technical direction
• Activities: System design, standards, evangelism
• Impact: Consistent architecture

Solver:

• Scope: Gnarly problems
• Focus: Deep technical work
• Activities: Research, prototyping, fire-fighting
• Impact: Impossible made possible

Right Hand:

• Scope: Leadership support
• Focus: Leadership force multiplication
• Activities: Execution, communication, culture
• Impact: Organisation effectiveness

Find Your Fit: Most staff+ engineers specialize in 1-2

Staff Engineer Responsibilities

Strategic Work

Technical Strategy:

• Multi-quarter roadmap
• Technical vision alignment
• Investment prioritization
• Identify leverage points

Example:

Q1: Observability (enable debugging)
Q2: Performance (improve UX)
Q3: Developer experience (increase velocity)
Q4: Security (reduce risk)

Each quarter builds on previous

Organisational Work

Improving Systems:

• Hire and onboard engineers
• Define engineering levels
• Create career ladders
• Design interview process
• Build engineering culture

Cross-Team Collaboration:

• Break down silos
• Share learnings
• Standardise practices
• Facilitate communication

Visibility Work

Making Work Visible:

• Tech talks
• Blog posts
• Internal newsletters
• Lunch & learns
• Conference talks

Why: Sharing knowledge multiplies impact

Glue Work

Connecting the Dots:

• Identify missing pieces
• Facilitate conversations
• Unblock teams
• Fill gaps

Example:

Noticed: Teams A and B building similar features

Action:
1. Connected teams
2. Identified shared needs
3. Proposed shared library
4. Facilitated collaboration

Result: Saved 6 person-months of duplicate work

Building Your Technical Leadership

1. Start Where You Are

Junior/Mid-Level:

• Lead small initiatives
• Mentor interns
• Improve documentation
• Fix process pain points
• Volunteer for cross-team work

Senior:

• Own significant features
• Lead technical decisions
• Mentor multiple engineers
• Drive architectural changes
• Represent team externally

2. Develop Written Communication

Practice:

• Write design docs
• Document decisions
• Contribute to blog
• Explain in pull requests
• Create tutorials

Quality Markers:

• Clarity (non-expert can understand)
• Structure (scannable, organised)
• Completeness (answers questions)
• Actionability (clear next steps)

3. Learn the Business

Understand:

• Company revenue model
• Customer needs
• Market position
• Competitive landscape
• Product strategy

Why: Technical decisions should serve business goals

Example:

Technical: "Let's rewrite in Rust for performance"

Business-Aware: "Our bottleneck is database queries 
(500ms), not language speed (10ms). Let's optimise 
queries first—same performance gain, 1 week vs 6 months."

4. Build Relationships

Across Teams:

• Attend other team's standups
• Pair with engineers in other areas
• Volunteer for cross-functional projects
• Coffee chats with diverse people

With Stakeholders:

• Understand PM/Design perspectives
• Explain technical constraints clearly
• Propose solutions, not just problems
• Be reliable and responsive

5. Increase Scope Gradually

Progression:

Year 1: Own features within sprint
Year 2: Own projects across sprints
Year 3: Own initiatives across quarters
Year 4: Own strategy across years

Red Flags:

• Jumping to staff role too early
• Leading without learning to follow
• Skipping senior-level mastery
• Title-chasing over skill-building

Common Challenges

Challenge: Impostor Syndrome

Reality: Everyone feels this at times

Strategies:

• Document your achievements
• Seek feedback regularly
• Remember: You were hired for a reason
• Focus on growth, not perfection
• Find a mentor who's been there

Challenge: Being Heard

Common Issue: Technical ideas ignored

Solutions:

• Build credibility through delivery
• Use data to support proposals
• Start small (prove concepts)
• Find allies and sponsors
• Improve presentation skills

Challenge: Balancing Code vs Leadership

Tension: Want to code, but leadership duties grow

Approaches:

Option 1: Deep technical (Principal track)
- Maintain high coding %
- Lead through technical excellence
- Solve hardest problems

Option 2: Broad leadership (EM/Director track)
- Less coding over time
- Lead through people
- Scale impact through others

Option 3: Staff hybrid
- Strategic coding (40%)
- Leverage work (60%)
- High-impact projects

Challenge: Navigating Politics

Not: Office drama and backstabbing

But: Organisational dynamics and influence

Navigate Well:

• Build genuine relationships
• Understand motivations
• Find win-win solutions
• Communicate transparently
• Choose battles wisely

Measuring Leadership Impact

Quantitative Metrics

Team Velocity:

• Sprint points completed
• Cycle time improvement
• Deployment frequency
• Bug rate reduction

Engineering Quality:

• Test coverage increase
• Production incidents decrease
• Code review turnaround
• Technical debt paydown

Mentorship:

• Engineers leveled up
• Knowledge sharing sessions
• Documentation created
• Successful onboardings

Qualitative Indicators

Influence:

• Your proposals are adopted
• Others seek your opinion
• You're invited to key decisions
• Your ideas spread beyond team

Reputation:

• Known for specific expertise
• Trusted for hard problems
• Recommended for projects
• Recognised in performance reviews

Team Health:

• Engineers want to work with you
• Psychological safety increases
• Knowledge silos decrease
• Collaboration improves

Next Steps in Your Journey

Resources

Books:

• "Staff Engineer" by Will Larson
• "The Manager's Path" by Camille Fournier
• "An Elegant Puzzle" by Will Larson
• "The Staff Engineer's Path" by Tanya Reilly

Blogs:

• StaffEng.com (Will Larson)
• LeadDev.com
• Charity Majors (honeycomb.io)

Communities:

• Rands Leadership Slack
• LeadDev community
• Engineering managers groups

Action Plan

This Month:

• [ ] Write one technical design doc
• [ ] Mentor one engineer
• [ ] Propose one improvement
• [ ] Present one tech talk

This Quarter:

• [ ] Lead one significant initiative
• [ ] Improve one team process
• [ ] Document one architectural decision
• [ ] Build one cross-team relationship

This Year:

• [ ] Own strategic technical direction
• [ ] Multiply team effectiveness 2x
• [ ] Become go-to expert in one area
• [ ] Develop reputation beyond team

Continue Learning

Develop leadership skills:

• Master Soft Skills
• Improve Communication
• Lead Global Teams
• Grow your Career

Technical leadership isn't a destination but a continuous journey of growth, learning, and impact multiplication. Start where you are, use what you have, and focus on increasing your influence one step at a time.