My First 100 Days as an Engineering Manager — in a Pandemic
In May 2020, I took a sharp right turn in my career: I transitioned from being a lead software engineer to an engineering manager with three wonderful and talented direct reports. Ordinarily, that career trajectory change might have been relatively unremarkable; engineers make this leap all the time. But there’s a pandemic going on, and to say that it’s been tough would be an understatement. There have been tears. There have been times when I’ve wanted to chuck my laptop out the window. And there have also been awesome, rewarding moments that have reminded me that if I could go back in time and make the choice again, I’d still go down the same path. But I’ve often joked that I tend to play life on hard mode, and this has certainly been an example of that.
My job change was both sudden and not: the timing was a surprise, but I probably would have ended up here someday no matter what. However, the pandemic has had a major impact on my understanding of the role, and it’s strange to think that I’ve only ever been a manager during a pandemic. I believe this lends me a unique perspective, which is why I wanted to share my experiences, especially if I can help anyone else currently going through this transition or beginning the move soon.
And part of the point of this article is simply catharsis. I’ve always processed what’s happened to me the best by writing about it, and the ~100-day mark (coinciding with Intersession at NPR, the perfect opportunity for me to take a break from project work for 3 days to write this) seemed like an ideal moment to pause and reflect on the past few months and what I’ve learned.
So, strap in and let’s go on a journey together!
The Road to Management
Before I begin to summarize my experiences since becoming a manager, I wanted to spend a little more time describing the events and circumstances leading up to my role change, because context is everything; even if you went through the same transition at the same time, many of your experiences are likely different. My subsequent thoughts, struggles, and learnings are a product of my background, values, the organizational context I work within, the people I work closely with, and how the pandemic has affected me personally on top of professionally.
By way of background, here is a brief timeline of some of the most significant milestones leading up to my role change:
- March 24, 2014: I started at NPR as a software engineer
- September 2017: I became a founding member of and the senior developer on the newly-created Voice & Emerging Platforms team
- October 2018: We decided to create a second voice-focused scrum team
- May 2019: The second Voice Platforms team was finally in place, and I began transitioning my role from senior developer to tech lead
- September 16, 2019: I was officially promoted to lead software engineer
- January 29, 2020: I was asked by our VP of Technology whether I would be interested in becoming the manager for Voice & Emerging Platforms
- February 28, 2020: My reports’ previous manager left, and I took over as interim/unofficial engineering manager
- May 11, 2020: My role officially changed to engineering manager
When I started at NPR in March of 2014, Digital Media (our department)’s tech team had two managers, one for all software engineers and one for the small handful of sysadmins, though a second developer manager vacancy was filled later that year. By that time, we had ~25 individual contributors on the team, a mix of software engineers, mobile engineers, QA analysts, support analysts, and sysadmins/DevOps engineers. Both developer managers had roughly 10–12 engineers reporting to them. We did only incremental hiring over the next couple of years, until an internal departmental merger in the spring of 2017 led to several new engineers moving into the team, leading to the decision to create two more developer manager roles, the last of which was finally filled in May 2018 (with another external hire — up until then we’d never had someone promoted into management internally). Despite some reshuffling of who reported to who, by that point, we had grown to nearly 50 engineers, and the original manager who had hired me had become a Senior Director with only the other managers reporting directly to him, which meant we once again had anywhere from 10–14 ICs reporting to each manager. Throughout, there were always questions about how technical these managers were expected to be, but it was generally acknowledged that with so many direct reports, it didn’t leave them with enough bandwidth for much more than participation in high-level technical discussions.
At the same time, we always had anywhere from 6 to 12 scrum teams focused on a specific project or product. In other words, our management structure was entirely divorced from our team assignments. This was generally considered to be a good thing at the time, because many of these project teams were intentionally short-lived, and during my first couple of years at NPR in particular, it was not unusual for someone to change teams every 9 months or so on average. Because of our reporting structure, that meant folks could change teams without needing to change managers, and thus gave us maximum flexibility and made it easier to circulate knowledge and prevent silos. For the longest time, most folks seemed happy with this setup.
But as the tech team grew, the reporting structure made less and less sense, especially as our scrum teams had become more static over time, and our projects grew more complex and began to require a lot more cross-team coordination. The final straw came in the fall of 2019, when one manager suddenly left and another was about to embark on a 3-month sabbatical — leaving our team of ~50 ICs with only two managers for at least the next several months. It was clear that something needed to change both to address the immediate problem now and to prevent us from spreading ourselves too thin like this again in the future.
Now, I’ll put a pin in that for a bit and circle back to my own personal journey, because it’ll help explain why and how I became a manager. First, it’s important to know that I had already been expecting to go into management eventually — but I thought it was still 5–10 years off. That was a conscious decision, not an assumption about my age or tenure; I knew it was possible to go into management at this stage of my career, but I didn’t think it was the right time for me personally. I was still enjoying my role as an individual contributor, and I’d also observed other managers over the years who had struggled with the transition, often because they were moving into management and starting a family at the same time. Given the stage where I was at in my personal life, I decided I’d rather stay an individual contributor until after I got married and had children, deferring the challenging transition into management until after I’d settled into parenthood.
But I knew that all roads would ultimately lead to management for me, because I knew it aligned with my values. I believe that humans are simultaneously the best and hardest part of software development — not code. And while I recognize that it’s possible to be a very empathetic and human-oriented lead IC, somewhere along the way, I realized that I’m more likely to be able to make the kinds of meaningful changes to make life better for the humans building our software as a manager. I’ve always been instinctively drawn to process improvements so that we don’t just solve a problem once, we prevent it from ever happening again in the future. And in many ways, a manager’s job is to continuously advocate for process changes in order to improve the lives of your team.
One memory that stands out dates back to October 2017, when I attended (and spoke at) the Grace Hopper Celebration for Women in Computing for the first time. I attended a session titled “Technical to Manager: Making the Leap or Not”, which was a panel discussion featuring a diversity of experiences: a woman who had deliberately gone into management, a woman who had deliberately stayed an IC, a woman who had gone into management and hated it and went back to being an IC, and a woman who had managed to carve out a fairly unique role where she got to do equal parts of both. At one point, the woman who had deliberately gone into management made a comment that you’ll likely know management is right for you if you find yourself (perhaps subconsciously!) trading your books and blog posts and podcasts about technology for books and blog posts and podcasts about psychology and sociology. I realized already back then that that was me; while I was still doing both, I was getting more value out of reading articles from the Harvard Business Review than I was reading technical blogs.
I still thought the move into management was many years away for me, but I ended up taking (unknowingly at the time) tentative steps toward this journey beginning in October 2018, when, as I alluded to in the timeline above, we decided to create a second voice-focused scrum team. Up until then, the engineering portion of our team had consisted of three developers, of whom I was the most senior. My manager at the time encouraged me to leverage this opportunity to move into a lead software engineer role, because our engineering ladder centered on one of the key requirements for a lead being to lead projects across multiple teams — and the addition of the second Voice team would certainly give me ample opportunity to do that.
The new scrum team was in place by May 2019, and I was incredibly proud of the combined unit we built, captured a few months later in this photo (a bit outdated now, as a couple of folks have since moved on to other teams):
With all of the open positions filled, and the second team starting up, the remaining task for me was to figure out what it actually meant to be a tech lead. We’d never had more than 2 or 3 lead software engineers at a time, and a formal career ladder had only recently been introduced, with the lead level by far still the most ambiguous. Essentially: the position clearly existed, but there was a lot of leeway to define your own role. I realized quickly that not everything the other leads were doing applied to my team; context matters. We needed more leadership in some areas and less in others, and it was largely up to me to identify how a tech lead would best serve my team.
If I had to pinpoint a single moment when my current journey began, I would say: the end of June 2019, when I was working remotely from an Airbnb in Singapore for a week. Because it wasn’t feasible for me to fully work U.S. East Coast hours, I only overlapped with my team for part of the day, and so I enjoyed long stretches of uninterrupted heads-down and reflection time for the first time in a while. As I was mentally puzzling through the “what even is a tech lead?” quandary, I realized it might be helpful to just start jotting down my thoughts, stream-of-consciousness style. For lack of Post-it notes, I decided to use a Trello board, which ended up being a great choice both because it made it easier for me to share the results with my team later, but also because I soon discovered that the things I was writing fell into 3 different categories: Guiding Principles, Ongoing Responsibilities, and TODO. The first was really a list of values, the second a list of tangible ways in which I could see myself bringing value to the team on an ongoing basis, and the third a list of near-term initiatives and tasks I felt I should take on. I hadn’t immediately set out to frame my thoughts that way, but it ended up being a tremendously helpful activity, and the list of values in particular still guides me today.
When I returned from Singapore, I shared my thoughts with the team, and with their assent, I began to change my role. Notably, I stepped back from being the primary coder on our main projects because I had realized that while I could get the work done the fastest, I was robbing the rest of my team of valuable learning opportunities, and the latter was much more important in the long term. I instead began to focus more on those small ad hoc tickets that would periodically come in so that the other developers could avoid context-switching away from the primary sprint goal. I also spent more time on process improvements and figuring out how to better collaborate with both product owners. I created new standing meetings with them so we could discuss upcoming sprint goals as well as the status of conversations with our third-party partners. I even invited myself to more of those partner calls. While my life started to feel more and more like it just consisted of meetings, they were time well spent, and I felt confident that this transition allowed me to bring even more value to my team than I had as ‘just’ a really good coder.
Long story short, by September 2019, I had grown comfortable in my new role, and the title bump largely felt like a formality. I was excited to continue to work with my wonderful team in the new capacity, and I was also looking forward to closing the chapter that was 2019, which had mostly been focused on this career transition, and beginning a new one, where I planned to focus on other aspects of my life. When we rang in the new year, I was greeted with a lot of: “Cheers, 2020 is going to be your year!” because… I was getting married. My Korean-American partner and I were to embark on a 3-country wedding tour from the U.S. to The Netherlands (my home country) to South Korea in March/April 2020, followed by a 3-week honeymoon in Australia.
… You can probably guess where this is going.
But first, let’s flash back to January 29, 2020, the day our VP of Technology told me about her plan to rearrange our org structure so that now there would be an engineering manager embedded in every scrum team, with every developer on that team reporting to this manager, and asked me if I’d be interested in taking on that role for Voice & Emerging Platforms. I remember the exact date because one of our engineers who works remotely full-time was in town, and we’d arranged to go on a team karaoke outing after work. Perhaps it was the emotional impact of belting my heart out to Linkin Park and Alanis, but it wasn’t until then that it really hit me. I’d told our VP “yes” because it seemed like a no-brainer at the time; it was billed largely as the same job I was already doing, plus a few other responsibilities like timecards and 1:1s and performance reviews. It was only at karaoke that the potential impact of the decision hit me — could this be the last time I’d be able to go out with my team like this? After all, was it appropriate for a boss to have drinks with her reports? I surveyed the beautiful faces around the dimly-lit room and quietly sobbed into my Asahi tallboy as I queued up “Mr. Brightside.”
I wavered a bit, but in the end, I stuck with my original decision, for a host of reasons, but in large part because the alternative presented wouldn’t make much sense: we’d need to hire someone externally who essentially had all of my current skills and who either had management experience or was interested in moving into that role. When I knew I was almost inevitably going to end up in management anyway, it just didn’t make sense to turn down the opportunity. Sure, it was not at all when I’d expected to make this transition, but it was fine. My original plan of not going into management and starting a family at the same time would still hold true — I’d just be doing them in the opposite order I’d expected to do them in.
I thought the transition into management would be the only surprise life had in store for me, but 2020 was just getting started. Next, the timeline was suddenly moved up. The original plan had been for the new roles to take effect sometime between mid-April and mid-May in order to give us adequate time to get training. But then one of the original developer managers left to pursue another opportunity, and she happened to be the person my future direct reports were reporting to at the time. So, I needed to step in in an interim manager role after her last day on February 28.
Much of the interim period is a blur because I soon needed to make several difficult life decisions as the reality of the pandemic hit the U.S.: first, the cancellation of our wedding reception in Korea, and then, the day after we went into lockdown, the decision to postpone our entire wedding tour and honeymoon. When the D.C. Courthouse closed indefinitely just 5 days before we were supposed to have our civil ceremony there, I was inconsolable. My reports spent all of their energy trying to cheer me up when I should’ve been the one helping them adjust to indefinite work from home and the psychological pressures of an unstable world.
Somehow, we still managed to get married on March 23, our desired date. It was more like an elopement, with no guests able to be present, but it was a small victory in an otherwise bleak time.
The promotion finally became official on May 11. All told, 11 of us who were previously ICs became engineering managers, the one remaining lead software engineer became the organization’s first principal software engineer, and two of the previous developer managers plus one interim manager became Directors of Technology reporting to the VP. Each of the three directors has 3–4 engineering managers reporting to them. The move to this new structure will henceforth be referred to as “the reorg.”
There was every intention to make the reorg official much sooner, but COVID–19 delayed the rollout for well over a month. It’s no secret that NPR is facing a host of financial challenges as a result of the pandemic, and one of the first measures taken to respond to these challenges was a freeze on all promotions and raises. We ended up needing permission from the highest levels of the organization’s leadership to still go ahead with the reorg, and even then, we could only do so if we agreed to step into our new roles without any kind of pay increase. (To be clear: everyone was asked to make their own individual decision — no one was pressured — and everyone agreed.) In fact, the week before our promotions became official, we found out everyone would need to choose between a pay cut or an unpaid furlough in order to help NPR weather the financial storm. And the ambitious training plan that was supposed to accompany the reorg also didn’t materialize.
With all of those obstacles and disincentives, why did we still go ahead with it? Because if anything, the pandemic reaffirmed our belief that everyone deserves access to a manager who has ample time to support them. Back when our managers had 10–14 direct reports each, despite having the best intentions, it was always going to be challenging to support each individual as much as they needed it even in the best of times, say nothing of a crisis such as this one. In the new structure, no manager has more than 4 direct reports, so ICs don’t need to hesitate before reaching out for help — whether they need to adjust their work schedule around their kids’ virtual schooling, or assistance pushing back against product owners’ expectations in these changed times, or accommodations for mental health needs. We all felt the pandemic made the reorg more important, not less.
By the time my first 100 days as officially a manager kicked off, the 2020 that everyone had told me was “going to be my year” was already looking vastly different from anything I had ever expected.
As I was thinking through how to approach this next section, I realized that the most sensible way to frame my thinking is using the standard agile retrospective style — “what went well” and “what didn’t go well” — but first, I figured I’d go over what I found most surprising about the new role, because I think that will also help lend some helpful context for why I thought certain things went well and others didn’t.
What Surprised Me
Becoming your team’s manager really does seem to be the easiest way to make the transition.
If you’d asked me two years ago how I would’ve preferred to make the move into management — becoming my team’s manager or joining a new team (possibly at a new job) as a manager — I would’ve said the latter. That’s not because I’d read a management book or anything to suggest that that was the better path, it was purely based on a gut instinct that that was the better way to do it. Mostly, I guess I was worried that your peers will always struggle to accept you as their new boss, so it’d be preferable to start fresh with a new team, where from day 1 everyone’s roles are clear.
I couldn’t have been more wrong; it is so much better to become your peers’ manager. While there’s been some awkwardness, sure, in the end, I’ve found it so helpful to already know my team and what they care about; particularly in the context of the pandemic, it helped that I already knew from day 1 what their biggest needs were. And in the many moments when I felt insecure and questioned all of my own decisions, I felt buoyed by their trust in me. I knew they knew I would always go to bat for them. I would’ve never had that confidence had I become the manager of a group of strangers.
When you make the transition, you don’t immediately get to enter “the room where it happens.”
I didn’t go into management because I wanted “power”, but as the change came closer and closer to becoming a reality, I figured I could leverage the opportunity to ensure that we don’t make decisions that would adversely affect my team. To quote Aaron Burr in the musical Hamilton, I thought I’d find myself “in the room where it happens.” I was wrong.
It’s possible that this was a result of the nature of the road that took me into management — the reorg. Many times, the previous developer managers had been in the room where it happens, and that’s what I’d modeled my expectations on. But with the introduction of the new Director of Technology level, the decision was made that only the directors would attend most department leadership meetings, not the engineering managers. We were left in the hallway just outside the room where it happens.
When I first realized this, I was shocked, not in the least because it didn’t take long for a decision to be made in that room that adversely affected my team. Instead of having a presence and being able to defend our needs, my job was to communicate out this decision that I hadn’t helped make to my reports. I experienced a moment of, “Wow, if this is what the job is, this sucks.” It stung.
I wanted to offer this as a cautionary tale that becoming a manager doesn’t mean you immediately get to make all the decisions; you’ll be surprised how powerless the role often feels. There are days when it feels like I had more influence as a lead software engineer a year ago than I do now as a manager. I felt surprised (but also validated) to hear from several more experienced leaders recently that this is also what they experienced when they first became managers, so it seems like a fairly common phenomenon. But it’s interesting that I’d never heard anyone talk about this before.
The paradox is real: your to-do list is never-ending, yet no one really understands what it is you do all day.
A common theme in management books and blog posts is how often ICs admit that they just don’t understand what it is their managers do all day. Heck, I myself have been guilty of thinking it in the past. And the sentiment often contains a kernel of criticism: if I don’t know what it is that you’re working on, then are you really making the best use of your time? Why aren’t you spending more time on this other thing that I think is really important?
So that notion wasn’t a surprise to me. What was a surprise was discovering just how long the to-do list is, and that it really is all vitally important work. In any given week, I manage to complete maybe 60% of all the things I want or need to do (and have to try to make peace with everything I can’t get to — more on that later). Given that, it’s truly paradoxical that no one seems to know what you do all day. So much of a manager’s work is invisible.
I know this is a solvable problem, though, and I’m actively experimenting with different solutions. One thing I’ve been trying that works fairly well is that I send my reports a note (by email) at the end of every week giving them some visibility into things I’ve been working on outside of our scrum team and how those initiatives are going. In the past, I was using my 1:1s to give those kinds of updates, and while it worked, I’m trying to move away from that because I know I need to use those as more of an opportunity for coaching. Like I said, I’m still learning.
Moving from tangible contributions to ones that are much more difficult to measure is just as hard as everyone says it is.
Almost everything I’ve read from others who have made the transition from being an IC to being a manager has discussed this topic: that it used to be so much easier to tell if you’re doing a good job. After all, you could just look at how many commits you pushed, or how many tech designs you wrote, or how many JIRA tickets you managed to close this sprint. Your contributions felt tangible and measurable.
But the management aspect of the job is much harder to measure, and now that the bulk of my work no longer lives on a JIRA board, I struggle with having any sense of accomplishment. Even if I manage to translate most of what I’m working on into a to-do list, when can I actually mark something as “done”? How do I know I did enough to promote my reports’ happiness and wellbeing? How do I quantify their growth? Sure, I should be able to do so on a yearly or even quarterly basis, but what about week-to-week? How do I know I’ve done enough?
Again, I know there are approaches (if not outright solutions) to take here, and part of it is also accepting that navigating this ambiguity is the job. But while I’m still learning, I struggle a lot with having a sense of “enoughness.”
It’s not enough to allay a report’s fears once. You have to do it over and over.
This was probably the biggest surprise stemming specifically from the context of the pandemic. NPR’s cost-cutting measures that I described earlier are certainly unfortunate, but the upside is that they’ve all been done in the service of avoiding layoffs. Our CEO regularly reaffirms in our weekly all-staff meetings the organization’s commitment to doing everything it can to prevent the need for a workforce reduction. I’ve always taken him at his word, and I thought that would settle the issue for my reports as well.
That’s why it shocks me when, every few weeks or so, a report might say something like, “Well, when there are inevitably going to be layoffs…” even though no one in leadership has done or said anything to indicate that. I’m guessing this also has a lot to do with faith (or lack thereof) in institutions, especially by junior and marginalized staff, who have a history of not being able to trust the words of their leaders (in general, not at NPR specifically). But regardless, it has taught me the importance of reinforcement; if it’s important, you need to say it over and over, especially in a crisis. Because otherwise, folks might try to read something into the absence of your words — even if no such meaning was intended.
My approach now is to try to subtly pepper these reminders into nearly every communication I send to my team:
- Thank you for the sacrifice you’re all making with these furloughs and pay cuts in order to help the organization avert layoffs.
- By the way, did you tune into the All-Staff yesterday, where our CEO reaffirmed his commitment to avoiding staff reductions?
- The supervisors meeting yesterday included updates on the finance team’s successful approaches to preventing the need for layoffs.
- Isn’t it great that our organization’s leadership is still fully committed to averting layoffs?
I might start to sound like a broken record at some point, but I’d rather risk that than have one of my reports be unable to sleep at night because they’re worried about whether they’ll still have a job next month.
What Went Well
Focusing on my team’s wellbeing gave me a single, clear mission to focus on during the pandemic.
I tend to think that this is the biggest positive that came out of making this career move under these unique circumstances. Had I done this at any other time, I probably would’ve struggled to figure out which, among the many, many responsibilities I was now tasked with, was actually the most important thing for me to focus on. But the pandemic removed all doubt: it’s my team’s wellbeing, period. Nothing trumps that.
Am I still responsible for ensuring that our engineers continue to deliver against our roadmap? Sure. Do I still need to fight tooth and nail for time to pay down technical debt? Absolutely. But none of those things matter if my team is so burned out that they can’t do the work in the first place. And the threat of burnout under these circumstances is very, very real.
I realized that my transition into the tech lead role last summer gave me a head start compared to my peers.
The reason why I went into such great detail describing that Trello board activity that I did while working remotely from Singapore last summer is because I think that, more than anything, gave me a leg up as I began the new role. I had actually taken this experience for granted until late June, when all of the engineering managers met together without the directors for the first time, so that we could talk amongst ourselves about what we each found the most challenging. A common theme is that many of them needed to establish themselves as tech leads while also wrapping their heads around what it means to be a manager at the same time, because not everyone who was now a manager had been a lead software engineer before — a few were senior developers and a couple were even mid-level. They were often still the primary coders on their projects, they were not participating in higher-level strategy and roadmap meetings with their product owners, and they were not invited to sit in on important calls. None of those changes that I’d already made happened overnight — many of them took months. After that meeting, I was acutely aware of my privilege (and of course shared many of my tips and tricks and learnings), and I was grateful that I’d had at least one advantage even as I was struggling with so much else.
The takeaway here is that you don’t have to wait until you’re officially a manager or a tech lead to think through how you can most bring value to your team in a leadership capacity. Do something like I did — feel free to replicate my Trello board activity if you think that might be helpful. I’m sure there’s other ways of doing it as well. But it’s important to articulate the areas where you think your team most needs leadership, as well as starting to write out your own personal values (and hopefully you’ll start to see parallels between the two lists).
I sought out a mentor.
I never do anything halfway, and when I knew I was going to be a manager, I wanted to take it seriously and make sure I was setting myself up for success. I quickly realized that I needed a mentor. My previous manager, now one of the directors, did offer to mentor me, but I found that we would all-too-quickly end up in the weeds because he knew too much about the specific people and situations I was dealing with. While I appreciated his advice nonetheless, I realized I would benefit the most from an outside perspective.
By a stroke of pure luck, the NPR-wide mentorship program facilitated by the NPR Training Team was just starting up its new cohort in late May, with an open call for both mentees and mentors. I figured I had nothing to lose and decided to throw my hat in the ring as a mentee. There was a field on the application form where you could describe your ideal mentor, so I wrote something along the lines of: “a mentor with management experience, and ideally someone from outside Digital Media and someone who worked at NPR through the last financial crisis and knows a thing or two about managering in terrible times.” I thought I was asking for a unicorn and expected not to be paired up with anyone. Instead, they matched me up with Laura, a director in IT (a separate department but with obvious parallels), who has worked at NPR for the last 20 years.
Laura and I chat biweekly, and it’s been tremendously helpful. My hypothesis turned out to be true: there’s a lot of value in talking through my challenges with someone who doesn’t know the people or projects involved, though at the same time, it helps that she does know NPR and all of the complexities of the organizational context. Interestingly, I’ve often found our conversations to be like rubber-ducking: in the process of explaining the people and the projects and why I find a certain situation challenging to Laura, I already start to see the problem myself.
I scrappily found training opportunities, collected other expert advice, and created my own training program.
I am nothing if not resourceful, so I kept looking for training opportunities. In June, I was accepted into Poynter’s 6-week “Power Up: Leadership in Tough Times” training course, and over the summer, I applied for a scholarship for LeadDev Together. My application was accepted, and this month, five of my peers from the leadership team and I attended the first two sessions together. They have been incredibly informative and timely, and we’re grateful to have this invaluable resource available to us.
I also recognized that formal training programs aren’t the only way to learn from the experts. I read Julie Zhuo’s The Making of a Manager, Jill Geisler’s Work Happy: What Great Bosses Know, Lara Hogan’s Resilient Management, and all of Cate Huston’s blog posts on management; I made a reading list out of all of Cate’s book recommendations. I’ve purchased Camille Fournier’s The Manager’s Path and Alison Green’s Ask a Manager and have those queued up for the next couple of months. I was surprised by how much I enjoyed these books, as I don’t normally read anything but escapist fiction (or Wikipedia) in my spare time, but I found them insightful (especially in understanding what the role is) as well as validating, reinforcing that the things I’ve found hard, most new managers find hard.
I really wanted to find a way to encourage our entire new tech management team to teach and mentor each other, so I created a “Management Skills Seminar Series” (MSSS for short) that’s a bit like a book club in reverse. Essentially: everyone reads a different management book (or watches a talk, or listens to a podcast, or reads a series of shorter articles related to one subject or theme) and then shares a 20-minute presentation with the other leaders summarizing what they learned and what they thought applies most to our organization. As an example, I did my presentation on Julie Zhuo’s book, a colleague covered Lara Hogan’s, my manager did Will Larson’s An Elegant Puzzle, and another peer recently gave a great talk summarizing Simon Sinek’s Why Leaders Eat Last. I’ve found this homegrown training program to be a nice mix of informative and fun — it’s always great to hear what my peers are learning and what resonated most with them.
I was asked recently which of these methods of learning I’ve gained the most value from, and I would probably rank them in this order: (1) the mentorship program, (2) the Poynter and LeadDev Together courses, (3) MSSS, and (4) the books I’ve read. That’s not to say that I haven’t found the books helpful, because I have, and I believe the world would be a better place if everyone in a leadership role would pick up a management book every once in a while to expose themselves to new ideas or insights. But in the context of COVID–19, I’ve gotten more value out of settings that provide opportunities to discuss things with others, not just consume information one-way — because as talented and experienced as these book authors are, no one has managed in a pandemic before; this is everyone’s first time. While there is some preexisting wisdom on managing through a crisis, there are also things about our current circumstances that are unique to 2020, and that’s why I’ve gained the most from having real-time conversations with other managers. The mentorship program has given me the most mileage because it is inherently personalized, but the Poynter training was also valuable because they used Zoom’s breakout feature extensively to put attendees in discussion groups, and LeadDev Together and MSSS encourage conversation among my peer group at NPR.
Finally, I found it interesting that once I got myself in the mental mode of trying to find leadership advice everywhere, I truly was looking for leadership advice everywhere — even in nontraditional places. Much of my first watch of Becoming was spent dissecting what makes Michelle Obama a leader who inspires people. After watching The Last Dance, I couldn’t stop thinking about the instance when, in the early 90s, the Bulls coaching staff were trying to make MJ more of a leader and less of an individualistic player, and one of them said something along the lines of: “we needed to teach him that he could win without always needing to have his hands on the ball.” That resonated so much with the transition we were going through.
We were already well-equipped to go fully remote, so that in and of itself did not cause any new challenges.
I don’t want to dwell on this too much, but I did feel obligated to point out that overall, the switch to working fully remotely was not an issue for us. While we’re not a remote company — everyone is generally expected to work out of our headquarters in DC — we’ve always had a small handful of staff working remotely full-time from other parts of the country, so we have a remote-friendly culture, and there was already an expectation that any meeting needs to be accessible to remote attendees. In my team’s case, we had a team member who worked remotely from Boston, so we’d worked out many of the kinks related to remote participation. As such, it was a relief that we had at least one thing going for us during these challenging times.
Right around the time I began to transition into my new role, my entire team did a “personal user manual” exercise.
This is not quite the same thing as a “manager README”, which I’ve read a lot of arguments both in favor of and against (this is a good summary of both sides), and I’m inclined to agree with many of the arguments against. But earlier this year, one of our product owners attended a conference where one of the speakers recommended doing a “user manual of me” exercise with the entire team. The idea is that everyone writes a document following the same agreed-upon template; in our case, we have sections with these headings:
- My style
- What I value
- What I don’t have patience for
- How to best communicate with me
- How to help me
- What people misunderstand about me
- What energizes me
- What drains me
- My typical work hours
One nice thing, though, is that these are intended to be living documents that can evolve both with your own personal growth as well as with your team’s needs. As we’re in the middle of onboarding a remote intern for the fall, we recently decided to add these 3 additional sections:
- What has been most challenging for me during the pandemic
- What I’m looking forward to most post-pandemic
- Ask me about…
… with the expectation that we’ll delete those first two post-pandemic, but for now, they provide helpful context for a new person coming in.
The reason why I think this was a positive activity overall is because everyone on the team did it together, putting us closer to equal footing. Obviously my being a manager impacted what I wrote in a few of the sections, but overall, I tried to stay focused on who I am and what I care about as a human, not as my job. I learned quite a few things I didn’t know about my reports in the process of reading theirs, as I’m sure they learned new things about me.
Lastly, I realized that as I was writing my own, what I was really doing was writing a list of my values — but that just writing those out isn’t enough. I need to constantly ensure that my behavior reflects those values, and there are times when I admittedly fall short of that. Still, writing down your values is a good first step; it’s easier to hold yourself accountable when you’ve stated what they are. The follow-up task is to prove that you actually live them.
I invested in my own self-care.
Like so many, I initially thought that working from home would be no big deal. I’d always had one standard WFH day a week — Fridays — so I thought I knew what to expect. After the first couple of weeks of #QuarantineLife, I was shocked by how much I struggled to get through each week. By Friday, my brain would be jelly. I couldn’t manage more than logging on and being available to answer questions for my team.
I had a feeling that this was only going to get worse as time wore on, so I decided to be proactive: for the duration of mandatory WFH (or until I no longer got value out of it), I would work half-days on Wednesdays, giving myself a mental health break in the afternoons. Many other folks were taking half-days or full days off on Fridays, but I found that taking a break in the middle of the week paid dividends, because Thursdays are typically my most meeting-heavy days, and now I can actually attend all those conference calls feeling refreshed. My half-days on Wednesdays also ensure I can have a full day of productivity on Fridays — and with so many other folks taking Fridays off, it’s often one of my only opportunities to get heads-down time.
My doing this benefited my team: because I took this proactive step, they knew they too could take time off for mental health breaks. Initially, many of them chose a standard day like me, and over the summer, folks took more ad hoc breaks as they needed them. Yes, I could’ve just said, “You can take time off for mental health, you know,” but actions speak louder than words.
But it’s also important to recognize that investing in my own self-care in and of itself benefits my team. I am able to support my reports and their work better when I myself am rested and healthy. Taking time off is not selfish.
Going through all this in quarantine improved my relationship with my husband.
I’m mostly trying to stay focused on my professional experiences in this article, but I wanted to bring this up because it was so unexpected.
As I mentioned earlier, I’d always had one standard WFH day a week, on Fridays. My husband has been undergoing a career transition for a while now that has largely kept him at home, so he’d typically be around on those WFH Fridays. Now, I’d always arranged my schedule such that I’d have minimal, if any, meetings on Fridays, and maximum heads-down time, and so I’d be able to do things like have LoL esports playing on the TV while I worked. Because of things like that, and because those WFH Fridays were generally chill and stress-free, I think he’d always had the impression that my job was fairly easy. In fact, when he attended a coding bootcamp a couple of years ago, part of what had motivated him to get into software engineering was this perception that it was this chill job with high pay and lots of freedom.
But #QuarantineLife does not at all resemble those relaxing WFH Fridays, and for the first time, he’s been directly confronted with the reality of my day-to-day work. I should explain, for context: we live in a ~600-square-foot studio apartment. I do have a proper desk and office chair, but our entire space is so small and arranged such that if I have my webcam on, you can always see him in the background, affording him no privacy (so I don’t have my webcam on very often). And because he isn’t currently employed and has no Zoom calls of his own to attend, he’s basically always overhearing mine.
This means he’s had a front-row seat to my career transition — and he is able to understand and empathize much more than ever before. If the pandemic hadn’t happened but I still became a manager, I bet he would have been tempted to think, “You’re just in meetings all day — how hard can it be?” But now he sees firsthand how hard it can be. He hears me arguing with senior leadership about the resourcing of my team. He sees the lost look on my face after I get out of an hour-long brain-melting meeting, trying to collect my thoughts and figure out what to do next. He watches me as I struggle to learn how to coach my direct reports and try to get the most out of our 1:1s.
Sometimes he comforts me (“Wow, it sounds like you were having a really rough day today.”), sometimes he chides me (“Don’t you think you were being a little too critical in that meeting?”). Mostly, he just observes and finds his own ways to be supportive — whether that’s simply starting to cook dinner while I’m still wrapping up, or quietly handing me a glass of wine towards the end of the workday, or enduring while I pop in the Pride & Prejudice Blu-ray for the one-too-manieth time that month.
I love him, and I could not have made the shift in a pandemic without him. ❤️
What Didn’t Go Well
I struggled with expectations about how much IC work we’re still supposed to do at the same time.
When the 11 new engineering manager roles were created as part of the reorg, the original vision was that with only 2–4 direct reports each, we would be able to achieve a true 50/50 split between manager and developer work. I had trouble with that, because an expectation that you spend 50% of your time each on two jobs quickly turns into an expectation that you do two jobs.
In my case, I had established a good understanding of what the role of a tech lead is among my team, and made it clear to them that that was the role I’d still be doing, but the new expectations hit me indirectly. As part of the reorg, I had sponsored one of my team’s senior developers to become an engineering manager in her own right — but that meant leaving our team so she could take this position for another team (and she’s thriving in the role, I’m happy to report). That meant I was left with one senior developer and two junior developers — still an excellent group of humans, but not enough to fully staff the needs of two scrum teams. I think senior leadership assumed it was fine because, after all, Nara was a senior-level dev, right? But now on top of being expected to carry an entire project (something I hadn’t done in nearly a year), I also had all of my management tasks to fulfill; even if I cut back on that somehow, it would have left me no bandwidth to invest in the process improvements I wanted to make. I felt overwhelmed; it was too much.
The solution ended up being to combine our two scrum teams back into one, which wasn’t an easy decision but the right thing to do.
As everyone quickly discovered, “WFH” isn’t the same as trying to work at home during a pandemic.
As with the section on remote work in the “What Went Well” section above, I don’t want to dwell on this a ton because the phenomenon has already been widely reported, and my team’s experiences largely reflect those same patterns: everything from struggles with childcare and virtual learning, to increased anxiety and other mental health effects. The article on surge capacity that recently did the rounds resonated with many of us:
What has been most challenging for me as a manager is remembering that people aren’t static. All of us — yes, myself included — have had periods where we could handle it, and periods when we just couldn’t. These ups and downs were not predictable, and I noticed that day-to-day and week-to-week, the changes were often imperceptible. But month-to-month, it became obvious that someone who had been ultra-resilient before had suddenly hit a wall, and someone else who just had a bad month was clearly doing better. Assuming these cycles continue to persist until there’s a vaccine and we can go back to the office, I need to learn to spot the warning signs better, so that I can more proactively offer my assistance.
Something I’ve been trying recently that’s been working well so far is asking, “On a scale from 1 to 10, where 1 is the worst you can possibly imagine and 10 is the best, how is your work-life balance?” during my 1:1s with my direct reports. (Full credit for this one goes to somebody else — I can’t remember which management blog post or tweet I got this idea from.) It’s worth noting that the answers will naturally vary from individual to individual; my 6 likely isn’t the same as your 6. But what’s important is the trend over time. If someone is consistently a 7 every week and then drops down to a 4, you know there’s something going on and you should probably try to nip it in the bud. I’ve also noticed that it gets people talking; even though the question itself doesn’t pry, something about it still encourages folks to share more about what’s affecting them both at work and in their personal life that might contribute negatively to their sense of balance.
Not everyone on my team reports to me, which creates a novel set of challenges.
Because we follow the scrum methodology, we are arranged into cross-disciplinary project teams, and so the people that I work closely with on a day-to-day basis are not just engineers, and not just my direct reports; my team also includes designers, product owners, scrum masters, and even an editorial SME. Obviously, all of them have been struggling due to the effects of the pandemic in different ways and at different times — but since they don’t report to me, it’s a lot less clear what I have the power to do about it.
This is essentially a variation of the practice of managing sideways — as opposed to managing down (the standard role of a manager, mentoring and coaching your direct reports) and managing up (teaching your own boss how best to support you). Unfortunately, there are a lot fewer practical resources on managing sideways — the management books I’ve read so far largely glossed over it — because organizational context plays such a big role, and depending on the situation, the approaches vary: sometimes you want to talk to the person directly. Sometimes you want to talk to their manager. Occasionally, it’s better to go to their manager’s manager. And very rarely, the most prudent course of action is to do nothing at all. It’s a delicate dance to begin with, and even more so during a pandemic, when the wrong approach can harm someone’s self-worth in a time when they’re likely already feeling down on themselves.
I’ve made this mistake several times already. I talked to someone directly when I should have gone to their manager. I talked to someone’s manager when I probably just should have done nothing. And I didn’t do a good job of getting my message across; it’s hard to say, “So-and-so is struggling to fulfill some of their responsibilities,” during a pandemic without coming across like a jerk, even though your intentions are good — you want to reduce ambiguity about who should be expected to perform that task so that somebody else who might feel equally stressed doesn’t feel obligated to pick it up unbidden. Communication is an art form, and this is one expression of it that I am far from mastering.
We challenged folks’ sense of belonging at the worst time.
Once the impact of the pandemic began to become clear in late spring, our department’s leadership was quick to acknowledge that our humans were operating under many new constraints, and we needed to recalibrate our expectations against our new reality. In the process of reworking our roadmap, an acute project need was identified, and a decision was made to temporarily reassign one of my reports to another team — an excellent growth opportunity for them, but a difficult move to make in a pandemic. Many of us are really attached to our teams; our belonging and sense of self at work are built around them. Is a crisis the right time to upend that?
This has definitely been one of the biggest challenges of my tenure so far. Because I no longer see them and their work day-to-day, I struggle to give them the same level of feedback that I’m able to give my other two reports. I’m also less empowered to remove obstacles for them. And more than anything, I empathize with the difficult situation this puts them in emotionally. As a child of two cultures, I know what it’s like to not know where you belong.
Despite all my best attempts at self-care, I stopped being able to maintain any semblance of healthy work-life boundaries.
There have been warning signs peppered throughout this post, so it’s probably no surprise: at a certain point, I too hit a wall. While the job was challenging from day 1, I didn’t find it truly difficult until a couple of months in. It caught me by surprise, too, because I had just removed a couple of obstacles I’d been facing, so it was supposed to be smoother sailing from then on.
There were many factors leading up to this, but more than anything, the problem was the combination of my never-ending to-do list and being childless during a pandemic. We have no kids, no pets, no responsibilities, just a 600-square-foot box that we live in, and most of my hobbies and interests were effectively canceled due to COVID–19. And at the same time, I had too much to do at work, and I never felt like I had done enough. So, it became easier to just keep working. 7pm… 8pm… 9pm… The week before my furlough — the peak of the crisis — I hit midnight a few times.
Part of the issue was my personality and upbringing: I was raised to prioritize delayed gratification. I will always gladly suffer a little now if I can avoid suffering a lot later. This works well for some things, and is a major reason why I was a high achiever growing up, but it’s not always a good thing when it comes to work. In particular, it’s not a good thing during a pandemic, when the risk of burnout is already higher than normal.
Another contributing factor, I think, was the first thing I wrote in the “What Went Well” section: that I made it my mission to protect my team’s wellbeing. While it was good to have a single focus, it became too tempting, in the context of everything else, to think that it was the only thing that mattered anymore. In other words, it became too easy to think of my job as my life — to stop observing a healthy distinction between the two. And that’s a slippery slope to fall down, because then you truly never stop working.
But perhaps worst of all, even when I managed to close my laptop lid, I had the hardest time getting myself to stop thinking about work anyway. I’d constantly replay conversations I’d had that day over and over in my head, or roleplay a conversation I needed to have the next day, or mentally write an email that could still wait. I experienced bouts of insomnia, lying awake all night thinking about work, unable to make my brain stop. It was awful.
What helped me claw back from the brink was, interestingly enough, rereading my personal user manual. In it, I’d written that one of the things I valued most was work-life balance. It shocked me to discover just how quickly my actions had changed to reflect the opposite of what I said I cared most about. I vowed to do better, both for myself and for my team.
Several of the aspects of the role of a manager don’t apply during a pandemic, and advice on what to do instead is few and far-between.
“Have too much on your plate? Delegate!” is a common theme in management books. It’s closely related to the idea of the stretch assignment — a task or an initiative you give a direct report to encourage their growth — because often, stretch assignments are things a manager was planning to take on themselves until they realized they don’t have a capacity for it, but one of their reports could take this on as a challenge. So given that I was struggling with my own work-life balance and feeling like I had too much on my plate, it should’ve been easy to just delegate more to my reports, right?
… Except that there’s a pandemic going on, and everyone else feels like they have too much on their plate, too. Literally everyone is trying to take things off them. Very few people have the capacity to take on anything extra right now. This is where that surge capacity article is particularly pertinent. We all need to be okay with just leaving things un-done right now, myself included.
There are other parts of management books that feel completely irrelevant at the moment. I chuckle when I remember a couple of chapters and articles talk about what to do when it feels like your job has turned 100% into hiring — boy, I’d love to have that problem right about now! But I’m not going to be there anytime soon. Instead, where’s my chapter on how to avoid resources being diverted from your team to other projects? Where’s my chapter on how to really, really, really convince your team that there’s no secret talk of layoffs?
It took me too long to admit that I was struggling.
When I managed to largely reset my work-life boundaries a few weeks ago, I didn’t immediately feel better. I still felt down. That was a surprise. Hadn’t I identified and fixed the problem?
The issue was that by gradually making more space in my brain for thoughts about something other than work, I made space for thoughts that weren’t, well, good. I realized that I was struggling with grief. Grief for the wedding and honeymoon I hadn’t had, for the grand newlywed life I was supposed to be living that I was not. Anxiety about the future, about whether I’m risking infertility by pushing our plans to try to get pregnant back another year or more. Worry for my mom’s health and safety, as a 70-year-old with a heart condition in COVID times. Fear that I may never see her again. Self-doubt about whether, as an E.U. citizen, I’m making the right decision by staying in the U.S. Anger at being stuck in a 600-square-foot studio apartment, unable to leave; we don’t own a car and my husband is terrified of the virus, so we’ve only left the District once since the day we got married in Virginia.
Why had I not admitted to these struggles before? Why had I downplayed them? Probably because there are so many struggles being reported on during the pandemic — people who lost loved ones to COVID–19, frontline workers, parents trying to work full-time jobs at home while their kids are doing virtual learning — that I had convinced myself that my problems didn’t matter. Didn’t count. Weren’t worthy. I gaslit myself into thinking my struggle wasn’t real.
In retrospect, my bout of unhealthy workaholism may have subconsciously been a defense mechanism that my brain employed to mask the real problem. Better to just work all the time than confront my grief and anxiety head-on. Better to chase the nebulous idea of completing a never-ending to-do list than to look my demons in the eye.
I’m still working on this; these developments are fairly recent. The approach that I’m trying to take here falls into a category that, in management writing, is often called “managing yourself” — a phrase that, when I first read it, I thought was silly, empty business jargon, but as I’m growing into the role, makes more and more sense to me. The idea is that in addition to needing to learn how to coach my reports, I also need to learn how to coach myself, using self-awareness as my superpower. That means recognizing my own strengths and weaknesses and areas of development, and pushing myself to be better — but also validating my own struggles and convincing myself I have done enough. Maybe it wouldn’t be enough in The Before Times, but that doesn’t matter now. There’s a pandemic going on, and it’s okay not to be okay, and to say this is all I can do for now.
Well-Intended Advice That Wasn’t Helpful To Me
This section will be brief, but I wanted to point out two pieces of advice that I was given that did not end up being helpful, at least not to me. Your mileage may vary.
Calendar management will only take you so far. It’s not a silver bullet.
When I tell people it feels like I spend most of my life in meetings, they tend to respond with, “That sounds awful!” I don’t necessarily feel that way because the bulk of these meetings are important and a good use of my time. But what I do struggle with is the context-switching, especially switching back-and-forth between “manager brain” and “tech lead brain.”
A solution that’s often proposed is to manage your calendar better: to rearrange your schedule so you have to do fewer context switches. The problem is that I have very little control over most of the things on my calendar, and not enough clout to ask the schedulers to change the timing to better suit my needs. And for the meetings that I do control — for the task forces and committees I help lead, for example — I’m often still powerless when it comes to choosing the time if I want everybody to attend. For meetings with 10+ attendees, in particular, I’m lucky if I can find one timeslot in a week when everyone’s free. So that’s when that meeting’s going to be!
Calendar management may work if you have a personal assistant who can reach out and convince others to change meeting times to suit your needs, but as just one individual, I can generally only try to make the best of what I’ve been given. That said, I have found it helpful to at least color-code my calendar to help me anticipate when the most draining context switches will need to happen.
No, it isn’t better to make every weekend a 3-day weekend. You need to take at least a full week off sometimes.
The idea is that, as a manager, it can be hard to convince yourself that you can actually step away from work and not have everything fly off the rails — or even just ensure that all of your normal responsibilities are taken care of. So one proposed solution is to just take lots of Fridays or Mondays off.
This may work for others, but it doesn’t work for me. Particularly because of how much I still struggle to turn off my work-brain, I’ve discovered that a long weekend doesn’t help me disconnect. Even if I keep myself busy during the day, I find my mind circling back to work things in bed at night. It’s probably not until the 4th or 5th day off that I am actually able to stop thinking about work — and to me, that’s the value of using vacation time.
The best solution for me turned out to be to just bite the bullet, take the whole week off, trust that my team can handle things in my absence, and trust in myself, knowing I did the best I could to set them up for success.
If I were truly committed to the agile retrospective format, then I would end with a section on what I would do differently next time. But at this point, I think the genie’s out of the bottle; there’s no way to undo what happened, and even if I got to do it all over, I’d likely still make the same choices. So in closing, I’d like to share what’s on my mind as I head into my next 100 days.
What I’m Thinking About
It’s all about values.
I’ve mentioned values a few times throughout, underscoring how important I think they are, but I really wanted to emphasize this point again before I close. I am constantly asking myself two questions:
- What are my values?
- Have my recent actions consistently demonstrated those values?
My values have really been my “North Star” during these challenging times. I know that’s a bit of an odd thing to say because normally, North Stars tend to be more aspirational — they reflect less of where you are now and more of where you want to be. But, frankly… I’m unable to concentrate much on visions of the future these days. I have some vague ideas — an abstract watercolor painting without any outlines — but I can’t get my brain to focus on adding any details. Truth be told, my goal for the next year is just surviving. Surviving, and finally going on my wedding tour and honeymoon, and cuddling a koala.
Given how many threats and obstacles lie looming in the next few months, until there’s a vaccine and maybe things start to go back to normal, I find it difficult enough just to remember what my values are and ensure that I am actually living them. I mean, we saw how easy it already was for me to forget about how I valued work-life balance and to start doing the opposite! If I can survive the next year with my values intact and with my actions having consistently reinforced them, I’ll already have done a lot. That’s why my values are my North Star.
Do enough people know what they can and should expect from their relationship with their manager?
I’ve been thinking a lot about why there are so many “bad managers” — not at NPR specifically but in general. There are numerous contributing factors, and the next section will touch on this topic as well, but one thing that certainly doesn’t help is that so few people have a model for what a good manager is. They might have a string of average managers, never raising the bar for what they expect from that relationship. This is problematic because the world would be a better place if everyone had a strong, healthy, positive manager-to-report relationship — so we should be setting the bar higher.
I do a fair amount of public speaking (or used to, anyway — I haven’t had the energy to do any virtual events since the pandemic hit), to the point where my brain is trained to look for opportunities to turn my recent experiences into talks. I’ve always found it easiest to write a talk about whatever project has recently taken up most of my time, but for the past year, the “project” I’ve been most focused on is becoming first a tech lead and then an engineering manager. So, I’ve always assumed that my next talk will be about that.
But recently, I’ve been pondering if there’s value in approaching this from another angle: instead of talking about what it means to be a tech lead and why you may or may not want to become a manager, why not write a much more accessible talk about what anyone with a manager should be able to expect from that relationship? Managing up would certainly be a big part of it, but there would also be an element of, “these are the signs of a healthy manager/report relationship.” I think that’d be useful, too.
You can measure the health of an organization by how well it supports its low-level managers.
In discussions about why there are so many “bad managers” in the world, a common theme centers on the fact that in so many organizations, going into management is the only way to advance one’s career past a certain point. Folks are often attracted by the idea of gaining influence or “power,” not recognizing that that’s only one aspect of the job, and so you wind up with a lot of personalities in management that maybe weren’t naturally suited for it. But I agree with the assertion that Julie Zhuo makes in her book, that good managers are made, not born. So even if there’s an expectation mismatch, it should still be possible to move past that and make good managers out of these folks who were perhaps not inherently suited for it. Why, then, does “bad management” persist?
As I’ve made my own move into the management track, I’m often struck by the nuance of everything — the fact that all things exist in shades of gray. And that’s especially true of people and their motivations. No one intends to be a bad manager; I’m going to be generous and assume that everyone wants to be good. If that’s the case, why is it that so few actually get there?
From my experience as an entry-level line manager, I think one major contributing factor is that it’s so easy to be overloaded with to-do list items from day 1, especially when you’re still expected to do individual contributor work as well. And when you’re constantly racing to tick things off that to-do list before too many new things pile on, you don’t end up giving yourself time for reflection and learning. After all, this is part of the cycle for growth:
- Self-awareness and/or direct feedback — what are my strengths and weaknesses, and where do I most need to grow?
- Reflection — how have my recent actions demonstrated my strengths or my areas of development?
- Planning for growth — how can I do better next time to improve upon these areas of development?
There’s not enough acknowledgement that these things take time — that you will need to spend some time when you’re not in meetings to do this. But it’s all too easy to wind up with a to-do list that already requires more than the number of hours a week that you’re not in meetings, let alone factoring in this additional reflection time.
While individual choices (as to how you spend your time) do play a role, the biggest need is organizational support: new managers need to know that it’s okay to spend some time on self-awareness and reflection; the expectation is not that they chase their to-do list all day. And it’s especially important to reinforce this lesson among your lowest-level managers, because odds are that behavior was never modeled or normalized for them, so they probably don’t know it’s fine unless you explicitly tell them.
It doesn’t help that there’s a lack of investment in leadership training throughout the tech industry. It’s common to see organizations’ training budgets spent primarily on sending folks to technical conferences. How often does your company use that budget to send a manager, especially an entry-level one, to receive leadership training? And what does that say about what you value?
I spend a surprising amount of time thinking about what I would ask if I were to interview for a new job, not because I’m planning to change jobs or companies anytime soon — I’m really not (and please don’t send me any recruitment emails, I’m not interested) — but because I think it’s a good way to do some self-examination: if I can think of questions I’d ask to figure out if a new job and a new company are a good fit for me, then what I’m really doing is supplying myself with questions I should ask to help myself determine if this is still a good workplace, or if there are changes I can help make.
My questions used to focus on things like work-life balance, and how much trust and autonomy individual teams are given. But lately I’ve been thinking of some variation of the question: “What does your organization do to support its lowest-level managers?” And what’s most interesting is that I could picture myself asking this question even in some alternate universe where I decide to stop being a manager and go back to being an individual contributor — even if I’m not one of those managers, or had any management aspirations, it’s still really important. Because line manager relationships have so much impact, both positive and negative, on the individual experience — and by extension, a workplace’s culture. By not adequately supporting its low-level managers, a company is hamstringing its ability to create a healthy and inclusive culture. In fact, I think this is an essential element in the DEI (Diversity, Equity & Inclusion) conversations currently going on.
I need to actively work to avoid burnout, both for myself and for my team.
I’ve talked about burnout throughout this post, so I don’t want to reiterate many of the points I’ve already made. But I felt obliged to point out that as I’m thinking through how to avoid burnout for myself and my team, I often find myself coming back to the Maslach Burnout Inventory:
- Lack of Control
- Insufficient Reward
- Lack of Community
- Absence of Fairness
- Conflict in Values
- Work Overload
Maslach’s thesis is that organizations (and their leaders) tend to assume that burnout is only caused by #6, but these other five factors are just as important. And the pandemic has exacerbated each and every one of these, which is why we’re all at much higher risk of burning out.
Lack of Control: I mean… *gestures at everything* The pandemic itself, and its specific impact on our individual lives, is something none of us can control. At NPR, one area where this has come into play is our roadmap conversations. Though well-intentioned, many of the initial adjustments to respond to the pandemic were done by a very small group of people, leaving a lot of folks with a perceived lack of control over their work.
Insufficient Reward: With promotions and raises frozen, and staff being asked to choose between pay cuts and furloughs, how do I as a manager ensure that my reports still feel sufficiently rewarded for a job well done?
Lack of Community: Though we were well-equipped to pivot to being fully remote, we were still a company with an office, and people used to have team lunches and go out for drinks together after work. Even just random water-cooler conversations contribute to a sense of community. While we’ve tried many ways to replicate these experiences online, it doesn’t feel the same.
Absence of Fairness: There’s a number of directions you can take this in, but probably the best example is less to do with the pandemic and more to do with the internal DEI conversations that have been reignited as a result of this summer’s reignited social justice movement.
Conflict in Values: Again, this can be taken a number of ways, including my earlier example of valuing of work-life balance but creating my own conflict. I’ve found that having an articulated list of values is also a double-edged sword, because I often find myself thinking, “I know I value these things, but does the rest of the organization?”
These are tough problems, and I wish I had more answers as to how to resolve them, especially since there are playbooks out there, but not everything applies during a pandemic. Ask me again after my next 100 days, and I hope I’ll have come closer to figuring out the solutions.
That was … a lot, and I’m deeply grateful to you for sticking with me for so long. I know I’ve still got a long way to go — Julie Zhuo wrote that it took her about three years to get used to the job of a manager — but I hope that what I’ve learned so far has been of some help to you, regardless of where you are on your own journey.
I want to end on a note of thanks: to Kaivon, Kris, and Tommy. It’s been a privilege working for you so far, and you have my gratitude for sticking with me while I’m figuring it out and trying to become a better human as well as a better manager. And to Laura, for all the great feedback.
P.S. If you like the work that we do, please donate to your local NPR member station. It’s the best way to show your support.
