How to be left

What to do when a senior-plus engineer leaves and you are senior-minus

Anna Rosenthal
7 min readApr 29, 2020

Out of many team dynamics that barely get discussed online is how to deal with the departures of senior-plus (senior, staff, and principal) engineers, especially if those staying are newer, not-yet-senior engineers.

In my relatively short time as a software engineer, this happened to me twice. My reactions both times could not have been more different, and watching other people process the news with me, got me thinking: why don’t we talk about this? To make the conversation more valuable, why don’t we discuss how to offer support to those being left.

May no one start their software engineering careers the way I did. Even after choosing the team where I had hoped I’d learn the most and do the most interesting work, I joined a team on Monday where the manager’s last day was the previous Friday. Their departure spiraled into two more: a tech lead with a 1.5 years tenure left our team three weeks after I started. Less than a month later, the only other senior engineer on the team who’d spent nearly two years with the company also left. There were no senior engineers (or above) left on the team and, still, no direct manager. What happened on that team will forever remain a professional trauma, the aftermath of which shaped me into the engineer, direct report, and coworker I am.

The second time I was left, it happened five months into my current job. A newly formed infrastructure team had two engineers: me and a principal engineer. Our brand new manager was barely a month into his job leading two teams when we heard the announcement of my team becoming a team of one. The principal engineer was leaving. I was to become the infrastructure team. This time around I dealt with the news and its aftermath much better. Below is my reflection on what helped me the second time when I was left — four pieces of advice I would have given myself in my first job, four things I must have learned since.

#1

Develop relationships at work and build a support group for yourself, regardless of team affiliation and seniority: on your team, outside of your team, with your skip-levels, people from teams you didn’t know existed. Meet people and learn to partner well — it will serve you well at work and in life. Talk about the departure news with your teammates if you have them — this will help you process the news in a less acute manner. People outside of your immediate team may offer the strongest support. It’s possible that they have gone through something similar and have the advice to share that will apply regardless of the team.

#2

Out of the senior people who are still around, understand who you can rely on to better understand the domain and grow technically. Maybe it’s someone who used to work on what you are working on and is now on a different team. Maybe it’s your manager, maybe it’s a different manager who used to manage your team in the past. Reach out to them and ask whether they’d be open to answering your questions, should you have any or casually need an extra pair of eyes on a PR. In my previous job, I reached out to a staff engineer asking whether I could pair with him on Fridays to review my code in person and go over more complex technical questions and concepts. He said yes and he’s my friend to this day with whom I regularly discuss tech topics (hi Gene :) In my current job, I reached out to a principal engineer on a different team and asked if it’s okay to schedule bi-weekly 1:1s with the goal of me learning how to become a better interviewer, mentor, engineer, and programmer. He agreed and in all our meetings so far, his advice and perspective have been valuable (hi Danger :) My hope for you is that other people at your company will be sympathetic and empathetic, let you lean on them during this transition, and spend time with you helping you get back on your feet. Remember though, if you don’t ask, the answer is no.

#3

The following idea liberated me the most in my current job, and maybe since I was in my first software engineering job, it could not have served me as well then, as it did now. According to a blogger whose posts I casually read, Google has an internal video called “There’s no adult in another room.” I may be misinterpreting the message since I haven’t seen it, but the idea seems to be: there may be no one out there with a solution to the problem on hand. In this context, adults are anyone above you on the corporate ladder: senior, staff, principal engineers, managers, tech leads, architects, product managers, VPs, and CTOs. Back to the idea of the video: no adult in another room may be able to understand or explain the problem, tell you how to go about solving the problem, make your solution simpler, or confirm any assumptions. Which means: you may know the problem and solutions better than anyone else, better than the adults. You are capable of making sound decisions and moving things forward. At the same time, you are fully responsible for the decisions you make, the designs and code you write, the approaches you take and don’t.

It doesn’t mean that we are operating in a state of full anarchy, and that you shouldn’t get others’ opinions, or that other adults don’t have valuable ideas or advice to share. They may do so and to the extent possible, you should leverage as many perspectives as you can get, yet you’ll be the person to make final calls and execute. It’s also possible that no one at the company would know where to even start solving the problem you are tasked to solve — that’s okay. You are capable of learning and understanding the problem, possible solutions, tradeoffs, and making a decision. This being said, you may make mistakes — and guess what — that senior-plus engineer who left or is about to leave, might have done a better or worse job of solving the same problem, making the same or worse mistakes. Just in case you need to hear it again: it’s okay to make mistakes — doing so and learning from them is one of, if not, the most effective way to learn.

For a strange reason that I’m still trying to untangle, newer engineers regard themselves as those who know close to nothing and senior-plus engineers as those who know everything (which they don’t — I have plenty of examples to prove this), and it somehow all ends there. My speculation is that these are imposter-syndrome-fueled, hero-worshipping tendencies but I’ll keep untangling.

As improbable as it may sound, technical leaders may offer limited advice if any at all, and not know what’s next. Stop looking for an adult in another room and become one yourself: step up your learning and doing games. Look at everything you are doing as an opportunity to learn and improve.

#4

If you see your manager overworked (I have yet to meet a manager at a startup in New York City who isn’t), and there are initiatives, features, tools, or domain fields that were owned by the departing engineer, offer to take over those, at least temporarily to create a sense of community, stability, and continuity. People from other teams may rely on those initiatives, features, tools, and fearing the unknown, are imagining that things will fall apart — take action to prevent such sentiments if you can. In the time that the departing engineer still has left, ask them to go over the documentation of the most recent projects and/or schedule some time with them to go over the nuts and bolts. Ideally, they could also make public statements of you formally taking over those areas so that others know the new point person moving forward.

I don’t mean to discount the disappointment, sadness, distress, and pressure that come with the news of a team member, especially an effective, kind, and helpful engineer leaving: they likely were leading high-visibility projects and had domain knowledge that is, more often than not, not replicated or written down anywhere. Both times during those weeks between the announcement and their last day, I felt betrayed and neglected, drifting away mentally multiple times a day. Yet, I know for a fact that without what happened, I would not have learned to build relationships that transcended jobs. I would not have learned to advocate for myself and be my own manager first. I would not have learned as much, as fast as I did. I would not have learned when to ask for help and what kind of help to ask for. I would not have been given the opportunities I have been given. Back then I didn’t know that this was me learning to stop looking for adults in another room. Granted that there are less adverse paths to learning this and other lessons, such has been mine and if yours is looking similar, we are not alone.

Thank you to Gene, Michalina, Dan, William, James, Noam, Manni, Bahar, Danger, Morris, and Amir for being the kind of people I could count on. Thank you, Camille, for giving me advice on this topic not once, but twice. Thank you to Leah and Jill for proofreading and encouraging me to write — without them there would be nothing for me to share and for you to read.

Thanks for reading.

--

--