Link Twitter Facebook LinkedIn Github Email

My first two years as a manager

It’s been about two years since I switched career tracks from software engineering to management, and I feel like I’ve learned a ton of lessons, some of which I wish someone had taught me long before I became a manager. Many of them are obvious in retrospect, but I feel like many management lessons are like that. Hopefully, others new to management might find these lessons useful as well.

Delegation and project management

When I was an individual contributor, I thought “delegation” just meant that you ask someone else to do something! But then, things I delegated sometimes got forgotten or went in completely different directions from where I had intended. High Output Management was incredibly helpful in making it clear what I was missing: “Delegation without follow-through is abdication”. I wasn’t checking whether the task is proceding as expected. I feel like this notion should be taught to every tech lead, to every employee: “This is what your manager is doing when they’re being annoying!”

Beyond basic delegation, I didn’t really know how to manage multi-person projects as an individual contributor, even when I was the nominal tech lead. They would regularly run late, and I constantly had to jump in to help pick up the slack. Becoming a manager and forbidding myself from pitching in directly gave me no room to continue being that bad at it.

The main mantra of “who does what by when” from the Manager Tools podcast has been incredibly helpful, because ensuring clarity for those criteria solved many miscommunication headaches; performance and organizational problems also become much easier to uncover. In addition, the “what” has to be based on concrete, unambiguously observable deliverables, not just effort or time spent. In other words, rather than “research options” or “develop X feature”, better deliverables are “write and send out a report” or “release feature X on internal build”. Just relying on some sort of summary status (“Are you on track? Is it green?”), as often happened in teams I’ve been on, is not enough. There’s too much room for miscommunication, misunderstanding, and forecasting error.

These aren’t the only important parts of project management—planning and forecasting are important, too—but it certainly helped!

Task-relevant maturity

Early on, I avoided telling people exactly what to do. I would ask leading questions, reflect questions back at the asker, and hint and nudge them in the direction I thought was right, because I thought that telling people what to do was the mark of a poor manager. “I have good people! I don’t want to micromanage them,” I thought. “I’m here to enable them to do a good job.”

The results weren’t always great, however: work that didn’t meet my expectations, team members getting frustrated about what I wanted. I learned that sometimes, you do have to tell people what they should do, directly and explicitly, and then check up on them frequently. People may never have done this kind of work before, and so they don’t have the tools to solve their problems themselves—their task-relevant maturity is low. Even if they could learn it on the fly, it might take them so long that it’s not worthwhile, or there may be too much risk that they cause something disastrous to happen. In those circumstances, telling them what you want them to do is a teaching moment, and not necessarily a management failure.

In addition, when I was an individual contributor, I never thought about the task-relevant maturity of the team as a whole. I was just responsible for solving problems, doing code reviews, and I never really thought about staffing in any other terms than “do we have enough people to write code”. That was pretty disastrous for the quality of what my team shipped. I had to work overtime to fix up code and catch problematic designs.

Now that I’m responsible for evaluating what kind of work people are ready to do, it’s become much more apparent to me that the team’s collective experience level and expertise should set limits on what kinds of projects we tackle. A software design-heavy project isn’t good for a team of junior coders, for example. Even if they manage to finish the first version of the project, the high cost of maintenance over time would be an incredible waste due to design flaws making the system buggy and fragile.

These days, I think a lot about matching people and teams with appropriate projects, and ensuring that I’m being just directive enough.

It’s possible to be too helpful

On the other hand, despite trying not to be directive early on, I did try to be as helpful as possible as a manager, giving lots of suggestions and helping people solve problems. I thought I was helping my team to produce better quality work! Maybe I was, but I eventually also realized that I was having negative side effects. Being so involved stretched me thin, and more importantly, crowded out my senior engineers from leading and influencing. I had to pull back and delegate this responsibility for technical leadership, so that my team could function more independently of me and the technical leaders I was trying to cultivate actually had chances to lead.

I still struggle with this (I do like software development!), but where I can, I try to ask myself who else could or should be helping instead of me. In addition, rather than making suggestions as I check in on the quality of work and technical strategy (my delegation follow-through), I try to couch my words in terms of expectations rather than suggestions.

Sponsors are critical for career progression

I didn’t really appreciate how important sponsors are for people’s careers until I became a manager, when I started writing performance reviews and putting people up for promotions. Before, when I was a staff engineer (a relatively senior position at my company), I took for granted that people trusted me when I gave peer reviews on who was doing well and on what.

As a manager, though, upper management was much more skeptical of my evaluation of people’s technical skills (rightly so), and so it mattered a lot to have other senior software engineers as sponsors that could vouch for my people, especially as they got to the higher end of seniority. It might sound like politics, but to me, it’s really about chains of trust, where my promotion proposals are treated skeptically like self-signed certificates. Now, I know to seek out sponsors that have the company’s trust when making the case for promotions.

Planning around my energy levels

When I was a software developer, I had a lot more control over my schedule and energy. If I needed a break in a marathon coding session, I could take it! As a manager, though, my days often fill up with meetings, and it’s not easy to just move those around to manage my energy levels. Even if I need a break, it sucks for the other person to cancel a meeting 5 minutes before it starts.

These days, I pre-schedule 30 minute mental breaks, at least once a day if not twice. That time is sacred, not to be spent on email, meeting prep, or any other work—not even mulling about things. Usually, I’ll grab a snack, a cup of tea, and just sit. Sometimes, I’ll try a mindfulness exercise or take a walk. It’s a chance for my brain to disconnect and for me to recharge.

In addition, I used to try to stack all of my one-on-one meetings with my team on one day of the week, in an attempt to reduce my context shifts from “one-on-one” mode to other types of meetings, but that was just too exhausting, not to mention a bit unfair to the people who I met with later in the day. I can’t keep up more than maybe two hours of active listening at a time, so these days, I spread my one-on-ones across the whole week.

Always be selling

I’ve realized I need to always be selling the team’s mission. This was easy to remember when I was quickly growing the team, because I was heavily involved with recruiting and hiring, but it was harder to remember to do when I wasn’t hiring. For the people already on the team,though, I’ve found that if I’m not continuously selling what our mission is and what our plans are in the future, people can feel lost, uninspired, or drift on to thinking about what else is out there.

I can’t say I find this easy. Selling is an emotionally taxing task for me, and I definitely feel more tired as I put in more effort, but it feels worthwhile nonetheless. It’s worth it to have the team feel productive, optimistic, and creative.

These probably aren’t profound lessons, but they weren’t obvious to me when I started, and I feel like they’ll be useful lessons for me no matter where my career takes me, whether it’s back to being an engineer in the future or continuing on as a manager. I tried as much as I could to learn from helpful books like High Output Management, but the real experiences in the past two years reinforced my book learnings and added nuances that I wouldn’t have noticed otherwise. I’m looking forward to what I learn over the next two!

The end of accountability

I expect that to many people, “accountability” seems like a euphemism for “blame”. That’s hardly surprising, given how it’s used in the media and news.

From a recent Vox article on the opioid epidemic:

An overwhelming majority of Americans want pharmaceutical companies to be held accountable for the opioid epidemic, according to a new NPR and Ipsos poll.

From an op-ed by Chris Hughes, a co-founder of Facebook:

The government must hold Mark accountable….Any day now, the Federal Trade Commission is expected to impose a $5 billion fine on the company, but that is not enough.

From a Radiolab episode on Good Samaritan Laws:

“When you look at the [criminal case for reckless endangerment of EMTs], he needs to be accountable for those actions because he knew the risks that were involved.”

These uses of “accountability” feel very tied up in desires for justice and punishment: firings, fines, convictions. Consequences.

In the workplace, though, I see many uses of the word “accountability” for a different, less negative idea, one that I think is closer to “ownership”. This use is about who’s owning the final decision-making to ensure a project is successful. The accountable person is the one that knows what’s going on, what has already happened, and what needs to happen next.

That meaning of “accountability” is really useful, because I want to give my team accountability for their work; that empowers them to do what they think is best and gives them the recognition for it. Accountability is also important to divide up clearly, because otherwise, people pay a huge coordination tax, accidentally stepping on each others’ toes, getting frustrated trying to reach consensus. It’s not surprising that I see “accountability” often being used among managers.

My use of “accountability” isn’t meant to be about who gets punished when something goes wrong, since focusing on apportioning punishment or blame is often harmful to effective teamwork.1 But I can’t control how language evolves; when I’ve tried to use “accountability” in the way I describe above, I too often see my team look uneasy—maybe on guard for the threat of punishment. Every time, I feel I need to reassure folks and explain the difference I see between “accountability” and “blame”, and when I do, it seems like I’m rowing upstream against the current. I don’t want my team looking over their shoulder or trying to cover their ass.

That’s why instead of “you’re accountable for this”, I’m going to start saying “you’re the driver for this”. The driver is the one at the controls, keeping things on track, taking detours, and course correcting to get things done. It conveys the same meaning, but without the implied threats. At the end of the day, what matters to me is that my team can work effectively together to build great products, and the word “accountability” is doing more harm than good for that. I doubt I’m alone in feeling this way, and I think it’s time for that use of “accountability” to end.

  1. Software engineers might have seen this idea that throwing blame is counterproductive in the form of blameless postmortems. Instead of focusing on who should be punished or shamed, these postmortems focus on learning and self-improvement, creating a safe space for really understanding what happened and preventing similar issues in the future. The book Difficult Conversations calls this moving from a “blaming mindset” to a “problem-solving” one.

Modeling Organizations

One of my favorite things about High Output Management was the way Andy Grove treated managing organizations as a special case of managing systems. He starts off his book with a model of a company as a breakfast factory.

Similarly, Acolyer in this blog post applies ideas from optimizing distributed systems to the scaling of organizations:

I was thinking about the advice I should give to the CTO of a fast-growing company struggling to maintain velocity amongst all the competing demands on his time. And it occurred to me that the Universal Scalability Law has a lot to say about this situation.

This also reminds me of Will Larson’s posts lately on systems modeling of organizations, such as this one on modeling reliability of an organization:

We’re doing an annual strategy refresh on how we’ll approach security, reliability and such, and incorporating modeling into developing these strategies has been a surprisingly effective brainstorming tool.

I’ve found posts like these to be very useful, so hopefully you will, too.

100 Years of Bauhaus

When I was in high school, I took a class that attempted to integrate many subjects through the study of one time period in history. What I remember most fondly from that class was our study of Bauhaus, the art school in Weimar Germany that started 100 years ago. This amazing website celebrates that history with details of the people, the art, the settings, and the classes. Well worth an evening to peruse!

Transitioning to management

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.1 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.2 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.

  1. Service level objectives.
  2. The entire product development organization, including Engineering, Product, and Design.