undefined

points

[-]

"Requirements Engineering", "Writing Code", "Writing Documentation" are all areas of work that are independent of seniority in my point of view.

I might send a junior to a well-meaning customer that already knows exactly what their requirements are to just document them and learn the process. Or I might require a principal engineer for the requirements engineering of: We need a new programming language. Let's figure out the requirements for it and what abstraction level is actually feasible for the target hardware platform.

Same for writing code: A junior might write code, a staff engineer might write code. Just likely on very different levels.

If an engineer comes to a manager and asks for budget for work they invented, I'd expect the answer to be something along the lines: "That is nice, but can we please focus on the stuff we are required to do?" That alone would be reason enough for be not to put ideas that way, but to come up with a requirement why it makes sense to do the work.

by gloryjulio3 hours ago|

parent|

[-]

You are not talking about the expectations in terms of the corporate levels. Staff and senior have clear definitions in tech companies. A staff(l6) is the team lead who is required to find the scope for himself and team. That's in his job description. If he can't do that he would get pipped or fired.

A senior(l5) is the tech lead on the project level. He is not in charge of handling the team's scope. As long as he handled his own projects well, he would usually pass the review cycle. The difference is crucial. At staff and above, the engineer's responsibility is vastly larger than a senior's.

I am not saying a senior can't do a staff's job - that's how he get promoted once he demonstrated that he is operating at a staff level, i.e "inventing" scope for his team. But a senior's scope is much smaller than a staff's.

This applies to almost all US medium to large tech companies