Is it okay to have less technical complexity when growing to staff?

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:

• Our in-depth session on navigating performance review - Largely inspired by our experience with Meta PSC, and it covers how to stay in sync with your manager so you are growing at the pace you want and your rating is never a surprise.
• To learn how you can build that deep, effective relationship with your manager to do the above, check out our in-depth session on having impactful 1:1 meetings.

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:

• More expensive to operate
• More time for other engineers to ramp up and contribute
• More fragile for customers since there are more moving parts

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.