YouTube Deep SummaryYouTube Deep Summary

Star Extract content that makes a tangible impact on your life

Video thumbnail

Getting To Staff (IC6) at FAANG Panel (Full, Sept 2023)

Ryan Peterman • 74:20 minutes • Published 2024-07-08 • YouTube

🤖 AI-Generated Summary:

The Journey to Becoming a Staff Engineer in Big Tech: Insights and Advice from Industry Experts

Becoming a staff engineer at a major tech company is a significant milestone in a software engineer’s career. It represents a shift from being an individual contributor focused primarily on coding to a senior technical leader who influences multiple teams and drives large-scale impact across an organization. Recently, a panel of experienced engineers from companies like Google, Meta, Amazon, Airbnb, Activision, and Netflix shared their journeys, challenges, and advice on reaching this coveted level. Here’s a comprehensive summary of their insights and practical tips to help you navigate your own path to staff engineering.


Understanding the Staff Engineer Role

  • What is a Staff Engineer?
    Staff engineer is a senior individual contributor (IC) role above the senior engineer level, recognized as a leader who drives projects with wide-reaching impact. Titles vary across companies (e.g., L6 at Google, E6 at Meta), but the core expectation is consistent: the ability to influence across multiple teams or even company-wide initiatives.

  • Scope and Influence:
    Unlike previous levels, staff engineers are expected not only to deliver technically but also to lead, coordinate, and influence others. This often means managing complex projects, mentoring others, and aligning teams toward common goals.


Paths and Projects That Lead to Promotion

  • Diverse Journeys:
    Panelists shared varied experiences—some got promoted internally after years, others made lateral moves to new companies where their work was recognized at higher levels. Both internal promotions and strategic moves can be effective.

  • Key Project Characteristics:

  • Large Impact: Projects that solved critical company problems or created infrastructure/tools used by many engineers.
  • Leadership and Collaboration: Success involved coordinating multiple engineers, gaining buy-in from stakeholders, and leading execution rather than solo coding.
  • Technical Complexity + Communication: Delivering technically challenging solutions while effectively communicating their value across technical and non-technical audiences.
  • Multiplicative Impact: Building scalable solutions or platforms that enable other engineers to work more efficiently, amplifying your influence.

  • Examples:

  • Building a comprehensive graph database to map microservices and their interdependencies, addressing a major security challenge.
  • Leading a project that reduced video processing costs by 94% through cross-team collaboration.
  • Developing internal debugging tools that saved thousands of engineering hours across teams.
  • Modernizing product architecture to enable new capabilities and improve reliability.

Balancing Technical Execution and Leadership

  • Delegation vs. Doing:
    Staff engineers must find the right balance between hands-on coding and leading others. This balance varies by individual, team dynamics, and project needs. Some weeks may be more execution-heavy, others more leadership-focused.

  • Leading by Example:
    Leading technically can mean diving deep into critical problems, pairing with junior engineers, and ensuring quality, while also mentoring and guiding the team.

  • Manager Feedback:
    Regular, honest conversations with your manager about how you spend your time and your leadership contributions are crucial to find the right balance.


Finding and Creating Scope

  • Don’t “Invent” Scope Out of Thin Air:
    Instead of searching randomly for something to work on, discover the pressing problems that are holding your team or company back. These are often “hidden” landmines others avoid or overlook.

  • Be the Person Who Raises Difficult Issues:
    Taking initiative to address problematic legacy systems or technical debt—even if it’s unpopular—can demonstrate leadership and vision.

  • Understand Business Needs:
    Scope should align with the company’s priorities and deliver tangible business value.


Building Relationships and Visibility

  • Relationship Building is Key:
    Success at staff level depends heavily on who you know and how well they know your work. Build genuine relationships across teams, managers, and leadership.

  • Be Visible:
    Remote work makes this harder, so be intentional about sharing your work and engaging socially. Use presentations, write-ups, and informal chats to keep others informed.

  • Mentorship:
    Mentor others and seek mentorship for yourself. This helps grow your network and builds advocates who can support your promotion.

  • Communication Skills:
    Tailor your communication based on your audience—technical deep-dives for engineers, high-level impact for executives and non-technical stakeholders. Practice clear, concise messaging.

  • Reframe “Self-Promotion” as Sharing Value:
    Communicating your work is not bragging; it's about showing how your contributions benefit others and improve the team or company.


Heuristics for Choosing Projects and Teams to Maximize Promotion Chances

  • Look for High-Impact Problems:
    Seek projects that affect multiple teams or critical business metrics.

  • Infrastructure and Tooling Often Offer More Leverage:
    Building core platforms or infrastructure can amplify your impact across many engineers and products.

  • Understand Your Company's Promotion Process:
    Engage with senior leaders or those on promotion committees to learn what projects and behaviors are valued.

  • Maintain a Portfolio of Work:
    Multiple projects demonstrating leadership, impact, and technical excellence over time are more convincing than a single big project.

  • Relationship with Your Manager:
    A good manager relationship is fundamental. They can advocate for you and guide you toward the right opportunities.


Advice for Staff Engineers Seeking to Exceed Expectations

  • Scale Up Your Impact:
    Move from influencing your immediate team to broader groups or company-wide initiatives.

  • Balance Delivery and Strategic Leadership:
    Deliver high-quality projects while contributing to long-term architecture and best practices.

  • Keep Developing Your Leadership Skills:
    Continue mentoring, advocating for your team, and shaping technical strategy.


Resources for Improving Communication and Mentorship

  • Know Your Audience:
    Research who you’re communicating with and tailor your message accordingly.

  • Practice Conciseness and Clarity:
    Learn to convey complex ideas succinctly, which is highly valued in leadership.

  • Build Empathy:
    Understand stakeholders’ goals and constraints to foster better collaboration.

  • Seek Mentorship Actively:
    Don’t wait for mentors to come to you; reach out and build those connections.


Final Thoughts and Takeaways

  • Promotion to staff engineer is not a race; everyone’s timeline is different.
  • Focus on solving real, impactful problems and building relationships with your peers and leaders.
  • Communicate your work effectively to gain visibility and build your personal brand within the company.
  • Balance technical excellence with leadership and collaboration to maximize your influence.
  • Understand and navigate your company’s promotion process proactively.

Connect with the Panelists and Continue Learning

Many panelists share their knowledge on platforms like LinkedIn, Substack, and Twitter, providing ongoing advice on engineering career growth and technical leadership. Engaging with their content can offer valuable perspectives and practical tips.


Conclusion

The journey to becoming a staff engineer is challenging but rewarding. It demands not only technical expertise but also leadership, communication, and strategic vision. By focusing on impactful projects, building strong relationships, and articulating your value clearly, you can position yourself for success at this senior level. Remember, it’s about making a difference not just through code but by enabling your teams and organization to thrive.


If you’re aiming for staff engineer, start by identifying the biggest challenges in your area, build relationships with key stakeholders, communicate your contributions effectively, and seek out opportunities that allow you to demonstrate leadership and impact across teams.


📝 Transcript (2023 entries):

we're here to talk about the journey to becoming a staff engineer in a large C company and so we'll go through our intros and talk about which companies we have experience in in just a minute but just to give some context I wanted to quickly share this diagram from levels FYI what does it mean to be a staff engineer staff engineer is a very senior level at these tech companies so typically you get to a senior level that's a terminal level of being an individual contributor an IC engineer and so that's what you can look at here which is senior s L5 at Google E5 at Facebook S3 at Amazon the level after that is typically what we're referring to when we talk about staff engineering so staff s at Google is L6 E6 at Facebook at Amazon interestingly there's no notion there's no vocabulary for a staff engineer the level after senior is principal so keep that in mind we're going to we talk about this from the perspective of Staff engineer but the vocabulary does differ based off of what company you're at but generally the idea of staff is that you have influence and scope across multiple teams and perhaps even companywide so it is a very challenging level to perform at and I think it'll be really valuable to hear from everyone here about how they achieve that and you know what advice they would have for everyone here so to kick off the intros do anyone want to start maybe Lee do you want to kick us off so I'm Lee mck I have been working in some capacity in software engineering since 2004 that's when I finished an undergraduate degree so worked at some smaller companies for a while did Healthcare informatics did nonprofit fundraising stuff and then starting in 2012 worked at Amazon worked as an sd2 there for a lot of the time moved into people management got promoted L6 which is equivalent to senior engineer as a manager and then a couple of years ago left Amazon joined it was then Facebook became meta while I was there as an L6 engineer staff they don't like things but same as staff level elsewhere didn't have a super fun time didn't go great so about a year and a half ago I moved over to Google in the same capacity working as an IC as a staff engineer um I've worked on the chat product and now I'm over on Gmail working on notifications I'm sure we'll give this General disclaimer but I'm not speaking on behalf of Google no one is speaking on behalf of their employers so my name is Ryan Peterman I'm a Staff engineer at meta and my prior experience is that I graduated from utila in 2017 I worked in a small satellite office at Amazon for around eight months or so and then I started I've met a at the new grad level and since then I got promoted to staff and a few years and I'm still at meta right now working on the Instagram product I'm just gonna Note new College hire is L3 there so that is three promotions in five years so just pretty significant anyway Ryan you pick next awesome yeah that's exactly right all three or ic3 or E3 for the newr level I'll pass it to Kari hey thanks Ken hey everyone my name is Carly I currently work at Activision same thing as Le I'm speaking on behalf of Activision but I am currently a senior manager but I also still hold an IC title which is a fun time so I do both my IC title is equivalent to staff we call it like lead engineer yeah I guess I graduated I finished grad school in 2017 moved up from Junior data scientist fairly quickly started at Activision at the senior level actually and then took about two years to get up to lead so it's been a fun ride making video games I love it I work in security so there's a lot that I can't answer about specifics about my job but I'm happy to give as many examples as I can not going to tell us how to write a around oh that would be great all right Zach All right so for me I started my journey in big Tech at Facebook back when it was Facebook back in 2016 doing like data engineering kind of stuff and I think I'm one of the ones here I think me and Lee I guess are the ones who like did the journey like through a bunch of hops but then I went to Netflix I feel like Netflix is where I got to staff but like back then Netflix didn't have staff everyone was just a senior engineer but what I was working on there was really crazy I also worked in security like Carly when I worked at Netflix and then I got the official staff title when I jumped to Airbnb and there I worked for two years I recently left I left about six months ago now I'm doing like content full-time but it's a fun fun gig I'm been liking it yeah rul you're next yeah all right I'm Rahul I am here at the Bay Area unlike everyone here other than Zach I do speak for my employer because my employer is me taro I'm very transparent and open happy to be open about what was my experience like at meta and Pinterest which is where I work and also my kind of perspective as a somewhat of Outsider now looking at these big tech company but I run Taro my experience in terms of big Tech is I was at meta or Facebook for four and a half years where which is where I went from senior to staff engineer prior of that I was at Pinterest for two and a half years and fun fact there is that I actually got rejected I got rejected for promotion twice at at Pinterest so I feel like I have certainly been on both sides of as a manager and I I've been on both sides of getting promoted and i' also been rejected multiple times from promotion so happy to talk about that too prior to Pinterest I was at a startup which got acquired by Pinterest so that's another fun story but yeah I feel like we have tons of really smart people here and really eager to to dive in I just chime in like Rahul just mentioned not getting promoted at Amazon I've tried to get promoted to senior sd3 three times and failed all of them the first try to get to L6 as a manager failed that happens and also like talking to the people on this panel like a lot of people grew through these levels super fast some changing companies some being super successful within their company whereas like I was 17 years 16 years into my career or something when I made it to this level so it's not a race certainly like if you are succeeding and progressing through the levels off but I just want to also set the expectation that it's not like what you are hearing from some people here and maybe all of us might not be your path so don't freak out if you've missed a senior promo the first try like that's not a weird thing so anyway yeah no I appreciate that input we do have a lot of great perspective here old young not old you're not old more mature perspective and younger perspective and different companies and so on so I'm super excited here how it's going to work we have a couple questions that we think will be broadly interesting to the 225 of you here and then after we go through a couple of those I think that'll probably take between 45 minutes or an hour then at the end we will do open question so you can raise your hand and we'll call on you and you can unmute okay so to get started the first question that um we have is tell us what the main project or perhaps multiple projects that got you promoted to the staff level into you anyone want to start here I I'll go first I think so for me I think there was two things there because I was at Netflix and the titles that everyone was just like senior but I felt like I had staff responsibilities and then I got promoted by hopping company so I think it was the Netflix project that Airbnb was like okay this guy's staff level so I'm gonna even though it wasn't a promoe I never really got promoted there I got hired at company but anyways going from that I worked on this project at Netflix called asset inventory and Netflix is famous for having kind of microservice architecture and one of the things that's awesome about microservices is you have this individual ownership one of the things that's terrible about microservices is security because then it's oh instead of having one app to hack now there's 3,000 or 4,000 or 5,000 apps to hack that each could have their own different vulnerabilities and code based problems and that was one of the big nightmares that Netflix was trying to figure out and the thing that I worked on there was like I built this graph database that described all of the applications and code bases and data sets and employees at the company and how they're all connected and how they all interact with one another and the relationships between them it's like this big ass knowledge graph of everything and yeah I worked on that for two years and that was a project was really intense but yeah I would say that was essentially what I worked on that was like the thing that at least Airbnb saw I was like yeah that's staff level yeah so I'll hop been next I also wasn't promoted I consider it's promoting yourself when you've done the work and you can convince someone someone else that you're there and get hired that was the direction I went but I had been managing people for 3 years at Amazon when I switched over to Facebook and at and a staff level and so what I would say is like doing the technical work was not enough like being in a position to lead people and know how to do that both as an IC and as a people manager I think is something that some people Overlook they there are times where people are like I but I delivered this huge project and it had all this technical complexity that's who else worked on it or how did you plan that and how did you parallelize those work streams how did you like take risk prevention to make sure the hardest thing wasn't the last thing to get done and delay the project and people are like I didn't have to I'm indiv individually a genius and I delivered it all myself and it's yeah that's not necessarily meaning you're there yet managing people and learning to manage projects and work streams was a big part of it at Amazon but before that a lot of the work that I had done as an IC that I think put me in a position to speak about the technical complexity when getting these other jobs um mostly had to do with Android internals um I was working on an app I wasn't working on Android itself I happen to be working on something that is part of Google Play services which is part of Android right now but in any event at the time it was just like we have these complicated apps and they don't fit essentially into the amount of it was a method limit I don't know how familiar people are but I had to write something that had a custom class loader to allow us to use multiple executable files in an Android application before Google started supporting that and put out something that did that and that was like the most technically complex thing that I had to do to allow Amazon video which was what I was working on it's Prime video now and then like combination apps with the shopping app and the App Store and video like all the things in them like it wouldn't work with just one and we weren't going to tell Engineers like ah put all the functionality into one big method and have a switch statement on the like operation or something like we didn't want people to code dumb because of this technical limitation so like overcoming that and not just like having a solution but making it work and delivering that that app that could continue to be extended was probably the like biggest Tech project I'll kick it to Ryan yeah and you mentioned an interesting thing which is being brilliant and shipping everything yourself versus working in a team for the staff level this is one of the first levels where the Baseline expectation is that you influence others to get large undertakings that actually built into the expectations of these levels is that you're a leader and that you're influencing people because software is inherently collaborative and so about the project that got me promoted this work was a large efficiency project it made video processing at Instagram significantly cheaper 94% cheaper for some of the basic encodings that we produce and I think a large part of what made this project staff level and helped me get promoted was that I created this scope which meant that I went and I found it I convinced people was a good idea I got Buy in and then I led the execution on it and going back to if I executed on it personally I would step in for the most critical components that added risk to the project but in large part this project was being executed on by several engineers and I was bleeding and doing the code review to make sure everything came together in the end it's not just me that worked on this project there's a lot of other people that came together to make this happen but I think the key here that makes it staff level is like the leadership and convincing everyone that it's a good idea and going for um so I'll pass it to Carly hi interesting hearing all of you talk about your Journeys because I've been thinking about this a lot with my team as well and it seems like what it takes to get to the next level like everyone has already said this is not just being technically brilliant right it really comes down to in my opinion in wars and Trust for me I was obviously working on a security project that's about as in detailed that go but I was I had taken ownership of a decent of a technical piece of this project but what I think and I had also I had hired some one thought I had a direct report under me and we were both kind of attacking this problem from multiple different angles I think what set me apart and what led to my promotion to staff was a couple of different things number one I can actually pinpoint it back to a presentation that I gave to an executive leader in our company based on some work that I had done as the findings that I had uncovered and I think being able to speak technically to an audience that might not necessarily want to sit in an engineering meeting was something that really set me apart from some of the other people that they deal with who are working on highly technical complicated problems and just coming across as a trusted collaborator and so out of that meeting I had an opportunity to switch and so I didn't change companies but I did do an internal move to get to staff and that's how I landed where I'm at now and so I was actually interviewing or presenting to someone in executive leadership and as well as our CTO and he offered me a job working for him after that presentation and so we were able to make that work it was really exciting for me um because it opened up a lot more doors for me I don't say that to say that's normal you're not going to go into the office of like Zuckerberg and kicked down the door be like oh staff now but at the same time you should be prepared at a moment's notice be able to speak eloquently to your work exactly like what Lee said you should know your numbers you should be able to recite like the impact that you've had and you need to be able to do this to Technical and non-technical audiences and oftentimes the people who are making the decisions about whether or not you're ready to move to the next level are both so it's not just the fact that you can I don't know do some crazy algorithm if that you can actually speak to it to a Layman make them understand and the value in your work and I think that's where you tip yourself over the Ed and then of course there's all collaborative nature of these projects right like it's not just enough to be like oh I built a machine learning model right like in my case it needs to be larger scale collaborative across a couple different business units something that obviously speaks to a pain point of the business right I think everyone here universally just described something that was problematic for their company if you can solve those problems like you're going to be cheat up for Success all right are you gonna be answering or I'll time in here just because I feel like I have a couple things that uh I think might be helpful to people and then for the future questions just in the interest of throughput we don't all have to answer you just whoever wants to they can if they have something to say they can answer but for this one I did want to add to the great answers we already heard I there were two projects that got me promoted to stff engineer at meta the first was actually an internal tool that helped the debug ability of the product I was working on and I was able to quantify that it saved literally thousands of hours of engineering time throughout the course of the year and it became effectiv like a platform where other Engineers could add in their own debug ability metrics their own debug ability tooling into this kind of architecture platform I built out so it was really creating scope and allowing other people to plug in that's a really powerful way to have multiplicative impact right and then on top of that I had another project which was what I would consider my main project which is re architecting something about the product I was working so a calling architecture I was modernizing it to a different team that had a set of API and that's actually one of the lessons I wanted to share is that one way to think about getting promoted to these very high levels is to think about a portfolio of bets that you're making so if you just have one project that you're so hellbent on delivering that's a good thing for the most part but in a big tech company there are a lot of things that frankly are not in your control and so having one main project is what I did along with one project which was more of a internal tool or something that I had a lot more control over that worked out really well because in both of them in tandem led to a huge amount of impact right and you when you're blocked on one you can work on the other that's one thing I wanted to take away or share as a takeaway is that you can actually think about having maybe two or three projects probably not 10 right you want to have maybe two projects that you can kind of balance between the other comment I wanted to make here is like I think Zach you mentioned this right that you got hired in as a staff engineer at Airbnb and that's another thing that's worth calling out is that in in addition to working hard and impressing all of your colleagues and having enough impact at your company another core ingredient of getting promoted to a very senior level is there needs to be sufficient business need for that right there needs to be scope that you can fill in to be a staff engineer and frankly at some companies which are not growing quickly they're stagnant there may not be that scope and so I think a lot of us are talking here about getting promoted internally I think that's certainly a really uh good thing and we should all drive for that but keep in mind that there's also an opportunity to get promoted simply by moving to a company where there's a need for your skill set yeah by the way on the portfolio of bet that's a really interesting point if you look at any promo packet it is a track record of multiple halves worth of work so it's not usually you're doing great and all of a sudden you have a staff project and boom you get promoted you've usually been doing it for a while you probably have some sort of track record so that when your packet goes to the promo committee people are aware of your name and you've been doing near staff or at staff level work for some time yeah that is a great call out one thing I just want to mention I dropped a link similar to what Ryan did earlier I dropped a link for uh video that I put on Taro actually about a case study for my promotion story so if that's interesting to folks check that out unless there's anything else to add here I'll move on to the next question yeah I think one thing I just want to add real quick about the one of the things you said rul that I love is multiplicative impact so I like to think of if you're a staff engineer at least like when I've been working as a staff engineer like I think of creating impact in two directions you have like your vertical impact of the direct impact that you want to have on the business and then you have a horizontal impact which is how can I enable my team to move quicker and how can I enable what about the development process sucks and how can we make the development process better and thinking about not just what we are building but how we are building it and if you can do the if you can solve both those how problems and the what problems that's when people are like wow this guy is really changing things and changing how things work I know for me that was like one of the other projects I worked on that Netflix was I decided I was like I want to learn some groovy script so I can learn how to cut deploy times down so then on my team I was able to write this groovy script that cut down the jar file that we deployed for our pipelines and it removed all the unused dependencies and it made it so that depending on the project they either saved 1 to seven minutes per deploy which saved on average like an engineer is going to deploy probably five or six times a day when they're testing a pipeline so it saves them like 30 minutes to an hour a day that's a lot of like time that we get back if you and then if you scale that out then it's like more a matter of adoption than it is of technical Excellence because then all you have to do is scale that out and get more people to adopt it and then you're like see oh now I have a hundred Engineers working and using this and then it's okay wow that's freaking that's how you can really also get a lot of big impact as well yeah actually 66 people with a 16% increase is a 10x engineer like you don't do 10x yourself 1% for a thousand people 10% for 100 that is where you actually make that kind of impact in my opinion yeah definitely and I've studied some Engineers that are the L9 level which is three levels higher than we're discussing now these people are Legend and looked at the things that they do and often times they are just making compounding improvements that make all of meta faster and so imagine you make the tooling that everyone's using 10% better and there's five figures worth of Engineers you're that's absurd impact this definitely scills if you're thinking even past staff level making other people faster in large organization that's a great segue actually into a question that Brian had and was a question I ask as well Brian wrote for a staff engineer they often will create or find their own scope or problem but at the senior level one level below you still need to do the actual work of coding or implementing something so how do you do both I think the question if I could rephrase it is how do you think about balancing the art of delegating delegating work versus doing it yourself I'll jump in here I think that I this reminds me a lot of conversations I had with my manager Jen when I worked at Airbnb where each week we would talk about are you managing enough are you delegating enough are you like working are you coding enough and like to make sure that I was contributing in each bucket enough because I'm definitely someone who likes to just nerd out and just like code Scala all day and just get into the nitty-gritty details of wow just really get geeking out but then I do that I've definitely been in that position where I do that to the detriment of my team and that's like a problem where I know I need to be leaning more into leadership those weeks and that's where having at least for me having just very Frank conversations with my manager about how I'm spending my time makes me like and then really taking her feedback in and understanding like oh like I am not leading enough and I need to be doing more leadership at least for me that's the bias U depending on the staff engineer you might have one who's if if a staff engineer is an engineer who came from management they might have the bias the other way around where they're like peopling too much and they're not drisking uh the technicals enough so like you got you really want to learn your own biases depending on your background and if you know your own biases are then you can try to adjust for them to get into that kind of sweet spot and that might not be 50/50 each week you might not be like I did two and a half days of leadership and two and a half days of coding some weeks you might do four days of coding in one day of leadership and it might be the other way around another week it like it really depends on the balance that you're trying to look for but there's also like how you lead if you're doing deep technical work you might be leading by example you might need to be sharing that out more you might need to be pairing with some Junior people to be divvying up work as you dive into it it so they can follow some of the threads instead of you having to do it all yourself but like leading I this is one of the things that I said when I was like moving back and forth between IC and management was like am I leading from the front right now or am I leading from the back am I pointing people the direction they need to go or am I up front and finding it and sending them down the path with me and in terms of that I think that you like how you lead it it varies by team none of this stuff is globally applicable some teams you're like amongst peers that are all about the same level as you how you lead that team is way different than if it's all new grads and you're the only person that's been doing this for more than 20 minutes like how you lead yes getting input from your manager can be really helpful because they can be like yo you spent the last three weeks and you did get that 4% performance Improvement and that's cool but no one understands how you did it no one knows what's going on like you didn't tell anyone what tools you used and if you were hit by a bus tomorrow we wouldn't even get it committed so like you know how you do it is as or more important than what you do I think though true Le it makes me think of how I would manage zap which is actually a terrifying because I think we would either have way too much fun or kill each other but honestly I think about with someone with Zach's Talent right like he's obviously incredibly successful and have the technical depth that most people don't I would be remiss if I let him go deep technically every single day and no one really knows exactly what he's doing like the force multiplier for super like Zach will be if I can get him into the R&D and design if I can make sure that he has input in all of the big projects that are going on we understand Road mapap and we have someone there who's be like that's going to break that's going to get [ __ ] that's going to work and knowing being able to do that quickly and then someone else can get into the deep into the schol and or depending on what it is and he might need to step in in Hell something really complicated but I think that if I were in a position that's what I would want from him because that where he think that would be the most effective use of his time but it's hard because you also don't want to be in meaningful day so it's a definite balance something you have to talk to your manager about something that came out of what Carly just said is one of the most powerful tools is asking the right question at the right time you being in the right place to hear someone say that they're going to rearchitecturing that's not the right Focus we can put that behind a shim and we can deal with that later can be the difference between successful projects and failing projects if you don't have you know your senior most people involved in those discussions s they might call that out 3 or four months from now when you've already sunk like two or three Dev years into something and 20 minutes of their time could have prevented that so like where you are applying these I I don't call people resources but where you're applying these people time it can easily like you know if they miss a hallway conversation it can be costly they can't be everywhere all at once but knowing like this is going to be an important thing this design matters like we need eyes on it yeah I want to just add more on that CU I like it really that triggered my like beginning experience at Airbnb because when I started there they were like talking to me about we need to get these profitability numbers certified we need to do it that way and it was like that was like the stakeholders were really loud about that and I was new so I was like okay I trust you guys because when you're brand new at a company you have to lean into stakeholder requests until you get the lay of the land s and I realized after about six months there like listening to these stakeholders and then learning like more about and then I I finally got the courage enough to ask what is the fundamental difference if the if these numbers are certified or not and like the answer to that was like essentially nothing or there was like one day difference in delay and that didn't have any like really strong fundamental impact on the business whereas other things we could be working on would and so I actually told my manager at the time I was like I spent six months on that where we had like all the seniors and me working on this trying to get these numbers certified but it's a very complicated pipeline that was not going to happen and I was like yo this is like a diminishing return I don't think we're GNA like really get much value out of working on this longer and like trying to push this to the Finish Line even though the stakeholders were really loud about that and then I was like I think we should change to focus on other things that are going to have higher impact and if you can explain the impact of things like that can be awesome cuz sometimes that can also save you a lot of Dev headache like what Lee was saying is if you could just show people how to prioritize things then maybe you can work on things that you enjoy more too because those profitability metrics those freaking those things almost ended me at Airbnb so hard but like you and three people working on that probably for four months probably cost the company a million plus dollars exactly exactly salary not even like opportunity cost totally it's that's a sunk cost not and what was the opportunity that we gave up for that and that's a thing that I think is another big part about being a staff engineer is you need to be able to persuade and like convince and it's because it's up to you you're the leader here like you could you get to decide what to work on a lot of the time your manager leans on you to identify the impacts and identify what things should be worked on and it's also up to you to recognize like what shouldn't be worked on even if the stakeholders are loud about it even if even if there's a lot of people with a lot of opinions that think that this is the right thing to do so and you need to have that courage to tell people like no we're de we're depr prioritizing your thing even though I know you're going to be mad about it doesn't matter what it's not the highest priority now and I think that and being able to explain that thought process can be wonderful and it helps your cross functional Partners respect you more because if especially if you deprioritize their project but you don't have a clear line of reasoning for it then you're going to build a lot more mistrust and you're going to build a lot more kind of resentment potentially like mistrust first then resentment if it keeps happening and I've seen that happen too where Team Dynamics have fallen apart right where these communications have not happened and so that's definitely another skill that I think is very important for success as a staff engineer and one one last thing to add so I think Lee you spoke a little bit about the needs of the team and maybe the needs of the project if there is a lot of senior people on the project it's going to completely change things but if there's a lot of hand working on execution maybe you're more in a leadership capacity one thing that I'd like to add is also it depends on your strengths as well so there are some Specialists or people who are ridiculously productive or just them execute is worth like four or five Engineers those people can have staff level impact by doing all the execution themselves they are still expected to scale themselves by sharing their knowledge and those types of things but they may be doing Almost 100% the execution themselves because they're ridiculously productive or maybe they're specialist and no one else can do their exact work it it depends it depends on your strength not everyone the tech lead archetype some people are just heads down coder some people people are domain specialist yeah isn't isn't that the archetype you're describing there I swear I remember at meow when I was there I was like they had the like the code monster AR type code machine I love that one for sure that's great for sure I feel I relate to that a lot for sure I don't that we answered this question at all I think we had a super interesting conversation but I don't know that we answered like where you find and make up this scope I I the thing is that that gets bandied about because you start to get better than the people that are managing you at your job and they can't find these things anymore they can't know what the sort of landmines are in your project they can't know what technical things are actually constraining projects anymore and so that's where the like you need to invent it is like you don't need to make up something to get promoted like that is a bad choice you need to identify the things that are hurting and that are holding the team back and raise those things up and convince people to get them done and do them and that is where you're like inventing quote unquote this scope is I I consider it like was calculus invented or discovered like I would say it was discovered and so are these like pieces of scope that you need to come up with you may invent something brand new and convince people to do it but most often you're discovering the things that must be done that either other people are afraid of they don't see they don't think are valuable and you are in the position that you have to convince them that they are going to actually accelerate the next three projects if you take this on right now or they're going to enable something that the product couldn't do before so that to me like I heard this a lot of oh it's up to you to find the scope and was like that's not a cool thing where am I going to find this scope and it like turns out that it is in the sort of either archaeology or Discovery in the code or whatever or not even code like in product requirements that you like find that there is a gap and one of the big things that I've done throughout my career that sometimes help sometimes doesn't is be the one that puts my hand up when no one else will it's a this old rickety system it sucks no one wants to work on it we should probably turn it off and it's oh you know what actually that's generating hundreds of millions of dollars in Revenue we probably shouldn't turn it off we should probably find like Strangler fig pattern to gradually replace it with something modern or whatever but no we're not going to give up on this system or leave it to the analysts to try to keep it running like it matters so those sorts of things again sometimes you get stuck with something awful when you are doing that but yeah anyway we'll be done yeah actually I'll use that as a transition point to the next question but just Lee I love what you said I feel like one way of summarizing that is if you're asking yourself the question how do I find scope to justify my promotion to staff engineer I feel like you've already lost but that's the wrong question to ask the correct question to ask is what are the most burning problems in this or what is the top of- mind concern for my manager director other Engineers on the team and can I build something or figure out a solution to this problem that will help everyone and you can derive from that the necessary scope to get promoted but if you start with hey how can I be like The Village Idiot stumbling around to find scope you're probably not going to find it it's like building a startup in some ways you don't go out and say like where what is the problem like you don't start with a solution you start with the problem and then from there you derive the solution so you don't start with okay what is the someone a bill it should be educated by the people you talk to and part of talking to people is relationship building right like you have to be pretty embedded in the organization to figure out what those problems are and so that's the next question I wanted to bring up at the end of the day in a big Tech organization we have to be honest that there is some level of politics that when you go in for your performance review you have to get a review from someone you might have mentored maybe someone who's a tech lead or a manager on the team and they going to talk about hey here here's what Ryan did in the past six months and here's why it was exceptional he should get promoted or whatever the the phrasing might be and so I'm curious for all of you how deliberate were you about that relationship building in terms of hey I'm going to find someone who I can mentor and they're going to write good things about me in my performance review or vice versa like here is a director who I really want to impress that can say good things about me performance review either upward or downward I'm curious how you all thought about relationship building it's the most important thing you can do man down at least in my experience how did you go about doing that Carly were there one-on ones that you set up recurring with different people or how did you um identify people who you wanted to really build that relationship with usually it's people that I interact with who I think we have some sort of common approach or common problem and we end up sinking up trying to solve something together I will say that at my current organization I have people that I would probably consider friends all over the org in various business units people I probably don't even talk to every single day or interact with on a daily basis through my normal work and people are always surprised to say oh I didn't know and I'm like I know [ __ ] but that's part of it right but if you want to be seen as an expert within your organization people need to know who you are around the whole of w and like if you hide all day if you're remote way harder I love working remote but I got to say doing that while I've been remote full-time at after since I started was significantly more difficult than when I was in a in an office for so it was extremely intentional it was Finding commonalities with people striking up friendships like the day Bly if you don't have people you can like [ __ ] talk with on slack too so a lot of it is just for fun because what are we all here doing if not trying to get through our day but then those people are the ones that you can rely on when you need something and they know that they can rely on you as well and so if you're super introverted I totally get it i' say that I'm probably an introverted extrovert you need to go against every fiber in your being that's telling you like don't talk to this person don't DM them don't bother them they don't want to talk to you and really try to build bir relationships CU you're never going to thrive in your career if nobody knows who you are because who is going to step up and say that you're great at at anything that person doesn't exist no one's going to come to your rescue and see you heads down at 10 p.m. on slack just cuz your little thing is green and say holy moly Zach deserves a promotion no they're going to say Zach deserves a promotion because everyone knows that he's a rock star because in every meeting he's absolutely killing it is delivering he's showing up delivering his timelines everything is on scope everything is within budget right like all of those things come to the table and you need those people crouching for you so thinking that someone's going to save you is the wrong approach and I see a lot of people doing that like one day they'll notice me right no if only I put in another 70h hour week for sure will know that I'm full person always metal or trophy like yeah your code will not speak for itself your code will not speak for itself yeah yeah when it comes to networking or getting people to know your work I did a really bad job of going to happy hours and I think even when we were in person and building relationships I didn't do a super good job but my work was very visible and I I got the promotion even during covid so I think this might apply for people who are asking about how to get promotion while remote and really the number one thing is that you communicate your work the plan get Buy in you tell people how great the results were I know in Ideal World you just have impact you don't need to tell people for it to matter but that's not how prussians work people need to know who you are how good your work was that's why communication and writing are really exceptional tools if you're looking to grow your career because it's not enough to quietly have and in theory if you are do make doing such a good job your work will Market itself but it's always helpful to put the extra work your your code and your work cannot Advocate on your behalf to people like maybe if it's an internal tool people are using it and your name is on it like maybe but maybe your manager can be your cheerleader but eventually you're going to run out like they will not be able to do it for you anymore for me like being known is been the biggest difference between stuck at L5 never going to get anywhere to I'm pulling together Android Engineers from across Amazon asking if they've had the same problem giving them the data on when their app is about to run out of methods and saying we've got to fix this does anyone else have anything okay reader team you moved Lucine to a separate deex file so you could use that but that's the only thing and you only did it like this and it's super self-contained okay cool that's one step but what else are we going to do and then whenever there's something going on it's oh hey yeah I know who's on the App Store that worked on that go talk to them being able to be the person people go to and if you don't know the answer you can give them a single step from you to the answer that's incredibly useful and this sounds like oh you're just like being a social butterfly no like human relationships are all there is none of this matters without that whether it's the relationship with our customers our users our co-workers those that we supporting that are you know underneath us whether we're managers or not like that is all that matters no one is going to remember that cool for Loop you wrote 10 years from now they're going to remember the time that like you introduced them to the right person to get them the opportunity that they needed or that you gave them the advice that avoided them like getting stuck in a horrible project like that's what matters it is all people so for me like I am remote I didn't go and visit when I was at meta at all and I failed like I did not succeed there I had decent relationships with the people I was supporting and they thought I was a cool person but it didn't matter like I didn't have the visibility I didn't have the relationships I didn't have the relationships once things started going bad to get the help I needed to dig my way out I had a mentor and was like what you're doing is great I don't know why the team is like this and that was it I didn't have anyone else meeting people I will say this is also like a scaling thing where we've talked about going broad I've started like when I was at Amazon with my own team asking one like off-topic question every day during the pandemic and now since then that hybrid and remote work is normal just so we have something to talk about just so we're like engaging with each other socially and now I've moved from the chat organization to the Gmail organization all of the chat organization and all of Gmail front end I now in two different rooms ask this question every day and engage with people I will run into people when I'm in Sunny Veil hey you're the question person hell yeah I'm the question person you don't know anything else about me you don't even know I'm a software engineer but my name and if I came to you I was like hey you're a PM in the spaces org and I need help with this they'd be like oh yeah I know you let's talk and not find a Time on my calendar next month so it does not have to be that you are working on a project together that you build a relationship with someone like you can say like to a manager hey is there anyone on your team that needs a mentor like even if the answer is no you asking that question changed how they think about you like you going and hanging out with the PMS at one meeting during their Summit just to understand their process and see if you can contribute and say hey if you had a Dev representative here it might be really helpful or if you like at this stage brought someone in it could change the way that we approach like writing our stories or whatever process you use and then all the PMS are like that's a cool person I like them and it has changed the dynamic and changed your sort of social cache and a sign ific way and I know some people are like this sounds like politics or playing a game and what I will say is maybe it does and it's not all bad sometimes you have to play the game and playing games is fun sometimes I will also note that I am an autistic person and I have lots of Social Challenges and yet I have found out that if I don't do this I cannot succeed I've got to figure it out and sometimes I figure that out by finding ways to be a weirdo and bringing people into the weirdness that works to just do make friends Weir there's so much I want to add two things there's so much good knowledge being dropped here if you all are getting value out of this just to give us some feedback can you just drop a reaction a thumbs up just to let us know if this resonating two things I want to add to so much good stuff that just was said one thing that Lee mentioned I think a good litmus test for if you are getting staff level or any kind of seniority in your company is if I go to your teammate and say hey what are what is this person what is Ryan known for in the team or in the organization and they can't tell me cohesively okay here's what Ryan did here's what Lee did here's what Carly did that's a bad sign like they should say oh Ryan is the person he's the expert on this system if I have a question about that I have a bug I have a concern he can help me out that is I think a really good way of of evaluating if you've built up that brand that credibility among your team or or so I think that's one thing I want to call out the other thing is there were a couple comments like Sean said what happened to modesty in this day and age so my rebuttal to that Sean is don't think of this as self-promotion like I did this project let me go tell everyone how awesome I am that's not the right way to view it in my opinion the correct way to view it is hey the work I've done has value to you as my teammate I can make your life better I can make the company moreone money I can make our end users happier and experience your bug there's value in the work I'm doing and therefore I would like you to be in informed of how you can benefit from my work for example this debug ability thing that I built at meta was a big part of my promotion I built a tool that improved how quickly you could debug issues in the product I worked on when I went and went out and talked about it I said hey here's a tool that will make your life easier and in fact I have a way for you to also get impact on your performance review this going to help you and it'll help the product it'll help everyone and so one way to think about it is what is a call to action you're not going out just to Pat yourself on the B you're trying to go out there and say hey here are ways you can get plugged in here are ways that you can help yourself or you can help the team and if happens to be the work that I did because the work I did is valuable and I want to tell you about it so that's how I would reframe this idea of self-promotion I can tell you're a startup founder you were made for it I completely support sex work so this isn't a negative thing but you sharing knowledge is not prostitution you sharing knowledge has Mutual benefit it helps everyone for you to say this is the thing I did it was hard when I tried it this way and it only worked when I did this I ran into a problem over here and this is how I solved it if you need to build something like this the like the first thing I did was build a lower level framework for it that you can share like changes the usefulness of your work it is not like Shameless bragging you're not like wearing a metal yeah you can wear a metal if you want but like you are not just doing it to show off you're doing it because it matters and like your work is important yeah and you're preventing future pain too it's I don't know I feel like sometimes Engineers feel like the only way to learn things is the hard way through debugging and crying and if you share your knowledge there's another way that you can maybe teach people right you can teach people through all sorts different ways and i' I definitely think that's a big thing where it's okay are you I think that there's a difference here it's an interesting line between like bragging and teaching where it's I think that's the line that some people like feel like they might be Crossing sometimes as an engineer but it's I know if you ever do a lunch and learn when you're teaching people stuff like there's going to be Engineers who don't know this stuff I I know whenever I did the lunch and learns when I sat in on them I'm like wow I just learned like 10 things and it's and most Engineers are C curious open-minded T tenacious people cuz it's if you're in big Tech you they select for those traits a lot of the time so they're going to want to hear what you have to say anyways let you learn someone can be doing a demo and that they have a browser extension that makes it so much easier and like what the hell where did you and they're like oh yeah I wrote that thing I only use it and it's like you post it can you share that because that's rad like you just like someone's sharing their screen for 15 minutes can change the way you look at doing work and they like they may not know what it's a cool thing so I don't know there's lots of ways that like sharing is caring and they'll do it cool so we have half an hour left okay so here's what I'm thinking I have one more question I'd love to get your input on we can try and keep it relatively short maybe five or six minutes and then for the remaining 20 25 minutes I'd love to open up to the audience and see if there's a burning question we can answer from the crowd but the question last question on my end is what heuristics can you tell us about that optimizing chance for promotion especially the staff level engineer and what I mean by that is when you think about a team or an or which is likely to get you promoted do you think about oh I want to go to a team which is very Junior heavy very senior heavy small large team how about infrastructure team versus product team that's a really interesting thing where I think a lot of people in Industry talk about how there's a frontend feeling it's actually harder to have multiplicative impact when you're doing a widget on the Android app compared to If You're Building backend infrastructure WI impacting hundreds of Engineers so I'm curious for each of you what heuristics do you have to think about where it's more likely to get that staff level promotion talk to someone that's above staff level senior staff or principal ask them what in this or they would fix if they had more time and then do that they know where the problems are they don't have the time to do all of it you fix a problem that they had a problem with and and you have a principal writing support on your promo document that's going to go a long way beyond that find out what's missing submit a document before it's ready or at least have people that are on the Committees that review them or managers that review them whatever the process is at your company write your doc right now not when you think it's ready write it right now and take it to people and say why would you reject this and then start working on that you may not be able to like get that work right away your manager may not buy in on it whatever but if you don't know what you're missing and you think this project that you're about to work on is your promo project and you do it and it's not you're going to be pissed and it's your fault you didn't find out beforehand if it's actually matters and if you were actually missing it so find out oh you know what no all the projects you've done are great but we've never seen you lead anyone we've never seen you present anything then you're like oh [ __ ] like this next project I don't need to write a bunch of code I need to be the one that makes it better and makes it sure it's on time and that other people say yeah they we were able to knock that out of the park because this person was leading it but if you're going blind you will not figure out you will not hoen your way into the promotion like the process itself is beastly and if you don't understand it you're not going to get promoted and if you think I'm not a manager I don't need to understand it then you probably aren't going to get promoted unless your manager is an incredible person and that happens sometimes but that is luck that is not something that you can affect I think we all wish we were our for now I do I follow churn that's my jam at every company of work that I always do those are were my projects I over induct them R though paino in the business always so dealing with churn for most of the companies I've been at we rely on subscribers users whatever so yeah I always try to solve something related to sure something Financial for the business and that's where I've always go I think for me I think that there's a couple different characteristics that I like to think about like for if you're going to get promoted and all that stuff I always think that the number one her istic that Rahul like I think is missing here is your relationship with your manager if you don't have a good relationship with your manager like it's going to be hard it's just going to even if you're the most Rockstar amazing guy ever like it's not going to happen I but like when I think about like big team small team stuff like that data engineering has a different perspective here a little bit where it's the data sets that you're using and creating as a data engineer like there better be like 30 other pipelines that read from it if there's not it's not going to be theft level engineer you got to have you're not creating like the data set that is used to make a viz you need to be making the data set that then everyone else makes other data sets with like you got to create that Master data if you're not creating Master data you're not a staff engineer a staff data engineer and you might be a staff analytics engineer if you do things end to end where you do logging to data set to viz and you and and maybe ml model and you have all four of those and you go more horizontally like that then that's another way that you can potentially be like staff level but at least for like the data engineer family if you aren't creating Master data and not not servicing a lot of teams with that Master data like you're probably not at that staff level yet and for me I I withraw the hero stics from the rubric that everyone uses to discuss what is staff and higher scope and typically like when we talk about those projects there's three characteristics like typically how large is the size of the work stream it's usually Quantified with the number of Engineers involved the duration the complexity of the work stream can someone in the level below you not solve that problem for some reason whether like some specific domain expertise on distributed systems or AI or something like that and then the last thing is like the actual impact of the effort is it Banning multiple teams is it achieving like significant business goals for the ore and so the reason that I mentioned this is because I think like what Zach was mentioning is like talking about getting leverage by building data sets that everyone else is using that means that this is going to have a lot more impact because you're making one data set here and then everyone's building on top of it so you're one level will higher up in this you know leveraged impact that you can get if there's opportunities for you to build things that are enabling others to build on top of them that's going to get you more of that leverage impact or if you're building tooling or anything like that so that will bias a little bit more towards the infrastructure teams if you're going that route if you're trying to go for like the workstream size route there's limited spot for that if you want to be the main lead in charge of this massive product initiative let's say that's 50 people involved there's only one spot for that top person to be the you know main Tech lead so those roles are a little the senior engineer and not like a staff or principal engineer that gets picked to do that like why would they trust you with it and maybe you've built up the like credentials and maybe you've built up the trust but you're like right there at the promotion Point like you probably don't need that project to get promoted if they're willing to hand it to you I don't know that's a rough one yeah exactly those types of promotions require permission someone's got to say you're the in charge so there's less of those roles available and they're harder to compete for but there's definitely some opportunities but most of these really senior Engineers I see are more on the infrastructure side or tooling or and it's specifically because of that leveraged impact if you're building on that bottom layer you're making everyone better I want to kick it to live questions but I just want to say this infro thing and backend thing to me is a legacy bias we just don't know as much what it looks like for people to perform at this level in other places we've seen what it looks like for backend systems to support billions of users and there's lots of people that understand that and the complexity when you're working on it's better now but if 10 years ago you were working on an Android app no one knew what it looked like for a senior staff engineer to be doing that work what is the difference between what they're doing with this application and what someone else would be doing they're like tremendously complex apps billions of people might be using them but no one really quite understands what principal front end engineer or something does and so if no one can judge it and no one can measure it you better switch to a backend team so you can get your promo which is [ __ ] but it has been a real thing so that's very true also in data engineering I've noticed that like when I was working at Facebook in 2016 there was uh one there was one staff data engineer now there's tons but this is because data engineering was very new like data engineering was like maybe 5 years old at that point in 2016 and so there wasn't like a lot of good definition of what those roles look like and then now there's probably dozens and dozens of Staff data engineers at Facebook but back then there was literally one yeah oh one thing I just want to add the the infrastructure bias doesn't necessarily mean front end versus backend there are Engineers that build client side infrastructure like maybe the build system that's used on Android or maybe there's some framework that is used to manage requests between the client and server so that could still be on the front end but it's still infrastructure like product infrastructure the key is that you have the other Engineers that are leveraging what you build and that usually one layer lower than the person who's building the user facing experience unless you're one of those whober techly building some new product before we open it up to the audience anyone else want to mention anything otherwise the way it'll work is there should be a raise hand functionality in Zoom so if you want to ask a question you can go ahead now and raise your hand hey thank you for the discussion um wondering if you have any advice I'm already at staff level what would you recommend to with regard to Performance Management I'm finding that exceeding expectations at this level is becoming harder and harder that's my question I can speak a little bit about that that so you're it sounds like you're talking about teener staff once you get to the staff level teor staff and higher the behaviors are actually very similar you are influencing through others you are growing other people around you and you're often taking on the largest problems in your or the number one thing that changes is just that the initiatives you take on are one step bigger or one step more impactful or something like that so it depends on your specific or or are you an infrastructure engineer or what exactly but you just need to do exactly what you have been doing and if you are on the exceed side as a staff engineer it's just a matter of finding something that is even larger in scope so instead of influencing your group of your or that's like maybe 50 people maybe you're um influencing across two larger orbs or maybe you're building some new infrastructure that hundreds of Engineers are using instead of maybe just like dozens of Engineers so um it's just a matter of scaling and taking on more scope but it very similar behaviors I want to add just a little bit to that so before I quit my job at Airbnb I got exceeds at the staff level for my last like for 2020 and here was the perspective that like you want to do to think about like the different projects that I was working on so if you want to get the staff level usually or exceeds you're going to want to deliver on like your main mey project for me that was pricing and availability and getting those metrics like really refined really good they run your highquality big rock project but then you should also be working on designs and discussions for like longer term things so like one of the things I worked on was this document on how we should build best practices on how to take data from the data Lake and put it back into the Airbnb app and the best practices around that and getting feedback from Principal engineers and all the other Engineers like in the company to understand like what they're what kind of edge cases we could we run into and what are the different like use cases and patterns that are involved there and if you can get one of those kind of like higher level architecture impacts as well as like just the meaty like big rock impact that is like you if you don't deliver that you're not going to even meet expectations if you can do both of those things that's how you're going to really get to that next level that like senior staff sort of level that's great let's move on to Alan my question is related to what seems to be like the most recurring piece of advice Beyond just a sheer technical skill which is doing that sort of technical communication both to people who are non-technical and also people who are technical as well as building those relationships and mentorship and I was wondering if you have any advice or resources books articles whatever that you found helpful for just building that sort of communication and finding mentorship within your org or without your org that makes sense yeah I can I can chime in here quickly I think one of the core skills of communication is know who you're talking to so I'll talk about meta or Facebook which is where I was from almost 5 years they're a workplace group and so one thing that I did before I posted any so workplace is basically like an internal version of Facebook you would post updates about your work and keep people informed and so one thing I would do before I posted anything is I would look through the membership and say hey is this workplace primarily other Engineers is it the leadership team is it a cross functional group of marketers and PMs and engineers and based on that you should tailor the level of depth of your communication to accommodate that I think you have to be really careful not to go too deep in the weeds or too light on the detail either extreme is not good depending on who you're talking to and so core part of is number one research who's in the standup or the meeting or the workplace group that you're addressing and number two understand how much do they know are you if there like a PM that you're talking to how much do they actually know about your work how much do they care and based on that you should accommodate or message differently I don't really have a book or a video recommendation off the top of my head I will say just talking to people again is really important to you because you want to have some empathy for where are they coming from what are they trying to get done and the way you do that is again going back to what we talked about 15 minutes is relationship building understand who they are and how you can help them and then if you do that enough you get a good sense of the different personas that you're talking to I think one thing that I just want to add real quick is one thing that I noticed that was this weird unexpected Synergy for me when I was working at Airbnb was so I when I worked at Airbnb I made a LinkedIn post almost every single day and one of the things that you'll learn about the LinkedIn algorithm is that uh it really rewards conciseness and if you can tell people dense information in the most concise way possible yeah that is a very powerful skill and and it's even more than like the level of detail but even if you have the level of detail can you say it in a way that is still concise but detail that is another thing that I would highly recommend that you can learn to grow from but that's another great way to learn let's move on to sesh hi thank you R for doing all of this so my question is you have talked about a lot about how impact a staff careers can bring in but I am a senior software engineer I want to become a tech lead soon I want to ask you like what will be my progress if I want to go to Tech lead first and then probably St engineer later yeah I can speak a little about this it's interesting that you mentioned Tech lead as its own level separate from senior and staff because I view Tech lead as a set of behaviors that can happen across level so there are senior Engineers that work on teams that are Tech lead they lead smaller project but they do everything that you expect from a tech it I don't know if that answers your question exactly but if you're trying to grow from senior you can take a look at like your specific companies like leveling system and I think you'll see that a lot of companies Tech leadership is just like a set of behaviors that can is orthogonal the the level that you're I just want to cut in real quick I think that if what you're missing if you've gotten feedback and what you're missing on promotion is some of these leadership things and some of these visibility things maybe being a tech lead will put you in a position to do more of that but it doesn't mean it's a stepping stone necessarily like you doing those behaviors and being a strong Tech lead does not mean you know that you're on your way to staff necessarily yeah this also shouldn't be like a something that's a mystery to anyone like Ryan said there should be a leveling system at your company or behaviors are clearly defined for each level and you should be able to look at it and have a conversation with your manager about where you're exceeding and where you're deficient none of us will be able to tell you exactly what all of those behaviors are most companies there's some standards but it might be a little bit different and if you don't know that for your company that's a really good place to start and ask for that documentation because you can only guess you really need to get that outlined for you let's do one last question before we each give our concluding remarks uh Sam rude hi guys nice talking to you all thanks for doing this I'm a big fan of Zach data engineering is my thing so I want to know one thing exact from you so I've been working in data engineering for five years now so one thing is I'll be working on a different manager my project manager is different and my Vine manager and the whole setup is different where I am reporting to so for the P for the performance review I have to take what what all I have done to my manager or the reporting manager it would be a very tedious task to explain him what I have done since he's not managing me and as a data engineer like most of the things I'll coding and all the backend work it this can be applicable to the backend Engineers as well so I don't even for the fact that to put something in my portfolio I don't have any anything to show in the front end so how do you manage this how do you showcase yourself at the great question yeah so I I got you on this so so part of this is if you don't have a portfolio piece something shiny or flashy to put in front of people like part of that is on the data scientist to help you bring that to the end or the data analyst to give you that front end experience if it's a viz project so that's one way that like you can sell yourself I think another way is like what are the other Downstream impacts for example for me when I worked at Airbnb one of the big things was is I worked on the pricing and availability data sets which then got put into Smart Pricing which is an algorithm that picks prices for Airbnb listings and that had a very big impact on the business so that usually it's there's like your data sets can be sold as they make one of three people make a decision better it's either they make an executive better at making a strategic decision they make a data scientist or data analyst better at making a product decision or they make a machine learning algorithm better at making an automated decision and if one of those three things is better there's usually a metric behind it behind like that kind of stuff sometimes the analytical work doesn't have as much of a metric because it's more an increased visibility but trying to craft a story behind that visibility can be another great thing to do because it will help show show things off that way and one last thing I would say is that as a data engineer you always have the optimization metrics that you can look at like this pipeline is now 30% faster or 40% faster because one of the bigest things I did at Airbnb for the pricing and availability data sets is I cut their size by 90% And the whole company can then use a data set that's 10 times smaller and so that was another way I sold my impact but it's a tricky problem because data engineering has that kind of issue where it does fall into the Shadows a little bit and it doesn't have as much of that shiny frontend appeal to it that you can't show it off as much as you can show off a squl query I don't know so I think that'd be my kind of perspective on like to like sell your impact as a data engineer okay awesome so unfortunately I think we're going to end the questions here I'm going to start with Ryan and we're going to ask everyone on the panel to just say where can people follow up with you or if you have any concluding remarks uh Ryan you can go go ahead and start yeah thanks rul for doing the question asking and organizing everything that was really awesome thanks so much to my fellow panelists it was great meeting all I see you all on LinkedIn but this first time actually putting a face to the name so it's really great and I really appreciate everyone listening and just the showing was really awesome I feel like I always just interact through like comments and stuff so this is really welcome interaction where you can follow me at mainly post on LinkedIn and the other thing that I do is I write a substack which kind of has a lot of content that's about software engineering career growth and all that I'll put the link in the chat there so yeah thanks everyone for listening yeah Ryan substack is pure just Solid Gold by the way so so good it's so it's so good it's so good definitely definitely definitely uh subscribe to that I'll pass it to uh Z awesome thanks thanks everyone for uh coming to this I'm like amazed that we were able to get like 200 I think we were at Peak and we like 260 people in here it's freaking nuts and for me it's I'm mostly on LinkedIn and Twitter uh I do reals as well reals and Tik toks so if you want to get me there too that's great I'm finally understanding reals and Tik toks they are a weird one and yeah I do substack as well that's why I do more long form data engineering stuff I'm mostly talking about data engineering right now but in the future in the next sixish months I'm going to be doing more software engineering content as well and like software engineering data product content like similar if youall ever read the book designing data intensive applications I want to build boot camps that teach that in a very applied way but anyways I have the two domains that I would recommend y'all check out I have exactly. substack docomo and that's going to be more I bought the domain I spent the money I spent the money how much was that domain that's a really good domain was like seven Grand that bad it honestly was not that bad yeah I'll pass it to Lee yeah so I right first off yes thanks everyone for coming this is a great turnout good questions everything it was a great conversation I am have just started like within the last couple of weeks the substack I've been writing on LinkedIn a lot but it's a very hard platform for people to discuss discover old content on and such even though I was like super fastidiously like keeping a link tree up to date for a while it didn't matter no one used it so for a long timely yeah so it's been about a year and I have written a lot of things so I'm trying to find a way to recycle those and shiny them up potentially on substack so um come see me I toss the link into the chat you can easily find me on LinkedIn my name is fairly unique so yeah we've got Carly left and rul so Carly you're up Hey awesome hey everybody you can find me on LinkedIn uh I'm also on Instagram Carly machine learning I don't do any link act do I just mostly PR real I think that are funny but I think we all need that in our lives you can also find me playing Call of Duty um I'm sorry ahead of time for smoking you yeah that's mostly it this was super fun uh right R all right yeah so once again thank you to everyone who joined and thank you to the panelists it's so much fun I feel like all interacted online in in some asent capacity but it's super fun to see all four of you in this more real time way I want to say two things one is a piece of advice and then the other is I want to plug something right so in terms of one takeaway at least for me is I think the vast majority of people when they are aiming for staff engineer or any senior engineer they the 99% of Engineers are lacking when it comes to relationship building and talking to people it's not about the code it's about really figuring out what are the problems who are the people who are encountering those problems and how can you solve them so I think that's in my opinion one thing that I really would love for people to take away from this conversation in terms of lugging stuff I have a YouTube channel I have been trying to be better about higher quality content there in terms of like really fit the algorithm so I'd love for you to get give feedback there if you have any and yeah LinkedIn is also I'm pretty active there so I think that's it I think we have to have two follow-ups number one is back we need to hear about your Burning Man Saga and then number two if you all are okay with that you can do like round two of the staff engineer panel in another month or two but this is super fun whoops all Q&A yeah whoops all Q I'm so down I'm so down this is absolutely wonderful yeah cool okay this is super fun thank you again to everyone have a great evening bye everybody bye