TOC

This blog post is part of a continuing series about enumerating the various responsibilities engineering leaders have and some of the concrete levers available to them. In general, this series optimizes for breadth, not depth, so if you’re interested in having me dive deeper into any particular topic, just let me know!

Being a Great Eng Leader is Hard

Being a great leader in any discipline is hard. It requires vision, strategy, inspiration, empathy, problem-solving, discipline, process, details, an extremely thick skin, and a lot more. As far as I’m concerned, being an engineering leader is particularly hard, because the job isn’t even very clear. There are a whole constellation of formal and informal leadership roles in tech with various names depending on your methodology - product owner, product manager, eng manager, people manager, tech lead, team lead, lead engineer, senior IC, project manager, program manager, SCRUM master, etc - that depending on the company may actually be in charge of any number of different overlapping responsibilities. And then once you do know what your job is, you still have to figure out how to get the job done. And again, that’s particularly hard in tech because a) it’s a very broad and flexible space, such that there a lot of different ways you could be spending your time and energy, b) you tend to have very little of that time because often the report:manager ratio is too high or you’re still trying to be an IC while managing, and c) startups and tech in general tend to be high urgency and fairly chaotic. Add it all up, and you have a situation where there is very little time, and a huge array of things you could be doing with it.

The goal of this post is therefore not to teach anyone how to be a good leader. That would be comically over-ambitious and would (and has) taken many full-length books. It’s not even how to teach any specific, individual leadership skill or style. Instead, I want to help enumerate the responsibilities that could be in your scope and enumerate some common, high-value levers that could help you achieve them. The hope is that by providing a framework for reasoning about what your job is and what techniques are available to you, you’ll feel less overwhelmed, be more deliberate (and successful) at spending your time wisely, and maybe even identify some concrete techniques that you want to dive deeper into on your own.

One other quick clarification before jumping in. This post is primarily targeted at “first-level” leaders who work directly with ICs, because that’s where my personal experience lies. While some of the content likely generalizes to “nth-level” leaders who manage other leaders, I can’t guarantee it, plus there are definitely additional responsibilities and techniques available to nth-level leaders that I’m not covering at all (and may not even be aware of).

Breaking Down the Job

First off, I’m going to completely disregard titles. Like I mentioned above, titles in tech are generally overloaded and ambiguous. Instead, I’m going to focus on the full set of “leadership responsibilities” that an engineering team needs to function healthily. How those responsibilities are ultimately allocated across humans is mostly orthogonal and out of the scope of this post. I’ve grouped the individual responsibilities into domains for easier consumption.

• Human Leadership
  • Help people be amazing at their craft.¹
  • Help people be happy.²
  • Help people be effective at their job.
• Product Leadership
  • Ensure people are building the right things.
• Execution Leadership
  • Ensure people are building things on-time.
  • Ensure people are building things that meet all the known requirements.
• Technical Leadership
  • Ensure people are building things “the right way” and with “sufficient quality” so as to serve the company’s best interests over the short and long terms.
  • Ensure the company has sufficient technical resources (people, process, platforms, technology, etc) to be able to execute successfully over time.

None of this is meant to be an exact science, just a useful practical framework. A lot of leadership activities may impact or be in service of multiple of these responsibilities, and many of the responsibilities may impact each other (the dependency graph here would basically be a giant spaghetti ball with lots of cycles).

Help People Be Amazing At Their Craft

So, without further ado, let’s start getting into the individual things you COULD be doing as a human leader.

Work Allocation. Your single biggest lever for investing in people is defining or influencing what work they take on. It’s high impact and there are tons of opportunities to exercise it. Work allocation allows you to expose people to new areas and broaden their expertise, dive deeper into areas they are already familiar with to increase depth and mastery, or just build more reps and muscle memory on critical skills. This is true for both technical craft/knowledge (e.g. work with a new database technology, dive deep into server internals, or drive more system design docs) and non-technical craft/knowledge (e.g. collaborate with a new discipline, plan a project with many stakeholders, or give more tech talks). Work allocation is also able to indirectly impact a ton of the other items in this list (e.g. who they collaborate with, the narrative for how their work helps drives vision, exposure to personal goals, etc).

Collaboration. Another valuable lever that you’ll have tons of opportunities to exercise is who people collaborate with. People will naturally pick up positive knowledge, skills, and habits from their coworkers via osmosis and advice, plus more senior people will often informally mentor more junior ones.

Mentorship. I see mentorship as the broad collection of “deliberate teaching and coaching activities” that you and other leaders (regardless of position) should be practicing LITERALLY ALL THE TIME. This is a huge topic, and one that is just as much in the realm of Technical Leadership as Human Leadership, so I’m going to save the heavier detail for that post and save some space here. For now, I’ll just provide some quick mentorship examples: letting mentees ride sidecar (shadow an interview, sit in on a meeting), working together with mentees as peers (jump on a whiteboard together, pair out some code), reviewing mentee work (design review, code review), providing constructive feedback, answering questions, asking questions, providing advice, and more.

Let Them Fail. One of the hardest lessons for me to learn as a human leader was “when to let my people fail”. On a personal level, I hate failing, and when my people fail, it feels like I failed. But failure is (obviously) a critical part of growth. So every time you see folks doing something you think is at-risk, deliberately think about the risk involved. What is the probability of failure? What is the impact of that failure on users, the company, or the individual? Ultimately, you have four options: a) stay quiet, b) point out the risk but let them decide if it merits action, c) point out the risk and force them to take action, or d) point out the risk and then get directly involved in resolving it. There is a time and a place for all four responses, but I find with more senior people I mostly rely on (b) (“flagging the risk”).

Homework. Occasionally, pointing people at specific self-improvement tasks can be extremely effective and well-received (it shows you care and are thinking about them and their situation specifically). This could be callouts of skills or technologies to work with, books to read, people to try and collaborate with, experiences to have, etc.

Help People Be Happy

Make Them Awesome. This probably goes without saying, but feeling like you are actively getting better at what you do is a huge morale win. See the above section ;)

Personal Goals. This is essentially just the subset of Making Them Awesome that people are particularly passionate about, plus the random extra bits they really want to be exposed to that don’t align with their core craft or career development. The first 1:1 I have with every single person who has ever reported to me is to understand what those personal goals are, to understand what that person wants to get out of their job and where they want to be in 5, 10, or even 20 years.

Vision. It’s a huge morale win when people can see and understand the vision of where the company, their team, and the systems they work on are headed over time. If you have good higher-level leadership (especially product leadership), this part can come for free, but if you don’t, it’s up to you to define your take on it and paint the picture.

Work=>Vision Narrative. It’s an even larger win when people understand how their individual work ladders up to driving that overall vision. Again, if you have good product leadership, this comes for free, but if not, then it’s on you. And if you honestly can’t come up with a good narrative here, then you need to ask yourself and your product partners some hard questions about what you’re working on and why.

Sense of Progress. And finally, it’s an even larger win when people feel like they are making progress towards that individual work and aren’t spinning their wheels, roadblocked, or making a snail’s progress. In essence, when they feel effective, which I’ll jump into in detail in the “Help people be effective” section below. Note that these last three bullets essentially combine into “people feel like they are making progress towards something they believe in”, and that’s a helluva great mindset to be in (and what I would call tablestakes leadership).

Just Listen. Honestly, for some people, one of the most valuable things you can do is just listen. It’s not always about needing advice or removing blockers. Sometimes people just need to get things off their chest, vent some steam, think out loud, or (as in my case ;) give an inordinate number of FYIs because it feels good to have another human “in the loop”. It’s up to you to decide when people need you to just listen, to respond, or to take action.

Care About Them As People. Similarly, it also feels really good to know your boss cares about you as a human being. Make sure to give people evidence of that. Don’t make everything about nitty-gritty work details. Everyone has a different interpersonal style, so I won’t provide any concrete examples, but it should come from a genuine sense of empathy and compassion.

Have Their Backs. It’s a pretty amazing thing to know you’ve got someone in your corner, someone who will support your asks, back you up when you take risks (or when you fail), and defend you when you aren’t around, even when it puts the defender at risk. Even just a few instances of this can define an entire relationship. And yes, it means you will occasionally need to take short-term risks of failure or delay, but it’s worth it.

Cheerleading. Sometimes people just need a source of positive energy around. Someone to get excited, someone to appreciate the wins and the steady-state positives that are so easy to take for granted. It can change the entire feeling of a team. That said, this is a hard skill to learn for certain personality types and may be worth deputizing (i.e., look for someone else on the team who can provide that energy and encourage it).

Team Cohesion. Morale obviously isn’t just about the individual, though. Feeling like you are part of a high-functioning, close-knit, intellectually stimulating, and emotionally supportive team feels incredible, and the camaraderie and solidarity you build with your teammates can stick with you for the rest of your career. Building team cohesion is particularly non-deterministic, but here are some basics that are usually critical:

• Work Together. This sounds stupidly obvious, and it is, but the act of directly working together builds a ton of cohesion. Make sure people aren’t siloed and get the chance to work directly on projects together. Exposing them to a variety of people is important, but also make sure to expose them to the same people over time, so that they build up a relationship and can take advantage of it.
• Foster a Culture of Rich Technical Discussion. Few things bond engineers as much as deep technical discussion. The goal is for teammates to be thinking through problems and debating with each other a lot, and that means it needs to be built into their everyday work (not the sole responsibility of any sort of special forum like a tech talk). Whether its more formal, like design review or code review, or less formal like early design discussions or “I’ve got this problem that I need help thinking through” conversations, you want people to engage in-depth by default. Depending on your execution methodology, this may come for free, but if it doesn’t, I’ve had immense traction from just a) modeling the hell out of the behavior myself (grab people and jump on a whiteboard, start a thread on the team chat, etc), and b) pointing out where it didn’t happen but would have provided immense value as part of 1:1 feedback or project post-mortem.
• Make Space for Being Human. I don’t believe that coworkers all need to be friends, but I do think that appreciating them as humans is a no-brainer. If your only interactions are all-work and no-play, this is hard to build up. Standard moves like regular off-sites, team lunches, or (optional, inclusive) social events like during-work happy hours definitely go a long way. I’m also a huge believer in micro-interactions. Ask someone how their weekend was and actually care about the response, let a hilarious conversation at the beginning of a meeting go for 5 minutes before reining it in, have a dedicated social chat channel and post a stupid meme to it once in a while. It’s easy to feel like these interactions are a waste of time or inefficient, but in aggregate they add up and provide long-term value.

Problem-Solving. This is a grab-bag for resolving all the specific, situational negative issues that can arise in someone’s job. It’s not about making work positive, it’s about getting rid of the bullshit. Every single “problem” is different, and so there is no formula for it at all, but here are some common techniques I’ve run into:

• Provide Perspective. Often people are angry about a situation, behavior, person, or decision because they aren’t considering the issue from the perspective of the other party (coworker, customer, leadership, company at large, etc). Providing that other perspective and the rational (or even irrational) thinking behind it can help provide logical explanation, empathetic understanding, or both.
• Resolve Conflict. Sometimes perspective isn’t enough, and you’ll have to step in and directly facilitate resolving inter-personal conflict. There are whole books about this specific topic, so I won’t touch on it here.
• Remove Negative Exeriences. There can occasionally be technical or non-technical aspects of the job that become just plain toxic for an individual without being a growth opportunity. Maybe they deeply hate public speaking, or maybe they are deeply burnt-out on certain kinds of tasks. If it gets to this point, you need to just remove the toxin from the situation, temporarily or permanently.
• Build Confidence/Voice. I find a lot of problems are caused under the surface by a lack of self-confidence. Not contributing to group problem solving, feeling intimidated at meetings, experiencing imposter syndrome or failure anxiety, or just not taking the sort of risks that help you grow. There are a lot of ways to help build confidence, but my top 3 are a) give them some concrete homework to do in the problem domain so they feel like they are building some expertise and making progress, b) give them some “easy lay-up” projects you know they will succeed at, and c) make sure to provide public praise whenever they do succeed.
• Develop Specific Skills. Sometimes problems are due to legitimate knowledge or skill gaps. Help the person invest in those areas through all of the techniques described in “Help people be amazing at their craft”.
• Life Challenges. Occasionally, a person’s morale is suffering because of problems outside work. This is unbelievably challenging and there are no easy solutions. My only advice is to approach the problems very cautiously, with an enormous amount of empathy and respect, and to allow people the time and space to process and heal. No one wants to appear weak to their boss, so if they were actually honest with you and have brought up what’s going on, you can assume it’s pretty damn serious and not crying wolf in any respect.

Career Development. I list this item second-to-last because a) the best thing you can do for someone’s career long-term is to help them be amazing at their craft and effective at their job, and b) it’s my sincere hope that company performance standards are aligned with being amazing and effective, such that career development comes naturally. That said, I realize nothing’s perfect, and so very deliberately reflecting on your company’s performance structure and how your people are performing against it is crucial (and you should be doing this constantly - your people should be so in tune with their performance that formal reviews are essentially boring). In terms of driving that development, you can more or less just lump what the company wants into what it means to be “amazing” and include it in your efforts from “Help people be amazing at their craft” and “Help people be effective”.

Psychological Safety and Inclusion. I list these two items last because a) they are such prevalent topics in the industry right now that I don’t have much to add, and b) even if I did, they are super deep topics that would require way more space than I have here to do any justice. So suffice to say we all need to do (and continue to do as best practices evolve) our homework on this one.

Help People Be Effective

Amazing and Happy. Honestly, if you’re doing all of the above stuff right, and your people are awesome and happy, then they are already setup as individuals to be effective. The only things that can get in their way now are essentially situational factors around them.

Capacity. People can’t be effective in terms of quantity or quality if they don’t have enough time or energy to spend on important work, and there are a lot of different issues that can degrade that capacity:

• Realistic Goals. When people have unrealistic goals, they are set up to fail. Not only is not meeting the goals demoralizing, but often they go into “I just have to get this done” mode, which causes them to either start hacking, burn too long or hard and get sloppy, or ignore other activities that are even higher priority, all of which usually degrades performance and causes a nasty negative performance/morale feedback cycle.
  • FWIW, it is my firm belief that mostly-accurate cost estimation is a core requirement for being a good engineer. If you or your engineers are consistently way off on estimates, then you need to dig deeper. And make sure to differentiate between cost estimation (how long it will take to do something if you sit down and do it) and capacity estimation (how often you have time to sit down and do things). Even experienced engineers who are very good at the former can be bad at the latter, mostly because they don’t want to admit to themselves how little time they have to “get real work done”. In these cases, I usually ask people to spend a week doing detailed time tracking. It’s usually pretty damning and underlines the issue very quickly.
• Sufficient Resources. Usually people end up setting unrealistic goals when they feel like they HAVE to get something done, but they don’t have enough people to do it. Well, too bad. Grow up and call a spade a spade. If the deadline is soft, admit you won’t hit it. If it’s hard, then ask for more resources. If there aren’t any and it really is critical, then get the team to heave-ho, but mark it down as a total planning fail in the books. And then focus on the real problem of hiring enough people.
• Air Cover/Bad Cop/Just Say No. A lot of engineers don’t like uncomfortable conversations and have trouble saying no or pushing back on prioritization. While this is definitely a growth point you should work with them on, in the meantime, you need to provide that air cover for them so they can focus on getting their actual work done.
• Less Crap. It is astonishing how much time engineers can end up spending on “crap work”. This can be answering support questions for internal or external customers, working around tech debt, doing manual tasks that could be automated, or having to build repetitive functionality that could be frameworked out. Here are some quick techniques that can help:
  • Support Rotation. The best thing I’ve ever done for my platform teams is introduce a customer support rotation. It’s this person’s job to take point on answering customer questions and help them get their work done (chat, email, internal StackOverflow, sitting down with them, etc). By funneling all the interrupts onto one person, everyone else gets to focus. Just make sure to formerly allocate time for it and reduce other goals accordingly.
  • Bug|Tech Debt|Whatever Jam Day. For the accumulation of smaller bugs and tech debt, it can be really fun to take a day (or a couple) and get everyone together to squash ‘em. I usually try to reserve a big conference room for the whole day, pre-pick good candidate tasks and put them up on the whiteboard, and then let people have at it. If your team is competitive, it can be fun to put up a leaderboard too ;)
  • Customer Boot Camps. For tasks where self-serve docs aren’t a realistic possibility, doing support 1:1 can be highly inefficient. In these cases, I often find doing a proactive “boot camp day” is super valuable. I think this works best when you set a tangible goal like “develop a new feature end-to-end”. Reserve a conference room, invite a bunch of customers, present some basic information up-front, and then have everyone work on their tangible goal live. You and your entire team can be there to help them along as they go. It accelerates customer learning, provides your team insight into customers and their pain points, and helps build relationships.

Alignment. If people are working towards different goals or the wrong goals, then they are wasting their value. This usually takes one of two flavors. A more direct lack of directional alignment on a single project or system is usally because of lack of shared context or communication, and can be resolved by “getting everyone on the same page” via meetings, documents, etc. If this happens systematically with certain people or teams, then invest in their communication skills and execution processes. On the other hand, a more indirect lack of incentive alignment is often much more insidious, where a team or person is pointed in the wrong direction out of self-interest. This is usually caused either by poorly constructed performance standards/goals incentiving the wrong behavior, or low individual morale causing a person to “go rogue” and only optimize for their personal goals.

Explicit Reprioritization. Even people who are fantastic at estimating and delivering can’t meet commitments sometimes. New high-priority tasks may come in, you may uncover information that negates assumptions you made during planning, you may get hit with more maintenance interrupts than you expected, or you may have just screwed up some estimates this time around. Regardless of why it happens, the right thing to do is to stop and take a deep breath, explicitly reconsider your priorities based on the new situation, and then communicate out those prioritization decisions to stakeholders. Unfortunately, it’s far more instinctive to just try and stick to your original plan without telling anyone, continually report “almost done” to stakeholders, let yourself get sloppy because you feel behind, let those mistakes further blow up your estimates, and then get caught in a catastrophic negative feedback cycle. When you see people starting to do this, you HAVE to get them out of their spiral. For senior people, this could just be a nod that they’re doing it again, for junior folks you may have to get heavily involved.

Reflection. Reflection is critical to improving yourself, your morale, and your environment. Make sure to provide venues for reflection and to constantly model it yourself:

• Regular Team Retrospective. I don’t care about the cadence or format, but your team needs to regularly meet to reflect on what’s going well, what isn’t, and (most importantly) what they want to change. This helps folks appreciate the positives, mitigate the negatives, and generally feel empowered to drive change rather than feel like victims. I usually rotate through a handful of standard formats to keep the scope and ideas fresh (you can find tons of examples in the SCRUM literature - they are totally valuable even if you don’t ascribe to SCRUM - I only partially do ;).
• Post-Mortems. I have an upcoming post entirely dedicated to this topic, so I won’t go into detail here, but effective post-mortems after production systems or projects go awry is critical. The tl;dr version is to a) do your timeline and immediate-cause forensics beforehand so that everyone has full context on what happened and how, b) get everyone together for a joint session where you do 5 Whys-style blameless root-cause analysis and generate action items, and c) make sure action items get prioritized.

Organization. Organizing people is an art and a science unto itself, it’s a huge topic, and the optimal solution is totally situation dependent. However, there are ususally a handful of important (often contradictory) principles that are worth considering:

• Decreased Coordination Cost. Crossing team (or larger org/domain) boundaries always incurs coordination cost. Communication generally gets slowed down from “ask a quick question or jump on a whiteboard” to “weekly project meetings and dedicated email lists”. You can also quickly run into potholes due to differing team culture (e.g. in-person vs chat vs email), process (e.g. design review or not), or priorities (e.g. top priority vs “a priority”). These costs naturally lead to the goal of “full stack teams”, where a single team has everyone it needs to achieve its goals (e.g. a PM, a designer, an FE engineer, a BE engineer, a QA engineer, a data scientist, etc). In cases where you have platform or infra dependencies, this can even include engineers for those dependencies, forming a full “vertical slice” down the stack.
• Increased Specialization. On the flip side, grouping specialists together by system or domain can also lead to efficiency gains. It let’s the entire team laser focus in on and prioritize a specific problem space, such that they are much more likely to understand it holistically (especially across multiple use cases) and optimize the hell out of it. This naturally leads to “horizontal teams”, where you break up teams by architectural layer. So how do you balance full-stack teams vs horizontal teams? My take (and the take of some directors I rather admire) is to have both. Staff horizontal teams for the critical platforms and infra, and for deep specialities like ML, but then make product teams as full-stack as possible. This may mean product teams having folks who overlap with horizontal teams and contribute directly to horizontal team systems, but the hope is that these are incremental improvements/additions, not deep architectural reworkings, and can be arbitrated by some guidelines and review process.
• Sufficient Capacity. As discussed above, having sufficient capacity is critical to being effective, and ultimately the overall organization defines the headcount for that capacity.
• Stakeholder Alignment. Juggling multiple stakeholders and their competing priorities is hard and takes time and energy. If possible, you want to organize such that teams have as few distinct stakeholders as possible.
• Dependency Alignment. Similarly, managing multiple dependencies is hard and takes time and energy.
• Incentive Alignment. And finally, the more you can map organizations to consistent incentives, the less you’ll run into either explicit or implicit incentive and prioritization divergence.

Moving Forward

Depending on your experience with human leadership, I hope this post leaves you feeling one of a couple possible ways. If you’re new to the job, then I hope it opens your (maybe very wide now) eyes to the entirety of what you’re signing up for and gives you a bunch of pointers to start ramping up on. If you’re an old hand, then I hope it reminds you of a couple of useful tools to rotate back onto your toolbelt, or even just to always be deliberate with how you prioritize your time. For myself, I usually look over this list every six months or so, using it as a frame of reference to check if I’m missing any valuable opportunities for helping my team.

Either way, I hope you enjoyed reading and are looking forward to the next post in the series :)

---

1. Note the distinction between goals 1 and 3 - you can be incredible at your craft but ineffective at your job, or generating tons of value but not investing in your skills over the long run. And hopefully this is preaching to the choir, but human leadership isn’t just about making people effective in the here and now to generate value, it’s also about setting them up to be happy and successful over the course of their entire career because a) that generally maximizes the value they generate, b) it’s a huge value add for them (which means it’s fantastic for recruiting and retainment), and c) it’s just the right thing to do. ↩︎

2. Note that for the Human Leadership domain I keep using the world “help” rather than “ensure”. Ultimately, all of these responsibilities are only aspirational, but it’s worth calling out that human leadership is particularly indirect and non-determinstic (e.g., you can do everything right and someone can still be unhappy). This is super important (but self-admittedly also super hard) to internalize for your own psychological health. ↩︎

---

New to Two Ways to Learn? Welcome! Check out the manifesto, enjoy some more posts, and share them if you like! As always, I love questions, feedback, discussion, and requests for follow-up details or examples. Leave a comment, tweet at me, or send me an email!

---

comments powered by Disqus