Comment by GMoromisato
1 month ago
This is a good question. I compressed too much: instead of "performance at your boss's level" I really meant, "helping to achieve your boss's goals".
If you're an engineering IC in a team of 5, what are your boss's goals? It's usually things like: hit your deadlines, avoid production bug catastrophes, and maybe add features that make the sales people happy.
How can your boss achieve those goals? I have a few ideas:
a) Processes: Introduce or refine processes for the team to ensure high-quality code or to gain efficiencies.
b) Mentoring: Help members of the team to function at their highest level.
c) Clearing Obstacles: Coordinate with other teams so they don't slow you down. E.g., make sure teams you depend on are on schedule, and if not, adapt and adjust.
But this is just an example. I think the easiest thing to do is ask your boss what their goals are. What does success look like to them? Once you know that, you might be able to come up with ways of helping that they might not have thought of.
This sounds like advice for how to be promoted to a specific level -- the first point where awareness of things beyond yourself is required (somewhere around the Senior or Staff level for ICs, depending on your company).
Generally everyone in a team should be working towards some shared goal, there's no level at which you can be a chaos agent and not serve some higher purpose. The difference at this level transition is that you realise that for yourself -- someone doesn't need to remind you of the goal and nudge you back on course. That same realisation is not going to cut it at higher levels.
For me the general version of this advice is not something you can just tell the person who's being promoted, it's collective advice, for them, their manager, their tech lead: everyone needs to agree that this person needs to be given more rope, they need to do something useful with that (i.e. not hang themselves with it), the people around them need to watch out for when they start tying a noose and help them untie it (already regretting this analogy), and that's how you get promoted.
The rope takes different forms for different levels. I'll use the level scale I'm familiar with, starting with a newly graduated engineer at L3:
- L3 -> L4. You help decide how to build the feature.
- L4 -> L5. You help decide what features are worth building, and are trusted to maintain them.
- L5 -> L6. You help shape the work and ongoing maintenance of ~10 people's work (what products are worth building and how), over a time horizon of 6 months to a year.
- L6 -> L7. ~50 people's work, 1-2 years.
- L7 -> L8. ~200 people's work, 2-5 years.
- L8 -> L9. Things start to get fuzzy. The pattern suggests that you have a hand in ~1000 people's work, which is possible to do in the moment, but rare. There's two ways I can think of: you're either a world expert in your field, or you have set the technical strategy well for your organisation as it grew to this size.
This is just based on my experience, working largely on infrastructure teams both in big tech and in start ups as both an IC and a manager (currently an IC).
Yes--excellent points.
I think at the higher levels (L8+) the job switches to creating a culture that can accomplish goals.
I think those are good examples. I think part of the confusion is that most of those are typical responsibilities of e.g. senior level IC work, so "performance at your boss's level" looks more or less the same as "performance at your current IC level".
Which is good advice! Do your job well!
I'd say it's about doing things at the next level to show you're ready for that level. So for moving from a Sr to a Staff position might involve doing more mentoring of the team, showing that you are using your knowledge to improve the efficiency of both your team and other teams, etc.