I've been continuing my posts on Engineering Management the last few weeks. To keep email volume reasonable, I'm going to continue rolling these up into ~biweekly digests for this newsletter. I hope you enjoy the posts, and if there are engineering management topics that you're interested in, feel free to shoot me a question
You can see the whole series here or read the new articles in the email below.
When moving into an engineering manager role, one of the toughest transitions for me was mentally adjusting from being responsible for tasks and projects that I owned to being accountable for the output of a team. As I discussed in What Engineering Managers Do, I like using Andy Grove's definition of a manager's output: the output of their team as well as the output of any teams that they're influencing. Manager's thus bring value by improving those outputs. This potentially allows you as a manager to have a much larger sphere of impact than an individual contributor working on a single project at a time. But it also means that you will be held accountable for actions that you may not have had direct control over. This can be distressing for new EMs (it was for me!) as you realize that "working harder when things go wrong" may no longer be a viable strategy for avoiding failures.
The first time a manager gets negative feedback for work that wasn't personally in their control it is tempting to prevent it in the future by micromanaging or using themselves as a safety net. Micromanaging has a horrible reputation, but it is actually a very natural reaction for engineers who are used to competently completing tasks and then being praised for it who face criticism when a task they know they could complete is not done adequately. It is a very human response at this point to say "well I know how to do that, let's make sure you're doing it the way I would". When that is repeated over time it leads to the familiar and awful rhythm of low trust between the manager and teammate, low initiative from the teammate and frustratingly slow progress.
Acting as a safety net for employees is a more subtle task for managers. They may know they don't want to micromanage, but instead they might choose to tackle the complex, likely-to-fail parts of a task themselves, or perform a "diving save" taking over a project when it looks like it might not complete successfully. This appears better than micro-management -- employees have ownership of their work, at least until it goes off the rails. But it leads to many of the same issues as pure micromanagement: employees who don't grow because they're not learning to do the hard work themselves, a disconnection from consequences that means a lack of ownership from the team, and a lack of trust that will eventually erode morale. Like micromanagement though, this approach doesn't scale. You and your team will both be locked to a limited amount of responsibility that is based on your capacity as a manager to be in the details of everything. Growing as a leader and a team requires a different approach.
The only solution for handling accountability that scales is developing a high performing team. It isn't a problem to be held responsible for the output of a group that you trust and believe in. And high performing teams have a tendency to generate new leaders, allowing you to do less and/or focus on higher level work and grow your career. But creating a team like that requires effort and humility over time. This means as managers we have to be willing to take some short term failures.
While your team is in a growth stage (any of the forming, storming, norming steps in a group's development) you'll need to expect that their output will not always meet your individual standards. There are a few things you can do to mitigate this from an accountability perspective.
Firstly it is important to match your expectation setting and commitments to your team's maturity. If you're not confident that a team can make a commitment without you doing the work yourself, don't sign on for the work. And certainly try to limit the number of simultaneous challenging projects you're taking on so that you can focus on enabling your team when you do have challenges. This may sound naive and frustrating to people who feel they have to take on the work. The key thing to understand are that you can't do this forever -- eventually the team has to grow it's capacity to something the organization can accept, or either you or your management is failing. But in most circumstances it's better to give an honest no up front than make excuses for a failed project 3 months down the road. There are organizations which won't reward that calculus -- in which case you should probably document your concerns and continue anyway, hopefully developing some credibility for the next such discussion.
When you're in this type of growth stage, it's also important to understand the impact of the work that is coming in. I like the analogy that Gregg Dedrick shares here of juggling crystal and rubber balls. Some tasks are like crystal balls -- if you drop them there are expensive consequences and no second chances. But most tasks are more like rubber balls. If you drop one you'll get to pick it up and try again. It's important to understand which are which. If your growing team is being asked to pick up crystal ball tasks it's important to exercise caution. This is where it's extra important to be clear about your team's capacity, and is a case where it may be appropriate to get more involved personally to ensure success. Of course if most of the tasks coming your way seem like crystal balls, it's worth digging into that more and understanding what is driving that, and if some of them are actually more droppable than you think.
As your team grows you'll be able to start shifting the work you take on and saying yes to more things. At this point it's important to nurture the ownership that your team is feeling. Be generous with credit for successes while continuing to own accountability for failures. Within the team, make sure you are holding high standards and giving clear feedback when needed. Nothing undercuts an empowered team like somebody who isn't contributing at the level of the rest of the team and isn't held accountable for that. That said, leave room for failures to continue happening. Even high performing teams have room to grow, so the principles for a growing team still apply -- let people take on rubber ball tasks that are a stretch,
Managing a team that feels ownership of their work and is growing into higher levels of capability is more rewarding, less stressful, more educational, and more powerful for your career than micromanaging. It's also ultimately morally good -- you're creating an environment where other people can thrive and use their gifts and abilities.
In my last post I discussed the importance of delegating work to your team and giving them room to do important work. Delegation like this is crucial for effective managers, it's the only way that you'll ever have time to grow and it's the only way that you can help your team grow. But it isn't always easy, and effective delegation certainly isn't as simple as giving somebody a task and walking away. I've picked up a few principles over time on how to delegate well, as well as a few practices that have been helpful for me in finding the right mix of delegation. The principles that have been most helpful for me when delegating work have been to "trust by default", thinking about people's ability in terms of "task relevant maturity", "not being essential", and "giving objectives and context rather than just tasks".
The most important step to beginning delegation is to trust by default rather than making people prove themselves before giving them opportunities. Trusting in this context doesn't mean blindly handing people arbitrarty work and expecting it to go well. But it means being willing to give people reasonable stretch opportunities and then properly supporting them through them, and doing that starting early on in your management relationship with them. Ideally trust will build as you work with a teammate, but if you default to a "prove it" attitude it can be tough for teammates to ever gain your trust. If this proves difficult for you it may point to a higher level problem like you being too attached to doing work yourself or not having the right people on your team for the work you're trying to accomplish. Don't jump to that last conclusion though -- it's important to look in the mirror first.
When evaluating people's ability to handle a task you're considering delegating to them, you shouldn't be looking at their title or general track record, but instead focusing on what Andy Grove calls their task relevant maturity -- how experienced they are at the specific task under discussion. It's possible to give brand new employees tasks that are easily within their wheelhouse and very senior team members tasks that are outside of anything they've done before. If you base your support and expectations solely on how senior somebody is or how successfully they've handled generic delegated work in the past, you're likely to mishandle the delegation.
Adjusting well based on task relevant maturity means giving teammates who have less experience of success with a task more support and monitoring their progress more frequently. This doesn't mean micro-managing, but being a resource to the employee, checking in on the task regularly during 1-1s and reviewing any incremental steps in the process for signs that you've become misaligned on the objective or that things are off track. The key is that you're a support resource and a quality checker, not laying down specific restrictions on how the task is done. For teammates with progressively more experience with the task you can reduce check-ins and explicit offers of support to match their comfort level, though you should never completely ignore projects or lose track of what is going on with anything important.
A 3rd principle of delegation is more a warning post that you're not delegating enough. I never want to be essential for any task as a manager. If I get hit by a bus or leave the company, my ideal is that everything in the teams reporting to me will hum along perfectly for a long time, with my absence being felt only in lost potential in how I could have helped people grow, or solved higher level problems in the company. That means that if I see areas where I am essential for success, rather than allowing that to inflate my self importance I should view it as a sign that I need to grow somebody on my team into that role. If there are people who could be doing it but I'm not giving them the opportunity, it's time to delegate. If there's nobody who can do the work, then it's a gap on the team that needs to be filled by training or hiring.
Finally, it's important to delegate at the right level. Delegating completely defined tasks with a prescribed solution is just asynchronous micro-managing. Instead you should delegate objectives, and give people the context they need to make good decisions. For technical work this can come through in how a Jira ticket or Github issue is written. Does it describe a technical change that needs to be made without explaining why? Or does it describe a user problem, with context around what we know about past attempts to solve it or any relevant constraints[^1]? When having a tech lead replace them in an interview, a manager could choose to give them the list of questions they have been asking and ask the tech lead to read from the sheet, or they could explain what they're looking for in the position, any constraints around what will be accepted by the wider organization, and then have a discussion around the interview questions that the tech lead might want to use. The second way will engage the tech lead's brain, give them ownership and maybe help the manager learn something.
It's good to understand the principles and theory behind delegation, but what if you're not getting it right in practice? When I discovered last year that I was not delegating nearly enough, there were 2 activities I went through that helped me do a better job with this: a weekly review and being extra explicit about ownership
After getting feedback from multiple folks that I was trying to do too much work myself, my first step to getting better was a simple 30 minute weekly review where I went through all of my activities from the week and listed out anything I'd spent time on that wasn't part of what I considered my "core responsibilities". From that first list I then considered 2 questions: who else could be doing this work, and are there good reasons why I'm doing it instead? If you've never thought this through before you may find some good low hanging fruit where you're doing work that somebody else on your team would benefit from doing without a compelling reason. It's perfectly fine if many of the things on this list are more complicated though. There may not be an obvious person for every piece of work, or there may be good reasons why you're picking it up. In those cases the goal of the exercise is to bring clarity and give you time to think about what would need to happen to move these tasks to a teammate who would benefit from the work and/or be a more appropriate fit. Maybe you need to invest in coaching a teammate, have a difficult conversation with a peer about ownership, or just need to document the work so that other people can do it.
I started this exercise focused on "non-core" work, but scaling yourself as an EM means constantly giving up work and letting others grow into it. So feel free to consider all of your responsibilities and see if there's an opportunity for others to grow into some of those while you grow into broader and new opportunities or just get more time back to invest in people.
Another thing I found helpful when starting to document more was being explicit about ownership. If you have been handling a type of task yourself and want others to step into it, there are benefits to creating a clearly defined role or set of work that you can give somebody. Without this it can be easy for some piece of the work to fall back to you or be missed. For instance if you've been doing most of the project management on tech projects and want engineers to step into that, it might be helpful to create and document a "project tech lead" position that you assign for each project. You can then be explicit that the project tech lead is responsible for keeping the project on schedule and identifying or escalating threats to the project plan along with any other duties that make sense. You can also be explicit about what ways you expect to be supporting a project tech lead and any responsibilities that still fall on you as an EM.
Delegating work well is an incredibly rewarding activity. You give others opportunities to grow. You can reduce your own stress and increase your capacity. You'll learn from seeing other people take different approaches to work you have done in the past. Over time this will help create a team that is excited about their work since they're empowered to do meaningful work and continue growing over time, and it will allow you to continue tackling new challenges as well. So take some time today to figure out where you can find new places to share your opportunities and create new ones.
Giving good feedback to others is a core piece of any manager's job, but it's also one that is rarely taught formally. We all give feedback in some form or other every day: we leave reviews, give compliments, complain, or thank people. But making the feedback effective is a lot harder, and as a manager it is well worth the effort to consider how you can improve. Let's talk about the why, when and how of effective feedback.
The majority of people-related disasters I’ve created originate with my choice to not say the hard thing. On my short list of critical leadership skills, the ability to “say the hard thing” is right after “delegate until it hurts.” - Michael Lopp
As managers we give feedback because it is the core way we drive improvement. We are not generally doing the work, instead we evaluate the work and give feedback. That means making it clear to the team when we see things that are or are not working with the end product, the process to build that product or the inner dynamics of the team. And it means being clear with individuals what is or isn't working. Improvement for teams and individuals is a function of practicing the relevant tasks over time with useful feedback loops. Teams will get some natural feedback loops from the result of their work, peer feedback, and self evaluation but those are unreliable and/or slow. As a manager you are responsible for making sure that your teammates have tight feedback loops that allow them to understand quickly when things are going off track and correct them, or when they are doing something well and have an opportunity to do even more.
“if it hurts, do it more often, and bring the pain forward.” - Continuous Delivery by Jez Humble and David Farley
It's important to understand that feedback isn't something that should happen only at performance reviews -- good feedback is continuous. It's helpful to have regular times for giving and soliciting feedback like a weekly 1-1, but even those should be a backstop -- giving feedback directly after you observe a behavior or impact is often the best time. We want to minimize the feedback loop so that your teammate can respond quickly, and also minimize distance from the event which can often bring skewed memories from both parties. For those who find giving feedback hard or scary, the idea of doing this regularly might seem overwhelming. In this case though we can benefit from the devops principle of doing hard things more often. When feedback is regular and low intensity it can be easier to give and absorb, whereas a mountain of feedback at a performance review can be overwhelming and scary to give. Early feedback also allows for quicker course correction, hopefully making those difficult review conversations less common. Performance reviews should never contain surprises, they should just be formalization of an ongoing conversation.
"Radical Candor" is what happens when you put "Care Personally" and "Challenge Directly" together - Radical Candor by Kim Scott
Radical Candor has influenced my thoughts on feedback more than any other single source, and while the book is worth reading in full, its core idea is easy to summarize: good feedback comes from caring personally about the individual and being willing to challenge them directly. We've all dealt with the jerk who is happy to give unfeeling and unwelcome feedback on anything -- that's challenging without caring, what Kim Scott calls "obnoxious agression" in the book. More common and insiduous though is what she calls "ruinous empathy" and "manipulative insincerity" -- caring or not caring without challenging and thus simply avoiding feedback altogether. The single biggest antipattern around feedback that I've seen is choosing to not give it until it is much too late. People who give good feedback have plenty of empathy and understand the impact of their words -- but they also understand how people can be hurt when nobody tells them the truth, so they let that empathy drive them to choose their words carefully and judiciously speak out with courage.
The Situation-Behavior-Impact method is simple and direct: You capture and clarify the Situation, describe the specific Behaviors observed, and explain the Impact that the person’s behavior had on you. Center For Creative Leadership
If you're struggling with how to express a certain piece of feedback it can be helpful to prepare in advance. I usually benefit from writing down my thoughts and have found the SBI method from the Center For Creative Leadership very helpful here. For any feedback you want to give, frame it in terms of the situation (when and where did this happen -- any relevant context), the behavior you observed from the person receiving the feedback (what did they do), and the impact on you or that you observed. This model is helpful in giving a clear way to write feedback as well as avoiding a bunch of potential traps. It leads you away from guessing at anyone's intent or motivations, grounds the feedback in a real situation and behavior, and makes the severity of the feedback clear. Optionally you can continue to a 4th step -- asking the person receiving the feedback what their intention was and giving them a chance to share their thoughts, hopefully leading to a productive 2 way conversation.
Feedback is a gift - Michael Lopp
So far in this piece I've focused on giving feedback, but it's important to remember that feedback is a two way street. Giving feedback well gets easier when we develop an attitude of curiousity and gratitude when we receive feedback. Remember that all feedback is a gift -- even if some pieces of feedback are easier to work with and better delivered than others. Creating an environment where others are comfortable giving you feedback is hard -- if you're a manager you will have to work upstream to overcome some natural power dynamics if you want real honest feedback. It means being persistent in asking over time, building trust by proving you care, and being willing to take and be grateful for hard feedback when it does come. Ultimately there is almost nothing you can do that will help you more as a manager than creating an attitude where people are comfortable sharing unfiltered truth with you -- you'll grow faster and be more effective as you learn what is really happening around you, and it is much easier to share hard feedback with people who trust that you're listening to them. Feedback is a gift. Give it, receive it and value it.