Ben McCormick

BlogSubscribeSpeakingTwitterAbout

Engineering Management: Handling Accountability

I’m currently taking some time away from my job on parental leave, and it seemed like a good time to reflect on the lessons I’ve learned the last few years about engineering management, this is my third post, you can see a list of past posts on the series page

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,

Accountability for a high performing empowered team

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.

More Engineering Management Posts

This is part of a series of posts on Engineering Management. You can see the whole series here.

Content

Meta

Copyright © 2012-2021 · Ben McCormick