If you deliver as an engineer, you’ll eventually be asked to lead. That might mean driving a large project, mentoring your peers, or “tech leading” a team or subteam; it’s work that goes beyond the technology you build and into how you guide the organization and individuals around you. Leadership requires humility and selflessness, compared to coding; as an engineer, you might be the action hero in your own little hacking movie, but as a leader, your job is to make the most of others’ talents—to inspire them, to arm them with the context to make their own decisions, to keep them happy, and to help them improve on their weaknesses.
This section will offer tips for all of those enterprises; the one thing it won’t discuss in detail is engineering management, though these practices apply to that job. “The Transition to Management” (Chapter 4) discusses how you can reason about that career move, but it’s a subject well-treated in many other books.
Vision: Choosing valuable, feasible things to do and crafting an inspiring story about those goals. That story isn’t exactly the same as what you want to achieve; it’s a narrative that links that work to a bigger picture and helps people take pride in their piece of the whole.
QA: Making sure the team’s code and practices are high quality.
Project management: Planning, tracking, and communication to divide work into coherent pieces, allocate the right resources, do the right things at the right times, and remember the loose ends.
Harmony: Fostering a collaborative environment where team members respect each other but also feel safe and valued as individuals.
Mentorship: Shepherding the growth of your team members as individuals, including teaching, feedback, and career advice.
After that, we’ll discuss a couple of common specific scenarios: onboarding engineers to a team and managing an intern.
Vision and Identity
In my experience, engineers are driven above all by the desire to do work that matters, and when they feel that they’re contributing to something wonderful, other ills will be overcome, ignored, or forgiven; when people don’t buy the vision or feel an identity as a team, then no amount of nurture, fun, or money will keep them happy. Therefore, I think a strong vision is the most important part of a leader’s work, whether on a project, a team, or a whole organization. A tech lead may only control part of that vision (engineering managers or product managers will own part of it), but there’s usually room for maneuver—maybe you can add a project that matters, maybe you can cancel one that isn’t feasible, or maybe you can articulate the narrative that will inspire people to execute on the plan.
When you have the leeway to make your own roadmap, far and away your foremost tool is research (see “Having Your Own Project Ideas” in Chapter 3). Read, ask people (your team members, your peers, your customers, your manager) their opinions, estimate impact, estimate cost, and tell the story that you’re doing the project with the biggest bang for your team’s buck.
This is an opportunity that can change the company (or the world). If you deliver, the upside will be huge.
Our goal is to drive the load time of the site from 1.5s at p95 to 750ms. This is a hard problem, but our team has the expertise, and if we do it, we can bring in over $50 million next year in improved conversion rates.
This is an existential threat, and your team are the saviors. If the team doesn’t deliver, it may be disaster, even the end of the company.
At the rate the business is scaling, our main database is going to fall over in six months. This migration is going to be painful, but if we don’t do it, the company will not survive; we’re going to make scaling problems a thing of the past.
This is the smartest, most careful team, the stewards whose expertise and diligence put everyone else on track.
We are the stewards of production at this company. This is a tough and sometimes thankless job, but our diligence saves hours of downtime and millions of dollars.
This is the team that gets things done. Maybe others are more technical, but this team ships code that matters while others dither.
Our company’s business is driven by integrating smoothly with every customer installation. Today, we cover 85%, and our sales engineers sweat to cover the difference. Our goal is to bridge this gap, save tons of money on sales engineering, and unlock another order of magnitude of scaling.
As you can see, some of these involve a certain element of opposition, drawing a contrast between your team and the rest of the world; a touch of “us versus them” is a helpful device as long as it doesn’t go so far as to breed outrage or hostility.
Team QA
As a technical leader, part of your job is making sure your software and practices are high quality. I basically believe in three methods for achieving this: leading by example, direct feedback, and teaching your principles.
Leading by example should speak for itself—if the engineers you lead see you ship crappy code or play fast and loose with production, they’ll learn to do the same. If they see you hold yourself to a shockingly high standard, they’ll absorb that too. This method shouldn’t be underestimated; I find that young engineers are hungry for inspiration, and when they recognize admirable practices, they’ll strive to emulate them.
Second, you can give 1:1 feedback (a subject unto itself); this is an opportunity for more nuance and detail. Code review and design review are a tech lead’s most frequent opportunities to share and enforce their standards.
Finally , sharing your principles in writing and in presentations is the most scalable way to evangelize your practices; a presentation on operational practices can reach a whole team in one-tenth the time of giving direct feedback to everyone. I favor one-page white papers, runbooks, and slide decks especially—each give you opportunities to crisply codify your standards. I think every team should have at a minimum a document that captures its deployment and on-call practices, but you might get good mileage out of a style guide, a position paper on reliability practice, etc., etc.
Project Management
Project management as a leader is, more or less, a scaling up of project managing yourself (Chapter 5). I’ll only mention two extensions to those principles.
Communication
When you lead a project, you depend on the discretion and creativity of your team members. In order for them to make good decisions and have good ideas, they need to know what’s going on, not just to the minimum necessary to execute on tasks but in the big picture; that context lets them connect their work to others’ and find mutual opportunities (or common problems). You should strive to avoid making yourself the only conduit of information. This is an important argument for a weekly team meeting where everyone discusses what they’ve done in the past week. That meeting isn’t for you as the leader, though you might benefit—you could certainly get the whole picture from 1:1s. Its foremost purpose is to cross-pollinate across engineers.
It also colors how you assign tasks. If you tell an engineer, “we are migrating from Memcached to Redis for these data; please move all the call sites onto the Redis client,” they really don’t know what’s going on; that’s confusing and, to a knowledgeable professional, insulting. Moreover, they then depend exclusively on you for more information, which is inefficient for both of you. I’ve had countless tasks assigned to me with exactly that much context, and it’s always driven me nuts. In contrast, if you explain the motivation in detail and provide links for further information, you arm a professional to make their own way. In contrast to the above:
When we built this system, there was no common caching framework; we used Memcached because Tina was very familiar with it. Now, all the teams are aligning on Redis, which is going to have much better operational support, so we need to migrate off of Memcached. Ashish on that team is our point of contact.
Assigning Work
The second extension is about the subtle art of assigning tasks to the right owners. Whole books are written on this topic, and I won’t aspire to a complete treatment. I’ll just offer one tip: the ideal task for a given engineer is “what they’ve shown they can do, plus epsilon”—the ideal work is always a chance for them to grow, for the good of the team and for their own satisfaction, but not a wild shot in the dark that will require constant hand-holding. And, given that the ideal task always pushes an engineer, we should acknowledge that upfront and repeatedly check in on how they’re doing, offering help if they need it—if we don’t offer, junior people will usually think they aren’t welcome to ask.
Harmony
As a lead, you’re the shepherd not just of projects but of people, and you can contribute to your team’s execution by creating a harmonious atmosphere. Since many books have been written on this subject, I’ll offer only my top two suggestions.
First, always set a tone of positivity and optimism. A group of people will naturally key off the emotional tone of their leader, and when you’re pessimistic or angry, they will be too. Giving credit liberally and publicly and celebrating what goes right can create an atmosphere of positivity. Deriding or insulting your team does quite the opposite and should be avoided at all costs; your criticism hits twice as hard as anyone else’s. You’ll experience frustration, pessimism, and anger, but venting them is not the luxury of a leader (which is one of the great challenges of leadership); find your calm and positivity every day.
Second, keep an eye on people. If you sense that they’re upset or stressed, you can go miles by just saying what you see and asking if you can help; just as your criticism hits hard, so can your empathy.
Mentorship
The goals of mentorship
How to model the abilities and progress of your mentee
Tools for teaching, evaluation, and getting the most out of 1:1s
Integrating those tools in long-term plan
Your Purpose As a Mentor
- 1.
Teaching: Sharing practices and insights from your greater experience, putting new tools in your mentee’s toolbox.
- 2.
Support and comfort: The support of a mentor, particularly one who isn’t also a manager responsible for performance reviews, can be a great relief in stressful times.
- 3.
Evaluation: Assessing strengths and weaknesses, figuring out where to focus mentoring efforts.
- 4.
Tactical problem-solving: Helping your mentee navigate specific situations that arise in their day-to-day work.
- 5.
Goal setting: Helping clarify actionable, valuable goals; note that even experienced people may grapple with where to go next in their careers.
- A.
Building trust: Creating the shared context, openness, and supportive environment that will allow for candor.
- B.
Listening and learning: Taking feedback from your mentee, figuring out where you’re going wrong and how you can do better.
A Model of Your Mentee
Your model of your mentee—an idea of what they want and where they stand—determines how you’ll approach your task. I argue that you should have such a model in mind at all times in order to always reason clearly about your priorities as a mentor.
Goals
Some mentees have strong and specific desires—mastering a specific technology, getting a promotion, becoming a manager, executing a transition to product management, etc., etc., etc. These are the easy ones; most likely, when you hear their goal, you can help them craft a plan.
Most engineers, though, are much more vague in their aspirations; they more or less just know they want to Get Better. You should help them clarify their thinking if you can, but I also argue: some vagueness is fine. In the absence of specific goals, there’s one direction for an engineer, which is up and to the right: bigger impact, more complex problems, more autonomy, better quality, better communication, better project management, and so on. By default, we can set a goal of a new standard of excellence for ourselves, pick a small number of points to focus on, and start on the work.
I recommend discussing goals in depth with a mentee in your first few meetings, then no less than quarterly as you continue to work together; set yourself a calendar reminder.
A Vector of Skills
Success in engineering or management requires a portfolio of complementary skills; success in mentorship requires a model of your mentee’s skills relative to their goals. I recommend keeping in mind this vector of competencies and regularly asking yourself—and your mentee—where they stand; that clarity will help you allocate your time.
- 1.
Coding: Clarity, testing, documentation, and discipline in scope of differences
- 2.
Project management: Identifying dependencies, updating stakeholders, and tracking tasks
- 3.
Communication: Clear emails and engaging presentations
- 4.
Personal organization and time management: Not dropping balls but prioritizing effectively
- 5.
Architecture: The macroscopic design of systems
- 6.
Leadership/mentorship: At a level appropriate to their position
- 7.
Emotional skills: Confidence, stress management, and work–life balance
Tools for Getting Organized
I conceive mentoring as centered around 1:1 meetings happening every 1–2 weeks for 30–60 minutes. In this section, I’ll offer a menu of tools for teaching and evaluation in 1:1s; a later section will propose a scheme for integrating these pieces in a longer-term strategy.
Since your goal is complex and there are many tools available, deciding how to spend your time is instantly challenging. Luckily, you don’t need every moment to fit perfectly into a grand scheme. Stay organized with a shared doc, try to align on goals, and ask good questions—then you can be intuitive and flexible as you build your sense of your mentee and come up with a plan.
I only have one recommendation I consider mandatory: be proactive. Asking a report, “how’s it going,” is no crime—but when that doesn’t lead to deep insight, as it often won’t, you should have tools for getting somewhere interesting.
Agenda Doc
Frequency: Every meeting
Don’t be stateless! Keep an agenda doc you can both update where you record topics for your meetings; also stash key takeaways there. As you explore different ways of working together, your shared doc will help you stay organized and avoid getting overwhelmed. Keep your own private notes too, where you record areas to follow up on. Closing open loops helps you get the most out of your discussions, and being organized shows your commitment to your mentee.
Goal Setting
Frequency: Once per quarter
The main purpose of goal setting is to help your mentee clarify their thinking about long-term plans, but that process also helps you deepen your understanding of your mentee and do your own planning. Adapt your approach to the maturity and level of certainty of your mentee, whether that means brainstorming ideas together or diving in on the gritty details. Set yourself a calendar reminder to have this discussion quarterly, and be sure to record the results in your shared document.
Tools for Getting the Most from 1:1s
The Top Two Problems
Frequency: Every meeting
In some 1:1s, particularly as you’re getting to know each other, you’ll likely find it hard to get the conversation going; even if there’s plenty going on, it can be hard to decide what to talk about. I suggest asking your mentee to come to your meetings ready to discuss the two most pressing problems they’re facing. Those problems might be from any domain—technology, interpersonal issues, organizational issues, project management, etc., etc. This method is easy, it offers opportunities to advise on important issues, and you’ll find that you often segue to other interesting topics.
Probing Questions
Frequency: Once per month or whenever you have time
It’s good to leave space in your 1:1s for unstructured conversation—it’s a refreshing change of pace and an opportunity to hear things from your mentee you might not in a more focused conversation. I’ve often found that people have plenty to say but need prompting: where “how’s it going” or “what’s on your mind” might stall, a more specific question can get people talking. Have a few off-the-shelf questions ready to go. It can feel stilted, but stomach it, and be candid about the fact that it’s a way to start the conversation; once the discussion gets going, ask good follow-up questions! Learn something about how your mentee sees things.
Upward Feedback
Frequency: Once per quarter, if not more
Your mentoring is imperfect, in general and in each case in particular; feedback from your mentee helps you improve. At least once a quarter, you should solicit feedback about what’s been useful (or the opposite) in your mentoring. It may or may not go without saying that you should genuinely appreciate it when a mentee has the guts to give you honest feedback about how you can improve. This is also a good time to ask yourself, and maybe your mentee, the question: Is this interaction still valuable? The day can come when interests, needs, or circumstances change, and a mentorship relationship can come to an end.
Chitchat
Frequency: Every meeting
Ask about the long weekend; ask about the most recent episode of their favorite show; ask about their vacation. And in turn, talk about your long weekend, share what you thought about GoT, and tell them about your trip to the Computer History Museum. Taking a genuine interest in your mentee and sharing of yourself are important ways to build trust, and they can help you find enjoyment in the work of mentorship. A 1:1 dominated by chit chat doesn’t serve its purpose, but take some time to enjoy a conversation.
Answer with a Question
Suggesting that you reply to questions with “what do you think?” is more or less a cliché—but it can give your mentee a chance to formulate their own ideas, and it’s a confidence boost when they’re onto something. Give it a try.
Tools for Deep Dives
As you develop a sense of your mentee’s goals and abilities, you’ll identify areas where you want to focus your teaching. This section will suggest a few ways you can go deeper in a specific area.
Exercises
Frequency: As needed
Exercises in a given area can take the form of reviewing recent work, simulating a task, or producing a real product—the goal is to practice a skill, provide signal to both parties about progress, and give the mentor an opportunity to give meaningful feedback.
Review recent emails together to improve communication.
Review recent diffs together to improve code clarity.
Write a hypothetical roadmap for a team as a management exercise.
Choose a task tracking app, and use it for two weeks to improve organization.
Make a list of potential new roles to review together when considering a change.
Book Club
Frequency: As needed
Key insights
Weaknesses
Relevance to current work
It can add some nice variety and encourage your mentee to develop their own practice of educational reading.
Reviews and Postmortems
Frequency: once per month
What went right
What went wrong
What you’d do differently
As always, look for the general principle at work that your mentee can file away.
Putting the Pieces Together
- 1.
Goal setting once per quarter: Set a calendar reminder!
- 2.
Subject matter “units” focused in service of those goals—for instance, three 1:1s in a row focused on project management, with exercises and reading. You should aim to identify such a theme at least once a quarter.
- 3.
A default of discussing tactical issues if no broader units occur to either of you; look for broader lessons in those issues. These ad hoc conversations can offer a casual break from focused sessions. Fall back on “two top issues” and off-the-shelf questions.
- 4.
A liberal attitude toward diversions that arise along the way: Enjoy them, and learn from them together when they occur.
- 5.
Transparency about your process and collaboration with your mentee on making your plans; you should encourage them to take as active a role as possible in planning and discussion.
- 6.
Time thinking about your mentee on your own: Don’t only consider your mentee when they’re in front of your face. I suggest scheduling a dedicated half hour per month, the output of which should be a refined assessment of their skills and several proposals for subjects to cover together.
- 7.
Regular replanning: You may only set goals once a quarter, and you may sometimes spend several sessions in deep discussion of tactical questions. But, when you reach the end of the tunnel, step back, and think a bit about the future. Bring a list of ideas to your meeting, and discuss together: What’s something we could go deep on in the next month?
Onboarding Engineers
Regardless of whether you lead groups, you’ll likely sometimes take charge of onboarding new people to your team. I once saw this done well, but I may have dreamt it—it’s usually done terribly. I vividly remember simply having no one tell me anything when I started one job; I just got a task and got to work.
As we’ve discussed in Chapter 4, joining a new team is a bewildering experience even for seasoned engineers, but if you’re in charge of onboarding someone, you can save them some suffering. Here’s what I recommend.
Before your new arrival joins, prep a one-page document for them. This should include links to key wikis and dashboards or a list of owners for key areas they may need to work in.
The team’s mission
An overview of the team’s architecture on a white board, with pictures taken at the end for posterity
A discussion of the major projects going on in the team
A discussion of any key principles, values, or practices on the team and any special gotchas
A review of your larger organization, including an overview of the key engineers and managers in the organization and their portfolios
A Q&A
Finally, you should make it your business to be obnoxiously available for questions; this should be proactive, because new hires are shy and scared to ask. I suggest checking in at the beginning and end of every single day, asking how their work is going and if they need anything.
After your own first onboarding, which will probably be haphazard at best, you’ll probably be completely sold on this mindful approach.
Interns
Within a couple of years of starting your career, you’re likely to manage an intern. Cool! If you’ve read the above sections, you’re ready to lead and mentor just about anyone; I’ll just add practical details specific to interns.
Most internships are structured around one project. An intern is assigned an “Intern Manager,” who is usually a fairly junior engineer; the collaboration is seen as an opportunity for both parties, with the intern manager getting a chance to practice leadership. The team manager and the intern manager will agree together on a project, which is almost always far away from the team’s critical path (if an intern is on the critical path, the team is in for some trouble).
They don’t know anything.
They aren’t going to tell you when they’re off track.
Therefore, proactive mentoring and monitoring are the key to managing interns. Like most management, you should have a weekly 30-minute 1:1 where you review project status and where questions are welcome. As with all new employees, you should check in frequently to confirm that all is well—initially daily, later a couple of times per week. You should plan to go deep on your intern’s questions, not just telling them what command to run but delving into the theory of the team’s technology and methods. Perhaps most importantly, to keep them on track, you should set the project schedule, including deadlines for numerous milestones, like an early design review, a full design review, a prototype review, and projected completion. When managing a seasoned professional, managers will often ask the engineer to set deadlines, because they know best. With an intern, however, deadlines keep things on track, especially because they create frequent opportunities for the mentor to review the intern’s work; this avoids the (common) intern worst case, which is letting a false start fester for weeks before anyone notices.