The more senior you are, the more damage you get to do to the business if you're wrong. Intern working on a file format? Somebody else can redo the work if you screw up. CTO setting development strategy? Tank the whole product development effort, hobbling even good developers.
I consider a senior engineer to be (in broad strokes):
- Somebody who can organize other engineers to accomplish an objective.
- Somebody who can pinch hit if needed on any projects under their direction.
- Somebody who actively teachers other engineers about what the engineer knows, inside of work or out.
- Somebody who has either fucked up a few times, or salvaged a fucked-up situation (business or development), and can explain what happened, what their role in it was, and how they should've done things differently (because there's always a better set of actions to take).
- Somebody who can interface directly with customers if needed and who can help compromise between business objectives and engineering ones--even if it means saying no to new shiny or sugardadddy customer.
EDIT:
It's very important not to confuse a domain expert with a senior engineer. I've worked with brilliant DBAs and syadmins and OOP folks, and they're much better in their fields than I am--but that doesn't make them suited for architecture and project work.
The more senior you are, the more damage you get to do to the business if you're wrong. Intern working on a file format? Somebody else can redo the work if you screw up. CTO setting development strategy? Tank the whole product development effort, hobbling even good developers.
I consider a senior engineer to be (in broad strokes):
- Somebody who can organize other engineers to accomplish an objective.
- Somebody who can pinch hit if needed on any projects under their direction.
- Somebody who actively teachers other engineers about what the engineer knows, inside of work or out.
- Somebody who has either fucked up a few times, or salvaged a fucked-up situation (business or development), and can explain what happened, what their role in it was, and how they should've done things differently (because there's always a better set of actions to take).
- Somebody who can interface directly with customers if needed and who can help compromise between business objectives and engineering ones--even if it means saying no to new shiny or sugardadddy customer.
EDIT:
It's very important not to confuse a domain expert with a senior engineer. I've worked with brilliant DBAs and syadmins and OOP folks, and they're much better in their fields than I am--but that doesn't make them suited for architecture and project work.