I was asked a seemingly simple question recently: What does success look like as a manager?

On the surface there are as many answers as there are managers. Success is shipping the product. Success is hitting the team’s KPIs. Success is solving a deep technical problem. Success is nailing the roadmap. Success is increasing ARR. Success is solving the customer’s need. Success is fixing bugs. Success is clearing technical debt. Success is helping an engineer level up. Success is solving a process dependency problem. Success is …

All of these answers are fine and good. But I believe the question is missing a phrase, a phrase that changes the nature of the question and the nature of the answer.

What does success look like as a manager for you?

It’s now not about an outward definition of success, but is now instead entirely focused inward. How do you, as a manager, define success?

For me, the answer is both simple and complex. Simply, I’ve achieved success when the teams I manage hold themselves accountable.

What does it mean for a team to hold themselves accountable? Here is the complexity. It means that when there are disagreements, the team works them out without using me as an intermediary. It means when someone on the team deviates from team norms, the rest of the team will call them on it. It means when team norms aren’t clear, the team will surface the issue and work to clearly agree on them. It means the team will spontaneously retrospect and solve problems in the moment. These things are all part of the layers it takes for a team to hold themselves accountable.

Here is an illustration from one of my past teams. At standup one day, as the team was walking the board and talking over work, one of the engineers noted that several items had been sitting in review for a long time. This had been a persistent problem, but not one I as the manager was focusing on at the moment. This day, however, the team decided to solve it. They took a moment to talk over possible tools to help and settled on trying one that would send them reminders of open pull requests. Then they looked at process. They all agreed to ensure each of them set aside time during the day to do code review and what the expectation was for that code review. Did it mean running all the code and tests? Was it enough to just look over the code? etc. They agreed on the process, the tools, and then they agreed on the timeframe, committing to try it for a week.

The change worked great. Review began happening reliably and the team held themselves to it. This caused other ripple effects. Pull requests became smaller. The act of stacking pull requests where one pull request built on another pull request went away. Overall task size shrank. All because the team held themselves accountable.

A lot of pieces have to be in place for this to happen. You need a team that respects each other. They have to know it’s a safe space to speak up, to suggest ideas, to call each other out. They need confidence and comfort in the process, to know how it works, and how they can change it. None of this comes overnight, it builds over time. It took this team about nine months to get here.

My job as a manager is to create the environment where this can happen. It takes time. It takes persistence. It takes adapting to the individuals, to the team, and to the environment. In an industry where engineers are hopping jobs on average every eighteen months and companies are reorging just as often, this isn’t easy. But when it all comes together, it’s magical.

As a manager this is what success looks like for me. As a manager what does success look like for you?

—

This post was originally sent out as part of my newsletter, Learning Better Management By Sharing. Please sign up if you’d like to receive posts like this in your inbox. Thank you for reading.