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

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

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

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

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