[ Content | View menu ]

What does success look like as a manager?

Mark Mzyk February 25, 2019

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.

The Evils of Snark

Mark Mzyk February 11, 2019

Snark, noun
: An attitude or expression of mocking irreverence and sarcasm
Merriam-Webster Dictionary

Even if you’ve spent very little time in tech, you’ve almost certainly heard snark. It is the lingua franca of tech. We use it to communicate and bond about shared frustrations, especially about the everlasting struggle to get our code and systems to just do what we want.

Except this is the good interpretation. It doesn’t take much for snark to turn dark. That sarcasm that can bond? It also carries with it an undertone of contempt. Contempt for the code and systems we work on. But we don’t stop there. We carry that contempt to the person who wrote that code, who helped create the system we struggle against.

There is a reason the unhealthiest teams use the most snark. They’ve lost respect for those around them. They’ve lost their empathy. The expression of their frustration is now expressed in a way to make themselves feel better by showing how they know better. They have stopped trying to understand how everything arrived at this point. They have stopped trying to understand how those who wrote the code or work with them operate under their own constraints and their own struggles.

Snark is a way of giving up. Snark says I know better, but I’m powerless, so I’m not going to try and make things better.

If your team has a lot of snark, they are sending a message. They are struggling and need help. It’s not easy, but it’s possible to dig out of this. The goal is not to drive out snark simply by forbidding it. That’ll just drive the snark to back channels. Instead question it. Ask: what frustration is this snark expressing? What is in this team’s control to change? Redirect the team or person to figure out what about their situation they can make better. Then start taking small steps to change it. For those things beyond the team’s control, explain why the system is the way it is. Explain the possible constraints others are operating under. Explain the history that has lead to this point. Explain a vision of a path out. Give context and direction. Give agency.

Agency is the enemy of snark. Once there is agency the focus is on using it, on making the situation better. Slowly the snark will fade. It won’t be easy. Habits don’t disappear over night. Continue using the snark as a signal, finding the change you control in it. With practice the team will start to find what they can control themselves. Eventually everyone will forget snark used to be the norm.

What if someone just won’t give it up? Everyone else has moved on, but they continue to engage in snark. They are isolating themselves, setting themselves up for misery. They’ve had the opportunity to learn and move on with the team. If they simply won’t go down the same path, you’ll likely need to let them go. Snark still pervades tech. It’s not dying out anytime soon. They’ll be able to find a place that accepts it, even welcomes it.

Snark is currently ingrained in tech, but it doesn’t have to be this way. Empathy, context, agency. These are the tools you have to eliminate snark. These are the tools that lay the foundation for a positive and healthy culture.

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.

Learning Better Management By Sharing

Mark Mzyk February 5, 2019

Group of diverse people looking at a phone screen that one of them is pointing to.
Photo by rawpixel

I am starting an email newsletter to share my thoughts on software engineering management. It is titled Learning Better Management By Sharing.

Please sign up if you’d like to receive my thoughts as soon as they are ready to go out. The newsletter will get updates first, but I’ll also post all the updates to this blog as well. The newsletter will be a bit more curated than this blog, as only software engineering management topics will be sent there, while this blog is still my personal blog, so the topics here will be what strikes my fancy.

If receiving an email newsletter isn’t for you, this blog does have an RSS feed, if that suits you better.

Thank you for reading and for subscribing.