"Elevating Your Career: From Senior to Staff Engineer and Beyond" (Video & Transcript)

"I think when you start, you want to do a lot of flashy work, but as you go higher up, a lot of the work you do is kind of beneath the surface. It's not really seen, but it's felt by more people at the company.” - AJ Oxendine

"They're not soft skills, they're foundational hard skills. We're talking about communication, collaboration, good writing skills, good documentation. All of those are so, so important, the further you go up the ladder as an IC and as a manager. You don't have to move into management for those to be incredibly important. Up until you're about senior, they're seen as pluses, but by the time you get to staff, they're not really pluses. They're really required of you, and you can tell when people are lacking those skills." - Ei-Nyung Choi

“What you might notice, going from senior to staff is in terms of who should know about your work. When you are a senior engineer, typically your EM has a good sense of exactly what you're doing. When you go to the staff level, or if you are looking to get promoted to the staff level, one of the big things is you actually want people outside your team to know who you are, what you're doing, and advocate for you.” - Allison Liemhetcharat

“I was working at a company that was small, and so the title was more reflective of the years of experience, and it was always all hands on deck to do whatever needed to be done. It didn't matter what your title or your role was, you were expected to do it, which meant junior engineers got really, really great opportunities, and principal engineers had to do whatever happened. And then as the company grew, suddenly the expectations are kind of more in line like principal engineers do X, Y, Z.” - Cathy Reilly

AJ Oxendine is the Tech Lead and Staff Software Engineer for the Home Feed product at Pinterest. She enjoys the creative process of building new things, figuring out how they work, and how she can make them better. This passion has led her to study music composition, art, graphic design. and now, software engineering.

Allison Liemhetcharat is generally interested in using artificial intelligence to solve real world problems. At DoorDash Labs, Allison is the technical lead manager of Simulation and Evaluation, and working to improve autonomy. Allison attained her Ph.D. in Robotics from Carnegie Mellon University. Allison cares deeply about Diversity, Equity, and Inclusion (DEI) and mentorship, and has led employee resource groups (ERGs) and mentored over 40 people throughout her career.

Cathy Reilly is a Principal Engineer at Circle. Her 30-year career in tech has also included 14 years at Adobe.

Ei-Nyung Choi has worked in tech for almost 30 years, in roles as Sr Software Eng, Principal Staff Eng, Eng Manager, Software Architect, Co-founder, and CTO. She’s currently the Fractional CTO at tEQuitable.

Transcript has been edited for clarity.

Cathy Reilly: Hi, my name is Cathy, and I'm a principal engineer at Circle. I'm going to lead today's discussion focused on the transition from senior to staff engineer and beyond. We have a panel of all of you, the four of us highlighted in the screen, who have a variety of experiences, and we hope you come away with a clear understanding of your path. I'm going to ask each of the panelists to introduce themselves and also to give us a rundown of their career journey until today, and we're going to start with Ei-Nyung.

Ei-Nyung Choi: Hello, my name is Ei-Nyung Choi, and my pronouns are she and her. I'm currently the fractional CTO of tEQuitable, an independent confidential platform that helps companies create a safe, inclusive, and equitable workplace. I've been thriving in tech for 26 years. Seems so shocking for me to even say that. Having been everything between the most junior developer to the most senior by 10 years, to being an EM, to being a technical co-founder of my own startup, I've seen extreme success and incredibly painful failures along the way.

I started when jobs were falling out of trees if you knew HTML and Perl, which was back in 1998, and have seen multiple different contractions. I had graduated as a mechanical engineer from MIT, but I had this part-time job doing webpages for the Sloan Business School because I liked messing around in HTML, and I had the most embarrassing personal homepage ever.

From then, I went on to join a pre-modern era mobile startup, meaning that we were building for the Treo, if you remember any of those phones, and for Nokia phones, these old phones, which then led me to joining another startup that was in the first wave of iPhone and Android app stores, which led to incredible success.

My studio had spent six years straight, never leaving the top-grossing list for the app store. I then started a mobile game startup of my own, which I eventually had to shut down. That's a part of the painful stuff that happened. I went back to working for someone else, which was Slack, as a regular engineer, not a leader like I was used to, because I needed a break from being responsible for very heavy decisions.

And at Slack, I was promoted to one of the highest engineering levels and led some of the best teams and projects of my career. Two years ago, because I was in a privileged position of being able to do so, I quit my full-time job to focus on my values and goals of having a positive impact on tech. I currently mentor and coach mostly underrepresented engineering leaders and founders, with a focus on women of color in particular, because I want to see all of you succeed. I'm so excited to join this amazing panel to talk to you about what it's like to go from senior to staff engineer. Thank you.

Cathy: Thank you so much. That sounds great. AJ, are you ready?

AJ Oxendine: Sure, I can go next. I'm AJ Oxendine. I work at Pinterest as the tech lead for home feed. I was just recently promoted to staff engineer, so I'm the most green out of this group. Thank you.

I actually started out as a graphic designer. I studied graphic design at FIT, communication design, and I wanted to start my own web design business. Ended up needing to learn how to code an actual website for a merchant, so like a content management site.

And from there, I struggled with the code. I got it to work, but I felt like I needed to learn how to code, so I actually ended up taking a bootcamp learning, not web design, but app development on Android, and that led me to get an apprenticeship program at Pinterest.

They have these really great apprenticeship programs, which are for people who don't have a traditional computer science background but are good engineers and want to kind of get their foot in the door. So I started at the lowest of the low, and they give you about a year to get converted to a full-time employee. I did it about six months, and so that put me at L3 engineer, and that was about five years ago. Oh, actually I'm on my sixth year.

So from then, I've been promoted multiple times up to senior engineer, and now I'm staff engineer and tech lead at Pinterest. And so I had a pretty straight row at Pinterest.

Cathy: Thank you so much. Allison.

Allison Liemhetcharat: Hi, I am Allison Liemhetcharat. I'm currently a senior staff engineer at DoorDash Labs. Also, for my career journey, I actually did my bachelor's and PhD at Carnegie Mellon. Also, my PhD was in robotics, and after that, I was actually working in a government research institute, so this was kind of my coolest job title. I was a scientist, which is still my favorite job title till day.

And then around that time was when autonomous vehicles were starting to get popular, and Uber kind of started the self-driving division. So that's when I went over to join them, and I worked at Uber for about three years. There, I led simulation and I worked on motion planning as well, and it was a nice experience. We actually grew, at least from the autonomy side, we grew from 200 to 2000 people, so it's a huge growth in the short period of time.

So there's a lot that can be said about that as well. And subsequently, I joined a small startup…. So this was started by someone that I knew from before Uber, and then he created a startup. He was at Uber, he created a startup. I joined him after a while. I worked there for also a little bit over three years, and the focus was on providing kind of Uber-like services for autonomous vehicles, and eventually the startup we were acquired by Gopuff. And that was around the time that I decided, okay, I've gone through this startup journey, and I was pretty good.

I took a break. So I did a one-year sabbatical, where essentially I wanted to take a break from all the work stuff and spend more time doing stuff I wanted to do. And one of the cool things I did was I actually work on video games with my daughter. So we did that for quite a while. It's still something that I try to do now that I'm working again, but much less free time to do it. And after my sabbatical, I joined DoorDash Labs to work on autonomy, and right now I'm a technical manager in charge of simulation and evaluation. And yeah, I'm really excited to be on this panel today.

Cathy: Okay. And thank you so much, and I'll finish it off. So I would say that my career journey would be fairly typical. I think the atypical thing for me is that I've been at a few companies for a long time. I was at Adobe for more than 10 years, and the last three years of that experience, I was on the infrastructure team building stuff on top of AWS, and that led me, both the people and the technology led me to the company I currently work at.

So I've been at Circle for 10 years. It's in the cryptocurrency space. It's a startup that is a little more than 10 years old, probably 10 and a half or 11, been through a lot of expansion and contraction. We're currently in the middle of an expansion period, which is great. During one of those previous expansions, I was in charge of a data center deployment and migration project, which is probably what got me to the principal engineering position.

And now that we're in a second period of extensive growth, which, not quite the level that Allison just said, 200 to 2000, but more like 50 to 250 engineers, which I think is a lot. I feel that the expectations of me as a principal engineer have changed a lot. So that's something that we might talk about later.

Okay, so that's our introductions. What we're going to do today is we're going to divide the panel into three different parts. In part one, we want to talk about what are those staff engineering roles, what are the scopes and responsibilities as well as the skill sets that you might need to be successful at one of these roles. And Allison is going to start us off. So how do you think the scopes and responsibilities change as you move into the staff engineering roles?

Allison: I think one of the big changes is the amount of the kind of work that you do. I think generally as a senior engineer, your work is a little bit better scope in the sense that you'll be given a task and say, okay, this is a project you need to do within a certain deadline. You have to do it with certain deliverables and so on.

When you transition to the staff, I think this is where the goals start to be a little bit more nebulous. You have to work with different teams to kind of figure out exactly what do they want? What is the MVP that will work well for all the people that care about it, as well as things like what are the timelines?

So you need to understand how badly do they need which features when, in order to actually build out all these pieces. So as a staff engineer, you might be building on some of these yourselves. You might be also in charge of parcelling out the little pieces, the architecting of the pieces so that then you can hand it off to other people on your team to work with as well. I think that's one of the biggest differences I've noticed in terms of the scope.

Cathy: Aj, would you say you had a similar experience in terms of the scope of responsibilities?

AJ: Yeah, so when I first started, I think my scope was very feature-based. So I've been a product engineer, I think I forgot to mention that. But it was very feature-based, metrics-driven, like do this new flashy screen, make the metrics go crazy, get the C-level happy. And that was really just it.

And as I went from L3 to L4, maybe it became getting the code cleaner, just for my team. Refactoring things, making better hierarchies between the pieces of code that we're using.

But as I progressed from L4 to senior level, the scope became working with cross-functional teams, making sure that we had seamless design between our team and the other different orgs at the company.

And as I went from senior to staff, now it is more about making design decisions, talking with designers and PMs and managers, and really making sure that the app as a whole works together. Thinking ahead about what bugs and issues we might encounter when we try to bring new campaigns across the company.

And really, the work that I do now is helping other engineers on my team reach a higher level. I want them to have the same critical thinking design skills that I had when I came up. Making sure that we have the right tools across our company to share the same architecture.

It's more broad. My reach is much farther. There's people on teams that I haven't even heard of who need something that I built for them. And so yeah, I think when you start, you want to do a lot of flashy work, but as you go higher up, a lot of the work you do is kind of beneath the surface. It's not really seen, but it's felt by more people at the company.

Cathy: And is there any skill that you had to acquire that surprised you?

AJ: Talking to people? Communicating with people. There's a funny thing I used to say about talking to backend engineers. It felt like they were from Mars and we were from Venus. I would explain some kind of UI pixel UX scenario, and they had no idea what I was talking about. And they'll talk about CGS and models and machine learning, and I don't know what they're talking about. And so, really creating a language to understand things with people who have no context about what you're doing, that's a really good skill to have.

Cathy: Totally agree on that. Other key skills that I think that I use probably every day is acquiring broad knowledge, whether it's through experience, investigation, networking, and becoming good at seeing what's there and what's not there. So one of the examples, that's not a product example, but an everyday example, is taking that pull request. And when you look at that pull request, you can look at it a couple of different ways, and if you're a junior engineer, you're going to look and you're going to see what's changed and you're going to be like, okay, that makes sense, that makes sense, and that makes sense.

But when I go and I look at it, I'm trying to figure out, does it match the requirements of what you were supposed to do? Did you add all of the tests that you were supposed to be adding when it gets deployed? Are you going to be able to figure out what went wrong when something went wrong, and is it self-documenting? Is it maintainable?

Because I know in six to 12 months or two to three years, when I have to look back at that code, that I will never remember what I said. So maintainability is a big thing, and I think that's one of the big things on the continuum from a junior to a more senior engineer. So for me, those are those skills, like what's there? And then as you become more senior, what's not there. So I think that Allison also talked about some of this ambiguity.

So now onto personal experiences and challenges transitioning. AJ, earlier when we talked, had mentioned the fear of not meeting expectations in this new role and how she got over it. Would you like to share something with the group today?

AJ: Yeah, so I believe when you're a lower-level engineer, it's really easy to meet expectations. They're like, build the thing, you build the thing, it's done, and it's very clear what you were supposed to do.

But as I became a staff engineer, it's really difficult to understand what my expectations are, what's required of me as a tech leader for home feed, how do I actually do well in this position?

And I almost didn't want to take the tech leadership position because I was really good at being a senior engineer, like, okay, you wanted a kick ass person, I can be kick ass. But it felt really ambiguous as to what would be required of me as a tech lead.

And there's also the fear of letting my team down or not having all the answers or not putting them on the best path, but I think it's a learned-in position. As I go day to day, I actually feel more comfortable in this role, and I feel like, oh, I actually do know what I'm doing, and there actually is a reason that they gave me this position. And I think most of it is just kind of doing that thing that they saw in me to begin with, and just sort of expanding on that and really leaning into that. But yeah, it was very difficult to grasp what was expected of me in this role.

Cathy: It sounds like you're successful in overcoming that challenge for now, and I'm sure there's a new one around the corner. For me, I would say that one of the personal challenges is that I was working at a company that was small, and so what happened was that the title was more reflective of the years of experience, and it was always all hands on deck to do whatever needed to be done. It didn't matter what your title or your role was, you were expected to do it, which meant junior engineers got really, really great opportunities, and principal engineers had to do whatever happened.

And then as the company grew, suddenly the expectations are kind of more in line like principal engineers do X, Y, Z, and I still have to recalibrate because...anyway, I still have to recalibrate. My ongoing challenge is recalibrating there. So maybe I should take some of that confidence and optimism that AJ had into my new role.

Ei-Nyung, you also talked about this difference between senior and staff at different companies.

Ei-Nyung: Yeah. My experience was that the first time I had the senior title was actually really early on. I was only two years into my career, and I was like, I guess I'm a senior now. I was at a very small startup, and I think there were maybe, at the peak, maybe 12 engineers, maybe as many as 15. And there were people that were also called senior that had 15 years of experience more than me.

And so I was like, I have joined the ranks and now I'm one of them. And I was really incredibly lucky in that place where just like Cathy said, because it was a smaller company, even as a junior engineer, I had so many opportunities, so many things I could do to show that I was learning and that I was contributing, but also these senior engineers were so giving and had shown me so much of what I had to do.

But when I compare that to, so that's senior in a small company, where I was doing a lot of stuff. I'm working independently. I know who to talk to, I know how it relates to our product and business goals. But my technical skills, when I think back, they were not there.

I was only two years in. I was doing the best I could, but after that, I went into again, as senior roles, to a couple of different companies. And after, I think, the third company... fourth company, I think, I went in as a principal because it was, again, a team of six engineers. And so I went as a principal engineer because I was one of the most experienced people there. And you are just holding down the fort. But again, I think I was only seven years in. Seven years is a long time, but I didn't sort of have my peak potential.

But the place where I experienced a really like, oh no, what's happening, is when I went to Slack after being an EM and being principal, being an EM and being a founder, and I went to Slack, I actually went in as a senior.

And the thing was that when I saw the job req, I only saw junior and senior as the two different software engineer and senior software engineer as the two types of job reqs. And I was like, yeah, I think I'm senior, so I'm going to apply for the senior role.

And I didn't realize that there were more levels inside the company, that those were just the external roles that they had. And I was like, oh, there are three levels above me. What? I thought I was going to....Because at that point I had 19 years of experience when I was going to Slack, and I was like, I'm going in as a senior, and I saw people come in after me coming in as staff that had six years of experience, coming in as senior staff that had 12 years of experience.

And I was like, I am so angry. But the fact of the matter, and I was angry for a long time, they did fix it. They gave me a bump up to staff, but they were like, we're going to keep you at staff. I was like, I should have come in as senior staff, was my feeling.

But I did learn a lot, and I learned the difference between small company and big company. I didn't have the experience with the kind of reliability that large-scale companies needed. I didn't actually have experience doing unit tests, and I didn't know how to write linters.

I didn't have a lot of these sort of tools-oriented, specific knowledge-oriented things that are so useful in bigger teams because I was used to operating in smaller teams. So when I was staff at Slack, I'm like, ah, this is actually comfortable at Slack when you're staff, you have the impact that you have on other people, but you're not responsible for large company decisions and large initiatives, but you have an impact on a small cone of people, which are the people in your team and in your neighbor sister teams.

And then it was a big jump also to senior staff. But I think that I just learned that the titles are not uniform. Don't be worried about...yes, be worried about the titles, it's going to impact your career, but really find out what those roles at the smaller companies and larger companies map to in real life before you understand that you want the title.

Just like AJ said, sometimes you were a little bit uncertain about taking that leap because you knew the responsibilities are different. So learn what those responsibilities are at the company that you're at or the company that you're going to make sure that you are in the level that you want to be.

Cathy: I think that makes sense. For part two, we're going to talk about balancing technical and soft skills. And I think that Ei-Nyung hinted at this, and you're up next on discussing the importance of both for staff engineers.

Ei-Nyung: So we talk about soft skills and we talk about glue work, and I think a lot of people have heard those phrases. And for me, it kind of makes me mad. Sorry, I'm full of energy today. Because they're not soft skills, they're foundational hard skills as far as I'm concerned.

And we're talking about communication, collaboration. We're talking about good writing skills, good documentation. All of those are so, so important, the further you go up the ladder as an IC and as a manager. You don't have to move into management for those to be incredibly important. Up until you're about senior, they're seen as pluses, but by the time you get to staff, they're not really pluses.

They're really required of you, and you can tell when people are lacking those skills. So really, I actually, even though I knew that in some ways it hurt me to be doing a lot of the glue work and doing the sort of "soft skill" stuff, I made sure that my technical stuff was always indisputable, but I leaned into doing things like mentoring and into things like being the one who communicates out stuff about the team and being the one that goes to the meetings because, honestly, that gives me visibility too.

I enjoy it. I built my skills at it, other people didn't want to do it, and it gave me visibility. And so it was for me, a win-win. But I know that in a lot of places, it's not a win-win, and it's just like grunt work. So see where you are, understand how that work is seen, and lean into it.

But yeah, those aren't just management skills, but they do transfer very easily into management, collaboration, communication. So keep working on those things and don't neglect that part.

Cathy: Allison, I believe you did have a brief foray into tech leadership and people management using some of those skills. Can you talk to us about that?

Allison: Yeah, so this is when I was at Uber. So I was the tech lead of simulation at that point. But as part of the growth, there were a lot of reorgs, as you can imagine. And what happened at one point was that we didn't have an engineering manager for quite a while

So at that point, they asked me if I wanted to step in to do the management of the team, and I was like, okay, sure, I'll give it a shot. And I think generally what I feel, and some advice I give to my mentees, is you don't really know if you would like management until you've really tried it.

So to me, this was my opportunity that came along for me to kind of get a taste of it. So my experience with people management then was that, firstly, it's a lot of meetings.

I'm the kind of person that I really enjoy spending my day just working on code.

If I can do that all day every day, that's the perfect day. What I found, switching to doing some management, is that most of my days now became filled with meetings, just meetings with people from across different teams, figure out what are the goals, what are the timelines, what should we build, things like that. So important meetings, but still takes a lot of time. And to the point that I realized that I wasn't quite enjoying my job really nearly as much.

So I went to talk to someone else on a different team that had a similar—he was also a tech lead that moved to becoming a manager. So then I asked him, do you have any advice? And what he told me was that he would block out a day a week that he could have no meetings on that day, and then just focus on coding.

So that's what I did. I blocked out Fridays, Friday became my day to do coding, and after just a very short while, I noticed that of the entire week, Friday was my favorite day of the week. So then I realized maybe management isn't quite for me. If what I'm enjoying is all the non-management stuff, then really I should just stick to a role that is focused more on the technical side and leave the management to someone else.

So to me, that kind of gave me the experience that I want to focus on tech leadership and less on people management. That being said, right now at DoorDash, I am actually a TLM, but luckily is’s a very small team, and I think I made it clear to my manager that if our team grows to a certain size, we have to hire someone to do the management because I don't want to manage a large team. I want to have lots of time doing my coding, which is something I can still do in my current role.

Cathy: It sounds like you're in a great position now. So now that we know what a senior plus staff engineer does, we've talked about some of the soft skills and tech lead management alternative. So what are the strategies that we know that we can give advice for the listeners on this call? So this is for AJ. What advice would you give to senior engineers who aspire to reach higher levels in their careers, and what steps can they take to position themselves for success?

AJ: I think first and foremost, I would say be a person who takes ownership. Really lean into taking ownership of your work, both in terms of the creative, artistic architectural aspect of coding, but also own your mistakes. Be fully transparent, be honest, and fix them fully.

I think a lot of us, especially when we're new, we kind of don't want people to know that we made a mistake or we want to seem perfect, but you end up being more trustworthy and more reliable when people know that you're going to own it, that you're going to clean it up, you're going to fix it, make it better. Then higher-up people start to lean on you more, and they start to trust that your work is going to be complete.

As opposed to someone who tries to blame some situation or some team or come up with excuses, just own it. I broke it, I'm going to fix it. It's done. It's less painful than you think.

The second thing I would say is to look for the holes, look for the issues. So our platform lead on Android, Sha Sha, she usually says to people in their first six months, to kind of find the bugs and call them out really loudly because after about six months, you get used to broken things a little bit. You're just like, okay, I'm just going to refresh every time.

And you kind of don't really realize that you've been skimping over this major issue. Whatever it is, something doesn't work well, or it takes five days to do something that should take two days, or you have to talk to three different teams to get approval for something.

Whatever it is, look for these things, and they could be small, they could be large, but try to fix things that are outside of your own scope, your own team. Try to fix platform-level, org-level, app-level, company-level issues. And when you're looking for these things, find ways to map them to your team's OKR.

So there was a time at Pinterest where we were building these one-off UIs, and they were crashing and breaking the apps, and these backend teams were adding things, and it was just constantly bad. And I'm like, okay, let's build a system to automatically insert these things and automatically log them and automatically check that it's not going to crash the app.

And that saved...it would take maybe two months to build something, and that brought it down to two weeks. And that's something that maybe no one would've agreed to let me do if I didn't say, Hey, we're going to increase velocity, we're going to be able to push out more code, we're going to make things better. And then they're like, all right, go build your thing, let you do it. But I think finding something that is outside of your daily scope and really solving a major issue for the company is something that will really take you from senior level to staff level and really gain you that recognition that you need to be seen across the company.

Cathy: So thank you very much. Ei-Nyung, can you talk about mentorship? And we didn't talk about this before, but what about sponsorship as well?

Ei-Nyung: Yeah, so sponsorship is the most, it's the best tool. And for people who don't know the difference between sponsorship and mentorship is sponsorship is actually creating opportunities for people to help lift them up. So, for instance, if I'm the tech lead or if someone wants me to be a tech lead of a project, then I could say, well, what about Allison instead, because I already have this other thing that I'm going to work on.

In this example scenario, Allison has never been a tech lead, but Allison has shown a lot of promise. I've been bringing up Allison's name all this time. Or if you're someone at a higher level, like a manager or a VP or a CTO, then you have that direct power to sponsor individuals so that they can show that they can punch above their weight.

But mentorship is, you don't have power, you're giving advice, you're giving coaching, you're transferring skillsets, sometimes. You can teach them skillsets in order to be able to help them advance. So one of the things that I'm really proud of that I did at Slack was that I started two recurring mentorship programs. One for front-end and one for engineers that are people of color.

And because the thing is that I remember the first time someone reached out to me asking for some sort of help and advice on some sort of tech spec that we're writing. They're like, Hey, you know, does this read okay? Is this fulfilling all the technical things? And I sat with them, and I was so flattered, and I gave them all this advice, but I also knew that there were more people that were actually better than me to give them feedback on it, but they hadn't gone to them because they didn't feel approachable.

That's why I started these mentorship programs, because I was like, oh, this person's getting the help they need, but the people that they wanted to talk to didn't seem accessible. I seemed accessible. I'm like, "Awesome."

So I set up these programs because I saw the value to them growing, and them being able to have the courage to reach out, but also, I was able to reach out to other people and get advice.

So if you want to be a staff engineer, the best place to go to is the staff engineers at your company and be like, Hey, staff engineer, what are you doing that's different from when you—sure, we can talk all day to you, but those people actually went through the process at your specific company and understand what their requirements are. And you can be like, what is your day-to-day job like? Can I shadow you for some of these meetings?

And often the answer would be yes, but also if you want to build some of your skills as well, even if you don't feel like you're qualified, you could mentor a junior engineer, you can mentor an intern, you can mentor someone who is one step or two steps behind you and you then will actually gain in your skillset too, not just a soft/core/foundational skills, but when you explain a technical concept to someone, you become better at it.

When you critique someone else's tech spec, you know how to write yours better. Because you're like, well, I don't answer those questions either. What about that risk analysis, right?

So really lean into mentorship, providing your own, but also reach out to the random software engineer in your company that you're like, oh, they're so cool. I wish I knew as much as they did and just be like, Hey, can we have a little chat? Because I think you're awesome and I want to be an engineer like you, and you'll make their whole month, their whole career.

Cathy: I do think that that's totally right. It is definitely good to have mentors at your level, but your network should have people at all levels. Like that junior engineer today might be on that team that you really want to be on in six months. And again, if you're at the same level but on another team, that doesn't mean that you can't learn from that person.

So you talked about sponsorship, mentorship, Allison, can you talk about being your own self-advocate?

Allison: Yeah, I think what you might notice, going from senior to staff is in terms of who should know about your work. I think when you are a senior engineer, typically your EM works quite closely. They see all your technique, and they kind of have a good sense of what exactly you're doing.

When you go to the staff level, or if you are looking to get promoted to the staff level, I think one of the big things is you actually want people outside your team to kind of know who you are, what you're doing, and kind of advocate for you.

So some of the ways that, I think Cathy mentioned this as well, sending emails out about what your team does or what you've done. I think this helps you gain visibility within the org in general.

And also, I think sometimes some companies have things like internal tech talks. I think these are actually very useful opportunities, both for you to practice giving a presentation and also to increase your visibility for people to know that this person actually knows what she's doing, especially in this area and so on, so that in the future when they're thinking about this particular area or something that's somewhat related, they're like, oh yeah, I think I heard Allison talk about something like this before. So this is someone that I should go to.

And when it comes to... in terms of promotions, I think usually one of the things we want is for our work to speak for itself. And I think that's something that is a general mindset, but unfortunately, that's not always true. I think a lot of times we do the work, we think that, oh, everyone will realize how wonderful what I built is, but they don't.

So you want to have some way to actually show it. Having metrics and all that is great if you have that. Another way that I found very effective is, instead of you talking about what you've done, if you have someone on a different team talk about what you've done, that adds a lot more weight, right?

Because, for example, you build this feature you think is great. If one of the users then tells your manager or says something about, oh, this feature that Allison built, Allison's team built, this will really help me in my day-to-day. That means a lot more, especially in terms of promotions.

Cathy: That's true. Thank you so much. That's the panel questions that we have, but now it's the opportunity for those on the call to ask questions. You can raise your hand, you can put it in the chat, you can put it in the question and answer.

Actually, I do have a question, and probably, I don't know which of our panelists can answer it most, but Ei-Nyuung kind of hinted and at this is, those soft skills are more important as you get more advanced, if you work at a company that recognizes that.

So sometimes I feel that we have a leveling framework that includes all of these great things, that includes mentoring and includes non-technical skills. And at the end of the day, I think that the technical skills are still seen as more important, and those engineers that are highly technical but can't attend a meeting and participate in a meeting are kind of rewarded over those that spend all their time mentoring or interviewing. Ei-Nyung, do you have anything?

Ei-Nyung: Yeah, so interestingly enough, so like I said, one of the most proud things I was doing this mentorship program, it impacted hundreds of people. It was over 60% participation rate in the front-end organization. And actually, I think the first year was like 85%. It was incredible and the outcomes were great, but when it came time for promotions, it would always be like, well, what I'm like, I've been doing the technical work that to me is, at this point in my career, just easy. So I don't talk about it, I didn't do anything. I don't promote it.

So I was like, I guess I have to start promoting myself, just like all three of you talked about. And I think that's where I had to get better at being the one that delivered. I always wanted to be the junior person, I would like you to deliver to these, the other person, I want you to go there to represent the team, because that's the leader that I want to be.

But I also realized that if I get to a higher level at a place like Slack, then I'll get more influence. So I was like, all right, I want to play the game by the scoreboard that they have, the score sheet they have, and I was doing all this other stuff still, but I continued to push on the technical side and make them more public and be like, I'm going to give an all-company demo and just keep talking about in public spaces.

And eventually, when I got my senior staff promotion, they wrote up my bio for doing the promotion, and they put that Iled these large technical projects first, and then also responsible for these mentorship things. I had them rewrite it. I said, put the mentorship on top because that's what I value, and I wanted to push the narrative that, even though it wasn't true yet, that this is of importance to the organization, and that one day you can potentially get promoted on doing those things. Even though I kind of gamed it where I was like, that's what I want the message to be.

Cathy: Sometimes you have to play the game and then also do what you believe in.

Okay, so we have a few questions, and if any of the people on the panel want to answer, just let me know. This is from Tina Wright, and she said, do you think it's required to have external visibility influence to reach principal levels? So, do you reach principal and then get the visibility, or do you get the visibility to reach principal?

Allison: I'll jump it a little bit. So I'm not principal yet, so this is just what I've observed, I guess. I think it depends on what you mean by external. External to your team or external to the company, but I think having visibility outside your team is pretty important. I would even go so far as to say, even before the principal level, external visibility, for example, across companies, like being known as a person who does X across the industry, I think that is probably less important. I think it doesn't hurt, but I wouldn't say it's a critical requirement.

Ei-Nyung: And if I can add that to that a little bit at a place like Slack, where by the time I left it had, I think, over a thousand engineers, it was required to have external-to-your-team visibility to reach principal levels.

And by that I mean that even for staff and senior staff, the requirement was that you were not just impacting your team, and you were not just impacting your team with the code that you wrote. One of the things that got me to senior staff was that I did a revamp, a re-architecture of the internationalization and localization framework, which touched every aspect of our product, and not just a small team thing.

So it touched the workflow of every engineer and potentially shortened the times for all of those people. So it was important to have projects in my pocket that were like, you can see the influence it had throughout the company that impacted whatever, like 80% of all engineers that it had blah, blah, blah.

Because at a big company, you're not going to get to principal unless your projects have that level of work. And also, even if I stayed at Slack, I was never going to try to go for principal because even as a senior staff, I was like, I want to give away my projects. I want to be the hands behind the curtain. I want to be the supporter behind the curtain, and I know that I have to have my name as the lead on these big-picture projects to get to principal. And I was like, I looked at that requirement, and I was like, I don't actually want it.

So I think that you do have to have your name and your face behind these very large visible projects in order to get to principal, but when I was principal at my small company of six people, no.

Cathy: Thank you so much. So we have two questions. I don't know if we have time for both of them, and there's another one there. What should we do? Take one more based on time or....

Ei-Nyung: Yeah, maybe one that AJ wants to answer.

Cathy: Okay. AJ, why don't you pick one of those questions?

AJ: I like, what do you think was key to your advancement to a staff role? So, a big part of it was letting other people know who I was and what kind of engineer I was trying to be.

So I made a decision, like an active decision, on what kind of engineer I wanted to be. So there's people who are very fast or people who write really complicated things. And I wanted to be the person who was unblockable and delivered quality code.

I was just going to be the quality person. Because I was on Android and we had a lot of issues. We didn't have all the nice features of iOS, and so I was going to make my system as sturdy and clean as possible, and I sort of created that as my brand, and I sort of marketed that brand to my manager and to people that I worked with.

And I was then able to get projects that were larger and required foundational changes and structural things that were beyond just making a nice feature. And I think once I was able to build my own system that I got different teams to adopt and use, then I had established a brand as a person who delivered quality code and created systems that would make everyone else's life easier.

So what was key was, I guess, really marketing myself, deciding my brand, and then putting that into action and having impact across the company. If you don't kind of make those decisions early on, I think you run the risk of getting stuck into just doing what you're told, and that's the wrong thing. Don't just do what you're told. I mean, do what you're told, but do more than that.

Do what you want to do and make sure that it's something you enjoy doing, that you get value from, so that way you don't burn out quickly, and you do end up having a large-scale impact such that the top-level people are asking, are you using AJ's system to build this? And that's when you know that you've done well.

Cathy: Thank you so much, AJ, and I just saw Karen put this in the chat. WEST now has a podcast that's called Engineer Your Career, and AJ and [inaudible] were the first people on that, and I just listened to that. So if you'd like to hear more from AJ, she is on podcast episode one. Thank you to all our panelists and all of those that are listening in today.

Karen has a poll that she would like to share with all of us, but...

Karen: I do have a poll, so let me go ahead and launch it. This is super helpful for us to better understand how we were able to serve you through this session, and also what your main takeaways were from hearing from Kathy and Allison and Ei-Nyung.

Ei-Nyung: Yeah, if I could just add, sorry, I always say this, you can totally add me on LinkedIn if you'd like, but if you don't add a message, I'm the only Ei-Nyung Choi there, so you'll find me. But if you don't add a message, I'm going to assume you're a bot or spam. So I'm definitely not going to accept your connection unless there's even just a small message. So please let me know how we met, and then if you are here, I will definitely accept it. Thank you. And this was so much fun. Thank you all.

Allison: And I'll echo what Ei-Nyung said. Yes, if you'd like to add me, do add a note, too. Thank you.

Karen: Yeah, I think that's great. Networking practice in general is sharing in the little message of how you met, especially if you met them from a conference or a recent event, it helps them be able to put you into context, helps you to be able to put them into context as well.

Later, as you're looking through your LinkedIn connections, you're like, how do I know all these people? You can take a look at your messages like, oh, I met them through here. Okay, cool. I know what I can talk to them about. So yeah.