A few months ago I accepted a new role at Lessonly: splitting my time between building software and managing 5 of my colleagues. It’s been one of the most challenging experiences of my career so far, but at times pretty rewarding. At some point in your career as a developer, you’re likely to be given the same choice, so I want to share what it was like for me in the first few months before the curse of knowledge sets in.
Why did I choose to become a manager?
- The impact I have on the people around me will last longer than the impact I have on the technology, as my colleague Ross wrote movingly about here.
- My team was growing quickly, with all the growing pains that entailed. I liked the folks I work with more than I liked building software 100% of the time, so I wanted to help make things better for them (and myself) on the team.
What Do Managers Do?
In a discussion group I started for others interested in management, we began by reflecting on the managers—good and bad—that we’ve had in our careers. Something that became clear from the start is that many managers have very different ideas about what their job is. Micro-managers, for example, think they are responsible for every detail of the work their direct reports do. Absentee managers think their job is to respond to requests from their direct reports but otherwise ignore them. We all agreed that the best managers do two things: they take a personal interest in the growth and development of the people they manage, and they provide frequent, specific feedback about what their reports should keep doing well and what they should work to improve.
If you’re new to management, or ideally before you consider a role in management, you should ask your boss what impact she’ll expect you to have. (Even if you’re not going into management, it’s a fun conversation to ask you manager what they think their job is!) Most managers have some formal responsibilities like performance reviews and approving time-off requests, but don’t make the mistake of thinking that’s all there is to it. Ask how you’ll be measured: will you have hiring and retention quotas? Will you be responsible for the performance of the people you manage, and if so, how will they be measured? A budget to manage? Regardless of how much direction your boss can give you, have frank conversations with those you manage as well to find out what they want or need from you.
If you’re lucky, from these conversations you’ll end up with a clear idea of where to start as a manager. But as you advance in your career, you’ll increasingly be expected to figure out what you should be working on. For me, this was a little uncomfortable. As a software developer, I was used to being given (or asking for) clear direction on what I was to build and why. As a manager, it’s as much my job to discover what needs to be done as it is to actually do it.
The lack of explicit direction all the time is one of the challenges of moving from individual contributor to manager, but there are many others.
The hardest one for me was prioritizing what to work on. As a manager, you suddenly have a lot of important-but-not-urgent responsibilities like monitoring your team’s performance and long-term planning. But there’s also no shortage of urgent work, such as helping your team and reviewing code. If you respond to every urgent request immediately, you may never have time for the important, longer-term stuff. I find it helpful to schedule time on my calendar for that to ensure I get to it.
Another adjustment is becoming aware of the example you’re setting. Culture arises from the behavior of everyone on the team, but especialy folks in leadership positions. As a manager, if you respond to email while on vacation or interrupt people’s work to ask them questions, be aware you’re communicating to your team that behavior is okay and even expected. Of course, you can also use this to your advantage. By not working while on vacation, you’re telling your team that they’re expected to unplug and enjoy their time off, and you’ll have a happier, more productive team as a result.
Something else to navigate as a manager is confidentiality, as you’ll likely have more private conversations than before. In a 1:1 for example, someone may open up about a difficult conversation with a colleague, and the next time you talk to that colleague, you’ll have to not let on what you know, in order to respect their privacy. Or your own manager may ask your thoughts on promoting someone, and if you see that person feeling down, you may want to tell them they’re being considered for a promotion, but of course you don’t know that. Particularly if you value transparency, it can feel a little inauthentic to suddenly have secrets to keep, but that’s what it means to be trustworthy. That said, be clear on your ethical obligations. No one can ever ask you to lie, and if someone confides in you information that could hurt others, you have to let them know your plans if you feel obligated to share it. Thankfully, I’ve not been put in situations like this, and hope I never am.
As a manager, you have to get comfortable telling people how they can do better. It can be awkward, especially if you haven’t built a strong relationship with the person, but I’d be doing someone a disservice if I see somehow they can improve and keep that to myself. The best way to make this easier on everyone is to practice by telling people when they do well. Then, when you need to tell someone how they can improve, it doesn’t seem like you’re only focused on their flaws. I’ve learned that all feedback, both praise and criticism, must be specific (“Great job!” is bullshit.) Tell someone what they did, what effect it had, and why that effect helped or hindered the team. For example:
I noticed in the last pull request you reviewed for so-and-so that you did some memory profiling and discovered a bottleneck. That’s awesome! Your attention to detail helped improve their code, and with the memory issues we sometimes have in production, it’ll make the app more stable as well. Thanks!
And when being critical, in addition to being specific about what happened, be clear about your expectations, and ask for confirmation. For example:
I wanted to check in about the feature you’re working on. You said it would be deployed it last week and it wasn’t, and now Marketing is scrambling to adjust their communication plan. It’s okay when things get delayed, but I need you to tell me in advance so I can communicate that to other teams, so their work isn’t negatively impacted. Will you do that?
Also, focus on facts, not feelings, since you’re more likely to agree on facts. “I didn’t like how you handled [some situation],” doesn’t tell the person why they mishandled it or how they could have done better. My team is responsible for doing great work, not for making me happy all the time, so I try to avoid suggesting otherwise and leave my feelings out of it.
If this sounds like a lot of advice, it’s not because I think I’ve got management figured out. Since taking on some management responsibilities has been such a challenge, I’m grateful for anything I think I’ve learned that’s made it easier. Still, I’m sure I’ll look back on what an incomplete picture this is before long, and any wisdom that does hold up to time is likely something I cribbed from one of the following sources.
Further Reading and Listening
- Should I become an Engineering Manager? - A useful perspective if you’re asking the this question.
- Simple Leadership (podcast) - Interviews with engineering managers about what the heck they think they’re doing. Insights from these helped me define what kind of manager I aspire to be.
- Radical Candor (book and podcast) - a superbly practical resource on the mechanics of management, particularly on software teams.