A Wild Year of Learning to be a Manager
An essay on being a manager in 2020 and some strategies I've found most useful to be a good one 🧑🏽💼👨🏼💻👩🏾💼👩🏼🔬🧑🏻🔧👩🏽⚖️
Wed Dec 30 2020
Table of Contents
Management and leadership is a strange job. It really is like learning how to swim; you can read about it all you want but at some point you're actually going to have to get in the water, flail your limbs, and try to stay afloat. The concept of swimming is familiar and you understand that you're supposed to kick your legs and move your arms, but the act of swimming is alien and awkward. I'm coming up on the end of my first year of formally being a manager, and considering how absolutely fucked up the year has been, reflecting on it might be therapeutic.
When meeting new people, catching up, or even when I'm dating, one of the first questions that a person will ask is "what do you do for work?" Upon which I answer, "I'm an Engineering Manager". This means absolutely nothing to most people, so the quick follow up is usually "what does an Engineering Manager do?". This question has always sort of haunted me because I never really know how to describe my role – what does and manager do?
My first year didn't really go as I had planned and I had to deal with a number of unforeseen challenges re-COVID19. I had expected for it to be a fairly smooth ride – and maybe that was naive of me – but when I was promoted in February of 2020, I thought that my path was going to be the typical one that my own managers could hold my hand down. Going fully remote, company-wide layoffs, and a global pandemic put a huge strain on me, my team, and everyone at Ada. It was a fucking tough year and it forced me to figure out what my job actually is, quickly.
Your Mission as a Manager
The managers one and only job is to elicit the highest performance from their subordinates. Andy Grove, the late CEO of Intel and their third employee, described the managers role as such in his book High Output Management. Largely, I subscribe to this description. And although the sentiment may be off-putting, I believe that this description is up for interpretation. Eliciting high performance isn't about outputting as much work as possible by making people stay at the office late to crank out numbers, code, or whatever else your business does. It's about pacing yourself, hiring, planning, making customers happy, and building a great team. All of which allow your team/organization to output.
Learn To Let Go and Start Delegating
If you're anything like me, then you likely feel a profound sense of ownership over the things that you make. For me, one of those things includes the software I wrote at Ada when the product was in its infancy. A large portion of the code at Ada quite literally has my name on it, and with that comes the feeling of "I am solely responsible to maintain this". As an individual contributor, this is natural and i actually think its an important thing to feel, and although i don't know how to prove it, i imagine that this is a feeling that's much more prevalent with smaller teams working on software. There's pros and cons to this self-induced ownership; a pro perhaps being the fact that you actually give a shit about your work and build the best product that you can.
On the other side, are the downsides to the feeling of ownership of a growing product – you can't own it all yourself and you need to let go of it. You're a manager now and you have other things to focus on; better ways to spend your time and to support your team. That's easier said than done though. This is one of the more challenging things that you will face when transitioning from an IC to a manager. Delegating problems to your team sounds easy, but turns out to be surprisingly difficult in practice when you've been the person "getting it done" for so long. The place that your thinking will trend towards is; taking on this work is how you associate yourself with being productive and if you delegate it, are you contributing? Are you being productive if you're not delivering value yourself? The answer is yes.
You hire problem solvers to solve problems, and they want to; let them do their jobs
If you're not letting go of your old responsibilities then you're not doing your job as a manager. Your direct reports will resent you for not entrusting them with the responsibilities of doing it on their own, and will feel unsupported by you in their own careers if you're not giving them hard problems to solve. You can't do their job for them. One of the most influential pieces of management advice I've ever received came from David Hariri, one of the co-founders at Ada, "You hire problem solvers to solve problems, and they want to; let them do their jobs". Framing it this way helped me to realize that delegating the jobs and responsibilities that I held as an IC was integral to my success as a manager and for the success of my reports. As their fearless leader, you should be using your delegation power to have your team work effectively and to be solving the right problems in highest impact way.
Build and Maintain Your Teams Healthy Culture
Culture is one of those things that's vague and opaque; it's very hard to identify/describe. As a manager, facilitating, building, and maintaining a positive and healthy culture is not just your responsibility, but also one of the most effective tools in your management toolbelt. Doing this right under normal conditions is already hard enough, but slap on a global pandemic, transition an entire team to working remotely, and toss in a layoff of roughly ~25% of your organization – keeping your culture/rebuilding it becomes extremely difficult.
BT culture is inspiring. I'd like to emulate it on my own team – teach me your magic ways
At Ada, my team is sort of notorious for our culture. I frequently receive messages like "Builder Tools culture is inspiring. I'd like to emulate it on my own team – teach me your magic ways". I would describe our team culture as the following, in no particular order:
- Caring about each other, our product, and our users
- Supportive of our team's own members and our adjacent peers
- Autonomous, but very collaborative with our work
- Focused on solving hard problems the right way
I feel like I could write a whole book on culture; what it is, different types of culture that I've seen, and manifesting the culture that you want. Rather than diving too deep into my theories and ideas on culture, I'll instead elaborate further on some of the things that I do on my own team that I believe contributes to our culture, and that you could emulate on your own team.
Since transitioning to remote work back in late March, my team found it difficult to feel connected. Collisions, a topic discussed in Ed Glaesers Triumph of the City describes the ad-hoc exchanging of ideas through random encounters, were at an all-time low. Slack, email, or whatever your team uses to communicate, is in my opinion a very poor method of recreating this, and organized meetings to discuss a particular topic are great to solve a specific problem, but not conducive to free flowing discussion and forming new and novel ideas. To combat this, we instituted a recurring meeting now known as FaceTime where there is no agenda and the team is free to talk about or do whatever they would like. We typically talk about stuff that's happening at Ada, something interesting we've learned, or just share memes with each other. The end goal is not to just be goofing off, but to spend some time together and simulate a lunchroom or water-cooler conversation remotely.
Why is this important? Because there's more to teams and communication than working in the cubicles that are our home and only interacting with our co-workers when they need something from us. You work more effectively, communicate efficiently, and solve problems more elegantly when you actually feel connected to your team. In this new world where remote work is the norm for our industry, it's integral that you make an effort to create time in your teams day for the explicit purpose of having no purpose.
Ownership of Work
Making IC's take ownership of their work is a management strategy that I feel strongly about. On software teams I find it to be very effective, but I really don't know how well it works in other fields. Basically, the goal is to encourage and facilitate people to feel the same way about the things that they build as you or I would. When done correctly, the people that you manage end up requiring very little oversight. A few check-ins here and there and some occasionally feedback on their work will do the trick, but – and here's the hard part – you need to take a step back and let them figure it out.
There was a team that I observed at Ada (the team no longer exists but the people do) that had trouble delivering any new functionality to our product. The team consisted of some of Ada's most talented engineers (one of whom now works at Microsoft) but despite all that they had going for them, they still could only make small improvements and bug fixes. Why was this? Well, what happened was that they came down with a case of, what I call Scoping Paralysis. This is a condition that affects teams at fast moving organizations where they prematurely add way too much process to scoping out a solution. I've observed it manifest as two ways:
- The team can't land on a solution to a problem because they don't know which of them is the right/best one.
- The team understands at a high level the solution that they want to go with, but end up in a perpetual state of breaking it down into smaller and smaller tickets, finding a theoretical roadblock, taking a step back, and re-breaking the problem down.
All of this can be solved by just letting your team own the problems; just a little bit of coaching, a well understood problem and a list of requirements goes a long way. Instead of having your team break down epics into minuscule tickets via a process designed to optimize tracking productivity, give them a problem to solve. Humans are natural problem solvers – we love puzzles, and demonstrating trust in your subordinates' abilities to solve them is incredibly effective.
An Actual Balance of Work and Life
I really hate to harp on this but you need to actively encourage your team to not work when they shouldn't be expected to, and to take time away from their day-to-day to recharge. It is absurd how often I hear people complain about a lack of work/life balance at their current role, or even worse, have been lied to about there being a work life balance at a company. It's really easy for a recruiter or an interviewer to say that there is a balance when in reality there isn't, so it's your job so create an environment where it's safe to take time off of work by praising people for taking time off as well as setting an example yourself. It's much more efficient to have your people work at 100%, 32 hours a week (Mon-Thu) and stay at the company for 5 years than to be working at 70%, 40 hours/week and leave after 2 years. Rested, energetic, and enthusiastic employees make much better problem solvers than burnt out, tired, disgruntled ones, and this will be reflected in the quality of their work, and the team as a whole, which you yourself are evaluated.
The Years to Come
Honestly, I didn't really mean to write this much and i'm not sure what happened. I feel like I started writing this with the intention of it being more of a short blog post and then blacked out, then it ended up being closer to a manuscript. In any case, 2020 was a big year with a million distractions; it's amazing that anyone got anything done. As we all enter the new year, work is going to look different than how it started in 2020, and will remain different as well as continue to change from how it is now. As either a leader of a team or a member of one, I hope that reading this encourages you to collaborate or manage with a focus on empathy. I'm not sure what new challenges 2021 will bring to our working lives but after reflecting on this year I feel confident in our abilities to adapt – and it can't be any worse than 2020, right?