Like a lot of E5s, I'm working on a piece of my team's overall project roadmap, which is set by an E6 TL. The piece I own is less technically complex than other parts, but it is quite XFN heavy (great for people/direction contribution). I was wondering if this is still enough to get to E6 or do I need the higher technical complexity as well?
It's 100% okay, but I would clarify this with your manager.
Staff engineer is such an exciting and interesting stage in career as that's when things get really fuzzy and very undefined. Every staff engineer is different. Since a massive, critical part of being E6 is "filling in the gaps", how you grow into E6 depends a lot on what your org needs and values. Some orgs will have more technical E6s and some will have more people-skill heavy E6s. It varies a lot.
For reference, I have literally seen strong E6s (including one that got promoted to E7) do well with only ~10 commits landed per half. They were just incredibly strong at communication, shaping product direction, and leading people/projects.
For that 2nd part about clarifying this with your manager, here's 2 excellent resources in Taro to do that:
Lastly, I highly recommend this video from Airbnb's Head of Search Engineering Rachel Zhao about the difference between a senior and staff engineer.
Agree with Alex on this one. Here's another way to frame the answer:
All companies are in the business of delivering some valuable solution to their customers in a profitable way. Technical complexity is a negative most of the time because all it does is increase cost to the company. That can come in a lot of forms:
I would argue that staff engineers should help companies find ways to simplify. As an engineer, a good way to create value is by lowering costs, not increasing them. But, of course, your engineering leadership must also think this way for it to be good career advice. I suspect that Meta does.
It really depends on your org and how it handles calibration, if we are just talking about Meta. Some org expects E6 writing more code while also owning larger scope with more non-coding complexity. Talk to your manager about your goal and tell them you have concern about whether not writing enough code will hold you back. Be straightforward about that. Don’t soften it.
I’ve seen manages and directors giving hints to their E6 for “not writing enough code”, even though they are already working on what’s most critical to the team’s success. Your manager might be okay with you writing less code. Your manager have to know the probability of someone far from your team casually starts a conversation in calibration like “but hey, this person’s diff count is so low”.
Beyond Meta, my expectation of an E6 is to identify what’s most critical to the team’s success and focus on that, especially on reducing ambiguity and uncertainty. Writing more code or less code is not the point.