About a year and a half ago, I switched roles from software development to management, and it’s one of the most satisfying career transitions I’ve had. There were a few key factors and resources that I think helped me the most in making the transition.

High Output Management

Until I read High Output Management, I didn’t really know what managers were supposed to do. I knew I had to hire people, write performance evaluations, and help develop people’s careers, but was I supposed to be involved in the architecture of my team’s systems? How about the code quality? Shipping on time? Aren’t those my tech lead’s responsibility?

Andy Grove’s declaration that manager are responsible for the total output of their teams was a startling revelation. In the vein of the best of management advice, it was in retrospect both boringly obvious and amazingly clarifying. Yes, my tech lead was responsible for our systems’ architecture, our code quality, and our timetable for shipping. But so was I, because I was responsible for everything they were doing, too. I wasn’t writing code myself, but I was responsible for the code my team was writing. I was delegating all of those responsibilities, but I still had to make sure they were getting done and getting done well. The team was a way for me to scale my output beyond what I could do myself. Luckily for me, my company and my boss agreed with Andy Grove, so it was crystal clear what my job was.

The second thing that High Output Management taught me was to treat my team as another system that I needed to build. One could apply a lot of the same principles from Site Reliability Engineering to building a team: catch errors early, add monitoring, and don’t rely on people being perfect to make things work. A reliable team required clear goals and expectations the same way a reliable system required clear SLOs.^[Service level objectives.] I was responsible for my team, but I shouldn’t try to inspect everything they do, and so adding monitoring for quality and progress would be important.

No more coding

My “grand-boss” gave me some advice when I became a manager: stop coding.

I’ve heard vociferous disagreement about whether managers should code, but I think stopping was essential for me. No one likes a micromanaging boss, and if I were to have continued coding, the temptation would have been too great to step in and do my tech lead’s job for them. Stopping forced me to do work through my people instead of for them.

I also mostly stopped doing code reviews. That might sound odd, since, as I mentioned above, I was responsible for my team’s code, but if I were to have continued doing them, my team would have written worse code. Since I was no longer coding myself, my feedback would have been worse, but the big “I am your boss” sign on my forehead would have also given my code reviews undue authority, no matter how much I would have tried to make my team feel safe to disagree with me. So, no more code reviews.

Finally, as the team grew in size, not coding also freed up a ton of time for me to focus on other responsibilities like feedback and coaching.

Switching teams

I switched teams to become a manager, which meant that I was brand-new to the people, to the codebase, and to the problem space. The lack of prior context on this new team removed some crutches and temptations, so I was forced to get better at some key skills:

• I didn’t have prior relationships with the team, so I had learn to build them from scratch through one-on-ones.

• I didn’t have any previous expertise, so I had to ask better questions to understand what was going on.

• I hadn’t seen them work before, and I wasn’t writing or doing code reviews, so I had to learn to size people up without writing code together.

• I had no expertise in this new area, so I had to learn to work through other people instead of diving in myself.

At the same time, since I wasn’t managing former teammates, I bypassed the need to address any resentment or awkwardness that could have come from being put in charge of my former peers.

Starting with the people

When I first started as a manager, I met with our SVP of EPD.^[The entire product development organization, including Engineering, Product, and Design.] He had a policy of meeting every new manager in his organization.

His advice was frank and direct. “As a software company, we don’t really own anything. We don’t have factories or assets or anything else of tangible value. All we have are the teams that we’ve built and the intellectual property they produce. Your job is now to be a steward of those people. I want you to get to know every person on your team so well that if I were to ask you in three months what book you would give each one as a gift, you would have a good answer.”

We had some big projects that we needed to start immediately when I joined the team, but I made an effort to focus and make time to get to know my people, leaning pretty heavily on my newbie manager status to ask lots of questions. Building that trust has paid back ten-fold. People will forgive a lot of mistakes if they trust you, and that was essential when I was fumbling through my first year.

Radical Candor

I was really skeptical of this book at first because of the title: Radical Candor. It sounded like so much smarmy business self-help dreck. I was wrong.

It’s a terrific book on why it’s important, as a boss, to be frank and direct with the people on your team. I’m a fairly non-confrontational person, so this was (and continues to be) one of the hardest things for me to do. Holding back because of the fear of confrontation is doing a disservice to the people on my team, and giving them feedback early and often is a kindness.

The Manager Tools Podcast

My prior managers had never been structured in how they did the nuts-and-bolts of management, so I didn’t have a good sense of how to do the basics of one-on-ones, give feedback, coach, or delegate. I needed some resources that would get me started, and the Manager Tools podcast perfectly filled that hole in my experience.

In some ways, the podcast is a little overly prescriptive and framework-heavy, but when I was first starting out, that was particularly helpful. I could put my own stamp on their advice later on after I’d gotten more familiar with the day-to-day responsibilities. I highly suggest the episodes in their self-described Hall of Fame list.

There were a variety of other books and resources I found really helpful, but the ones above were truly essential in understanding what to do and why. A selection of some other things are below:

• Difficult Conversations: I’m still working my way through this, but it’s been a really valuable supplement to Radical Candor for helping me overcome some of my fears of confrontation.
• Turn the Ship Around!: A real-life example of scaling leadership out of the pitfall of centralized command-and-control micromanagement.
• The Five Dysfunctions of a Team: A “fable” of what the failure modes of teams can be and what they should look like instead.
• Good Strategy, Bad Strategy: A framework for understanding how to build a clear strategy that solves real problems.
• Getting to Yes: This is the classic book that came up with the concept of “BATNA”—Best Alternative To Negotiated Agreement—as a way to capture relative negotiating power. It also reframed negotiation as a collaborative problem-solving endeavor rather than an adversarial zero-sum process.