My stint as a manager

Over the last few months, during my short foray into management, one of the most common questions I got during 1:1s was, “Why did you decide to become a manager?”
I have since realized that many more people silently harbor this question, and so I thought I’d do my share of public service by going into why I made the change and what I learned from it.

As an engineer, I’ve had rocky relationships with enough managers that it got me thinking about that quote about dating, “If all your relationships have been disasters, the only common denominator is you”. I knew I was the one that had to change. I was the one missing perspective, and what better way to get perspective than stepping into their shoes? Best case, I’d be able to be a model for management done well. “Worst” case, it would help me become a better “senior” engineer.

For context, I managed two teams (not simultaneously) for a little more than a quarter each. I understand this is very brief in terms of experience, and so this entire post should be read with that piece of data in mind.

What I learned from the switch

• It’s not an easy job. In some ways, it took more time than an engineering role.
• Managers have way too many things on their plate. This explains one of my pet peeves as an IC - 1:1s getting repeatedly pushed out. I really hated pushing these out as a manager, but consider this scenario: you’re in a meeting with higher-ups and the section you’re responsible for falls in the portion of the meeting that’s running over. What would you do? I did the thing that was the easiest for me: bump the 1:1, sometimes unfortunately by an “undefined time”. I empathize with engineers having to hold off on work due to uncertainty over when the 1:1 was happening - if it even was. It may seem like a minor inconvenience, but to me it seems like an unnecessary one. In hindsight, it was a weak act from a new SDM (me) and if I got to do it again, I’d leave more meetings at the time they were scheduled to end. This reflection is partly motivated by my philosophy that…
• A manager’s #1 focus should be their reports. In my opinion, a manager should have only 2 “foci” - their reports and the business, and of the two, a manager should prioritize ensuring their reports are performing at their potential. I frequently lean on sports for analogies, and to me a manager would be like a coach: You are responsible for getting the team in the best shape possible, by actively coaching them when needed to the levels that they need in the areas that they need. This is not an easy nut to crack since, along with every individual being at different capabilities, each individual likely has their preferred style of working and receiving feedback, and their own preferences regarding growth. This isn’t extremely obvious as an IC, but as a manager there is no getting away from it. Some of the “best” managers I had aligned with me on my styles and what I thought was important. But that’s not to say they worked well with everyone, and similarly, not every manager that didn’t gel with me was a bad manager (many were really appreciated by teammates). They’re able to balance their reports’ preferences with the needs of the business, ideally leading to growth for both. Ideally, I’d have been a stronger manager in terms of understanding the (new) space, and being a more proactive coach (think more “Pep Guardiola” and less “Arsene Wenger”) for my team.
• Managers ideally should be technically extremely capable to evaluate reports well. A manager really needs to be able to correctly assess the complexity not only of the task assigned, but also of any roadblocks encountered. This leads to the oft-stated logical conclusion that a tenured senior engineer on the team makes a good manager for the team. A change in any of those descriptors makes for a less effective manager. For example, a manager from outside the team would take longer to understand the space the team’s working in. One possible thing to watch out for: a senior engineer may not easily be able to accurately assess performance of new engineers. I frequently had to remind myself of the bumbling engineer I was when starting out in the industry.
• Bias: As a manager, any biases that you or others have quickly come to the forefront. I’m not talking about bias in a malicious way here, but just acknowledging that it exists, and a good manager would actively push to dislodge these biases. I’d notice on occasion I’d have more regular 1:1s with people “like me”. And then I noticed the same the other way around too - people not “like me” weren’t scheduling as many 1:1s with me. Maybe I have a bias assessing this too, and it is just that people found 1:1s useless (I hope not).

What I liked

• More autonomy. In general the industry seems to be moving away from more autonomy for senior engineers, so I enjoyed the additional autonomy that came with the change.
• Managers get way more visibility. I found the work I was doing as a senior engineer was underrepresented, undersupported and undervalued. As a manager, you’re literally in the room where the decisions are being made, and more importantly, in the room with the people making the decisions. I felt I had much more of a chance to surface the work I was doing, and got much more of a chance to make sure engineering work on the team was highlighted. Note: this is one of those things that greatly varies from company to company, so this may not always apply.
• Ability to help others. Both with immediate work-related problems and longer, strategic career-related discussions. From a former manager I learned how important it can be to escalate immediately and unblock your reports ASAP, and I tried to carry this forward. What I didn’t expect is the strategic career-related guidance you could provide as an SDM. To this end, 1:1s served as a useful regular point for connecting with engineers on the team. One concrete example of this is sharing what 1:1s are for. When I entered the industry, I had no idea what 1:1s were for. There was no guidance around this and all I knew of it was that it was a meeting you had with your manager weekly. These frequently ended up as status updates, which, given I was giving updates in stand-ups anyways, irked me to no end. I’ve since found guidance that I’ve applied and also shared with my reports: Julia Evans’ blogpost, Julia Evans’ zine and The art of awkward 1:1s by Mark Rabkin. These should be mandatory reading for any entry-level engineer in my opinion. Here I have to acknowledge a former manager who told me that the meeting was for my career, and not for status updates, which shapes my current understanding of the meeting’s purpose.
• Getting to advocate for ICs. Nothing feels better than being able to do right by someone who’s been doing great work. Nothing feels worse to me than failing at that.
• There’s a lot of breadth to the role. Suddenly, I had to have a pretty solid idea of what every engineer was working on. As a senior engineer, if I needed to focus on a few urgent deliverables, I could ignore a couple of workstreams with no impact. That luxury disappears as a manager. It’s one of the “new” skills that will help me be a stronger senior engineer in my opinion.

What I would change

Read the following as what I would do if I was CEO

• Earlier I said, “managers have way too many things on their plate”. Not all of these things are warranted. There’s a lot of opportunity for streamlining these things, but that has to come from higher up at times. Some of these are from a bygone time, when the organization or the company was dealing with different constraints. Despite times having changed, many processes have ossified and remain resistant to change, even when they don’t add the benefits they used to. Some of these processes need to be changed at a very high level (CEO-level), which means it likely will always remain just “a wish” for a lowly IC.
• It would be nice if managers had more of a say in finances, including compensation. Maybe allocate a budget for the team, and let the SDM manage it like a mini-business. I admit it is not easy to do (think about how you’d deal with a team that isn’t directly making revenue), but it might be interesting to try. Without this, a manager can evaluate the performance of their reports, but how the feedback is received may vary if compensation and other mechanisms don’t align.
• I’d have management be a part-time role, with the remaining time spent on hands-on engineering work. I know this is implemented in the industry at smaller companies. It seems to me that this should work at lower levels in large companies, since the head-count of the organization probably matches that of a smaller company anyway. Without regular involvement on the technical side, I’d fear my skills at evaluation, feedback and growth of employees would suffer.

What I’d tell myself as an engineer

• Communicate often with your manager on deliverables. In my ideal world, if you give a date, work towards delivering the task by that date no matter what. If you need to put in extra time, put in extra time and take it off later. This was how the industry was a few years ago. Managers and ICs had this unspoken understanding that the work would get done, and requisite time off could be taken. I can understand the move away from that and more to a work-life balance “only 8 hours per day” model as of late, it seems anything delivered by putting in extra time seems to set that as the norm for delivery speed, despite it being unsustainable.
• Find a manager that wants you to grow as much as you do. Make sure you advocate for yourself, but make sure you are putting in the work first. Move if needed.
• If you want to get promoted, move to a team with fewer rockstars. If you want to be the “best” engineer you can be, stay on a team with rockstars (understand that this may not lead to easy promotions, etc.). What defines a rockstar? They’re hardworking, committed (around for the long term), smart (able to reason about new problems) and knowledgeable (aware of existing issues & solutions). The tech world is woefully lacking in resources for intermediate+ engineers (partly because it tends to get hyper-specialized beyond a point), but working with rockstars will let you learn while providing a guidepost for where you could be at.
• Hold regular 1:1s with your teammates (especially entry-level/new teammates) and share what you have learned. Give them guidance on what you’ve learned and what has allowed you to be successful.

Should you switch?

If you like engineering and building, I think at some point you would yearn for the hands-on gratification that programming provides. As a former manager said, “You should only take the role if you’re passionate about helping others grow”.
Note: There are cases where promotions up the management chain make a strong case for switching. This was not a motivator for me, but is a reason for many to make the switch.

If you found this useful, please drop me a note! If you want more of my thoughts, I’m open to meeting over coffee!