Skip to content

Technical Leadership

General Resources

Link Notes
StaffEng Tutorials Guides for reaching and succeeding at Staff-plus roles
Gergely Orosz Resources for Engineering Managers and Software Engineers
Tech Lead Expectations for Engineering Projects Gergely Orosz's framework:
  1. Setup a framework for collaboration
  2. Manage risks
  3. Communicate project status to stakeholders
  4. Help the team focus and don't be afraid to delegate
  5. Motivate the team
Pat Kua The Definition of a Tech Lead Titles like Architect, Tech Lead, Team Lead and Engineering Manager provide endless confusion. This article explores the definition of the Tech Lead role
Pat Kua The Well Rounded Architect Acting as a Leader, Being a developer, Having a systems focus, Thinking like an entrepreneur, Balancing strategic with tactical thinking, Communicating well
Thriving on the Technical Leadership Path So what does the more strategic work of a very senior engineer look like?
Engineering IC Leadership Gitlab's view on Technical Leadership
Finding the steps on the individual contributor ladder Some experiences, learnings and questions to help people decide if the individual contributor (IC) route is for them
Becoming an Organizational Leader Progressing from a team leader to an organizational leader as an individual contributor
Your CTO Should Actually Be Technical Why engineering leaders also need to be great engineers
Gergely Orosz Internal Politics for Software Engineers and Managers "Politics" has a bad reputation in tech companies. What is it, why is it important, and how can you get good at the "right" type of politics?
Gergely Orosz What is a Staff+ Engineer? What the Staff+ role is, expectations and the rewarding and frustrating parts of the job
Gergely Orosz Ways Staff and Principal Engineers get Stuck (and how to get Unstuck) Common reasons why experienced engineers get stuck, how to prevent this from happening and how to get unstuck.
How do Individual Contributors Get Stuck? A Primer by Camille Fournier
Architects, Anti-Patterns, And Organizational Fuckery The architect role tends to be the locus of a whole mess of antipatterns and organizational fuckery

How Tos

Link Notes
Marco Lancini Weekly Digests to Increase Visibility and Transparency My own methodology to create and share weekly digests, both for individuals and teams
Gergely Orosz How to Lead a Project - as a Software Engineer Companion blog post for the "Tech Lead Expectations for Engineering Projects (Gergely Orosz @Uber)" document
An incomplete list of skills senior engineers need, beyond coding For varying levels of seniority, from senior, to staff, and beyond
10 Admirable Attributes of a Great Technical Lead There is no single formula to be a great tech lead. It's a demanding position. It requires both sides of one's capability: the heart, and the mind
Will Larson Sending weekly 5-15 updates A 5-15 report, spending fifteen minutes a week writing a report that can be read in five minutes
How to Influence Without Authority Understand first, influence later
Time management for makers
  • They are defensive of their time
  • They "pay themselves first"
  • They defend the time of others
  • They clearly designate interrupt-driven work and batch it
  • They clearly designate low-leverage work, and time-box it
  • They communicate with candor
  • They prioritize ruthlessly
Will Larson How to find engineering leadership roles
  • Peer-driven discovery
  • Applying directly, kind of
  • Executive search firms
  • Crowd-sourced searches
  • Sharing availability online
Gergely Orosz Becoming a Better Writer
  • Writing is an increasingly important skill for engineering leaders. Poor writing can hamper career progression, above a certain level
  • Tactics for more clear, more frequent and more confident writing
Plan on a Page Checklist
  • A brief mission statement and vision for your team
  • Short diagnosis statement
  • Two single-sentence focus statements in the 3m and 12m time ranges
  • A list of the key “workstreams”
  • A suitably detailed 12-month initiative roadmap
  • Upcoming key milestones
  • Key dependencies and partners
  • A list of non-goals
  • A list of key assumptions
  • A list of key risks you are managing

Consider including the following sections:

  • Metadata
    • Report title
    • Author
    • Date of report
    • Any additional metadata (e.g. tags, categories, reference number, etc.)
    • State (e.g. draft, in review, final)
    • An executive summary highlighting the main points
    • A table of contents
  • Introduction
  • Body
    • Progress - What happened since the last status report?
    • Plans - What are the next planned activities/outcomes?
    • Problems - What are the issues you encountered?
      • Problems split as issues (those you currently face/faced) and risks (those you might potentially face), their impact and any mitigating actions or decisions to be made.
    • Other
      • References to other useful documents, websites, or further detail
      • Contact point for questions or further information
  • Conclusion
  • Appendix

As you write a technical report, follow the ORID framework:

  • Objective - Start with data
  • Reflective - Describe how people feel or react to the data
  • Interpretive - Focus on the meaning or implications of the data
  • Decisive - Any specific recommendations, actions or decisions to be made.

Draw on the Pyramid Principle by:

  1. Starting with the decision/outcome
  2. Present supporting arguments (up to 3)
  3. Prepare to have at least 3 supporting detail for each argument, but only when it is necessary.

Be especially clear about your "ask", which is typically one of:

  • Input
  • Decision
  • Support

From: The Magic Prioritization Trick

  1. Organize the initiatives based purely on urgency (Less Urgent <-> More Urgent)
  2. Enforce a "curve" and stick them to a distribution (Whenever, Soon, and ASAP)
  3. Proceed to value: shift everything down to the BOTTOM of a 2x2
  4. Distribute the initiatives based on value (Game Changer, Optimizer, and Tweak).
    • The only move available is the VERTICAL movement
    • Urgency can't be shifted
  5. Define duration
    • Turn into a 9-box and divide each cell into three columns: 1-3mo, 1-3q, and 1-3y.
    • Place the initiatives in one of the three columns FOR THE CURRENT CELL

Managing Projects

Link Notes
Gergely Orosz Software Engineers Leading Projects
  • Why and when engineers at all levels could and should lead projects, and advice to prepare for leading these
  • Part One
  • Part Two
How to Make the Case for Slowing Down to Speed Up
  • Value-Driven Focus
  • Leverage Blocked Work
  • Figure Out Your Accountability Game
  • Test Assumptions
  • Identify the Wedge
  • Pitch the Approach (and the Wedge)
  • Smarter Trade-offs
  • Visibility on Main Roadmap
  • Pragmatic Solutions
  • Put your pride to the side

Overlap with Management

Link Notes
Lyft High Output Management for (Non-managing) Tech Leads How to increase the sphere of influence
The Engineer/Manager Pendulum Management is not a promotion, management is a change of profession
Leading without managing What does it mean to lead when you don’t have coercive power to get your way?
Filtering your language as an engineering leader
  • The most painful lessons learned in engineering leadership can be from when imprecise language has been used
  • Some good phrases:
    • Here's what I'd be worried about...: I want to warn someone about the risks of a path they’re considering taking, while still giving them ownership of the decision
    • This is just a half-baked idea but...: I want to gauge a reaction to, or get some honest feedback on, an idea, but don’t want the listener to take it as a set-in-stone direction
    • I'm going to give you some feedback...: I want the listener to be actively aware that I’m delivering feedback
    • Here's how I like to think about it...: I want to convey my mental model for decision-making, rather than the decision I would come to
    • Let me try to explain it. Correct me where I'm wrong...: I am wanting to make sure I'm not being an out-of-touch engineering manager
Pat Kua How Many People Can Someone Lead? Many factors affect the final number, including their leadership scope, other leadership roles, the experience level of the leader, the experience level of the team, and the level of organisational bureaucracy
Staff Software Engineer Responsibilities – Align With Authority
  • Staying Aligned
    • Figure Out Who To Align With
    • Avoid "Floating"
    • Write A Working Agreement
  • Trust
    • Meet Consistently
    • Develop Relationships Within Your Scope
    • Be Accountable
The Biggest Mistake I See Engineers Make
  • The biggest mistake I see engineers make is doing too much work on their own before looping in others
  • We end up in a position of dealing with the Sunk Cost Fallacy where it hurts to abandon the work already done in order to get back on track
Gergely Orosz Developers mentoring other developers: practices I've seen work well
  • Onboarding: a specific type of mentoring
  • Informal mentorship: it's happening everywhere
  • Formal mentorship: more effort, more focus, more growth
Drivers vs. Fixers The dual way to approach a problem