Towards being a great manager

Most people managers are bad.

People management doesn’t come naturally to most people, most companies have little or no training in place for managers, and managers often get “promoted” into management because they were the strongest or most senior IC on the team when a manager role opened up.

On top of that, being a people manager is often a thankless path, and you’ll hear executives and senior leadership question why we have people managers at all. After all, can’t HR approve vacation requests and submit raises for approval?

Despite the prevalence of bad managers, and the barriers that sometimes prevent great managers from doing their best work, there are very few things most of us will achieve professionally that are as rewarding as helping a team of people work together to achieve something they didn’t think they could do. Being a great manager is a superpower, and the path to get there may be shorter than it seems.

Below are the traits that all of the great managers I’ve worked with have shared. Each person manifests them differently, but they all have these traits.

If you internalize these ideas and put them into practice, you won’t automatically be a great manager, but you will be on the right path.

git blame culture, metaphorically

Software engineers rely on a tool called git to manage changes to their code — git makes it easier for many engineers working on the same set of files to all make their changes without losing work, among other things. For engineers, a common task when working on large, shared codebases is to run a command called git blame. This command tells you who made the last change to each line of a file, like this:

git blame some_file =>

a9b531b1 (David Colby 2022-05-13 20:26:44 -0500  20) def wild_method
a9b531b1 (David Colby 2022-05-13 20:26:44 -0500  21) do_something_wild
a9b531b1 (David Colby 2022-05-13 20:26:44 -0500  22) end

With one command, I can learn who is responsible for each line of code, when they made the change, and using that random string of numbers at the beginning I can even see everything else that changed at the same time that line changed. Incredible power.

git blame is a wonderful tool for collaboration on larger teams and is even useful if you are working on a codebase alone. Six months from now, you may not remember why you wrote that weird line of code at 2am. git blame gives you a simple way to see the full set of changes in context and, if you’re diligent about writing clear documentation you might even have a nice explanation of what you did and why attached to the changeset.

git blame is a tool for good, when used for good.

It makes it easier for teams to learn about the history of a project, identify who is most likely to have context for a question you have or a bug that has been uncovered, and it helps you and your team collaborate more effectively.

git blame is also a tool for literal blame. We can use it to find out who made a change that caused a bug so we can point the finger at them for failing. In some engineering cultures, the most important use of git blame is to figure out who to be mad at for the latest outage or poorly executed feature.

Feedback, the basics

Leading without giving feedback kills your team’s culture. No one knows where they stand and fear spreads through your team.

Learning to give useful feedback is a key skill for transitioning into a leadership role. Investing in building the habit helps you become a mentor and leader for your team, helping them grow beyond their current role into the people you need them to be as your business scales.

Even better, learning to give feedback doesn’t take months of practice or studying. You can just just start doing it, for free, right now by taking these two steps.

First: Notice specific things that people on your team do.

Second: Tell them that you noticed the specific thing they did.

Easy, right?

Okay, sorry, there’s a little more to read. Those are the two steps, but we have to talk a little more about step two with a few examples.