Technical Leadership

General

Reaching Staff-plus Roles

Link	Notes
StaffEng Tutorials	Guides for reaching and succeeding at Staff-plus roles
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

Definitions

Link	Notes
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
Architects, Anti-Patterns, And Organizational Fuckery	The architect role tends to be the locus of a whole mess of antipatterns and organizational fuckery
Gergely Orosz What is a Staff+ Engineer?	What the Staff+ role is, expectations and the rewarding and frustrating parts of the job

How Tos

Attributes

Link	Notes
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
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
How Do You Spend Your Time?	IC (individual contributor) work Mentoring and Teaching Strategic Stuff Rhythm of Business Learning Customers
Thriving on the Technical Leadership Path	So what does the more strategic work of a very senior engineer look like?
Drivers vs. Fixers	The dual way to approach a problem
Simple Rules of (InfoSec) Career Success	Take Action Focus on the Customer (internal or external) Be clear on your goals Believe in Your Team Work on Yourself Collaborate Improve Other Things Honor Your Sponsors It is Always Your Fault
The Case for Caring Less	Caring deeply is a career asset early on, but over-attachment to outcomes causes burnout and poor decision-making. Senior operators learn to place care deliberately, distinguishing noise from strategic importance, focusing on controllable actions over specific outcomes

Project Management

Link	Notes
Gergely Orosz Resources for Engineering Managers and Software Engineers	Documents and templates that hundreds of engineering managers and engineers have used with success at various companies Some examples: Tech Lead Expectations for Engineering Projects Project Reporting Template
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
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
Tech Lead Expectations for Engineering Projects	Gergely Orosz's framework: Setup a framework for collaboration Manage risks Communicate project status to stakeholders Help the team focus and don't be afraid to delegate Motivate the team
How I’ve run major projects	A project DRI starter kit Weekly meeting Landing page / working doc Plan / roadmap / milestones Who’s working on what Weekly broadcast updates Retrospectives
How to Drive Meaningful Change - Handling objections to your proposal	Be prepared to handle the various responses you will receive when you propose a change.
How to deliver bad news when it's not your fault	Avoid negative words, like "however” and “unfortunately” → Your goal is to minimize drama Avoid giving too many details → Your goal is to be concise and direct Don't accidentally accept blame → Your goal is to be clear about what happened Get to your point quickly → Adding too much preface makes things worse Remind the person of their own agency → Remind your colleague that you were both aware of the risks—and jointly decided to proceed anyway
Protecting your time from predators in large tech companies	Helping others is not your main job, doing the work is Large tech companies are full of predators looking for strong engineers whose time they can use Beware product managers from different orgs and weak engineers Don't let your time be consumed asymmetrically
Delegating Complex Tasks	Two proven methods for delegating complex tasks: Exponential training, Suboptimal Standardization

Handling Objections

Category	Objection	Mitigation
Disagreement on Outcome	Rejecting	Ask for specific reasons and address them.
	Denying	Paint a picture of the problem, get feedback from those affected, reduce cost and energy for the stakeholder.
	Diminishing	Illustrate the magnitude, paint the long-term picture, compare to other addressed problems, ask for their problem threshold.
	Nitpicking	Reorient on primary problem, address the root cause (e.g., disagreement on outcome, lack of perspective, personal relationship issues).
	Obstructing	Do the tasks, point out the lack of purpose, build trust, address personal relationship issues, or understand horse trading.
Disagreement on Mechanism	Rejecting	Ask for specific reasons and address them.
	Criticizing	Accept, reject, or address the criticisms.
	Optioning	Be open to alternatives if the outcome is the same, discuss pros and cons if the form of the solution is important.
	Compromising	Merge ideas, focus on the goal, and be willing to trade-off parts of the solution.
Agreement and Alignment	Accepting	No mitigation needed; proceed with implementation.
	Reinforcing	Get agreement on the outcome and general solution, then incorporate feedback while avoiding scope creep.
	Testing	Agree on test parameters and expectations, manage timing and scale of expectations, follow the test, and report results accurately.
	De-risking	Incorporate appropriate guardrails, argue out of busy-work if necessary, or propose other mechanisms to address perceived risks.

Communication

Templates

Technical ReportsExecutive PresentationsPrioritization

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

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 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
Gergely OroszBecoming a Better Writer as a Software Engineer
Some tactics for writing in public	Talk about facts Ask technical questions Fix mistakes Ask for examples/experiences, not opinions Start with a little context Preempt common suggestions Don't argue Analyze negative comments
A Practical Guide to Executive Presence	Execs Don't Freak Out Execs Don't Ramble Execs Calibrate Their Confidence Execs Aren't Blindly Defensive
A Practical Guide to Executive Presence: Earning Respect	Execs Demonstrate Deep Expertise Execs Never Exhibit Uncontrolled Lateness Execs Work Hard Execs Don't Take Things Too Literally Execs Have a Life Outside of Work
Why you should work asynchronously	Asynchronous work allows for remote work that's enjoyable and that actually works. Async increases inclusivity, produces better outcomes faster, encourages discoverability and permanence of context, creates space for learning, shifts knowledge workers to higher value work, improves work-life balance, empowers distributed teams, and enables parallelization and flow
Making the case to decision makers: the presentation format to follow	A tested template to follow when presenting to executive leadership teams.
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
Have Concerns And Commit	More often than not, you shouldn't be disagreeing at all, but instead having concerns about decisions
Ask for Advice, Not Permission	Instead of “Hey, I was thinking about doing X, would you be on board with that?” ask for advice: “Hey, I was thinking about doing X, what advice would you give me on that?”
Phil Venables A Security Professionals Guide to Dealing with Disagreement	Aim for a win-win Frame the problem differently and define the new problem as something to work together on Other person's point of view Make some progress, any progress Always be Closing Don't personalize Listen to the meaning not the words Go the balcony (take a break) Don't take no as a permanent answer Influence the influencers
Tone and words: Use accurate language	"We might want to try X, Y, and Z. These are a few ideas, but I'm not stuck on any of them. What do you think? Where do you agree and disagree?" "I'm still working through a few ideas. My initial hunch is we should X." "I've noticed you tend to do [X behavior]. This might not be as effective because [reason]. If you want to [reach goal], you might want to consider Z."
**How to Say "No" Well	Security's push to avoid being the 'Department of No' has overcorrected. In our eagerness to enable, we've lost sight of the value of a thoughtful, strategic 'No.'
Say "but yes", not "yes but"	If you’re in the “yes, but” habit, it can feel to you like you’re endorsing, but to others like you’re only reluctantly agreeing

Progressing

Link	Notes
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
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
Becoming an Organizational Leader	Progressing from a team leader to an organizational leader as an individual contributor
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? Part 1 Part 2
Senior Engineer Fatigue	Senior fatigue is, perhaps paradoxically, a sign of maturity in engineering. It's an indicator that you're transitioning from doing everything to ensuring that everything that needs to be done gets done in the most effective way
Keys to Career Success	Take Action and be Persistent Add Value - Focus on the “Customer” Be Who You Are - Play to Your Strengths Collaborate and Take Broad Responsibility Deal with Reality and Ambiguity Be Honest with Yourself

Overlap with Management

Link	Notes
The Engineer/Manager Pendulum	Management is not a promotion, management is a change of profession
Phil Venables The Art of Influencing	Be very clear on the outcome you want Understand the current situation: data, motivations, people, and environment Understand the “forces” that keep a situation current Use thinking tools to find the core of an issue Plan the change of mindset Communicate - in person and in various internal media Present the message clearly and effectively Execute on your commitments
Lyft High Output Management for (Non-managing) Tech Leads	How to increase the sphere of influence
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
How to Influence Without Authority	Understand first, influence later
Leading without managing	What does it mean to lead when you don't have coercive power to get your way?
Getting buy-in to get things done	When you are working in any sort of leadership role, you'll have to get people to work toward initiatives that you're leading or make changes you're proposing
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
Your CTO Should Actually Be Technical	Why engineering leaders also need to be great engineers