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.
When I tell a recruiter I worked for 7 years as a dev, they often categorize me as a senior.
From the perspective of HR departments, "Senior" means "Has worked in this field for at least N years, and therefore can command a salary between $X and $(X+Y)". You become one by keep working on the field, but I don't think this is what you asked.
From the perspective of management, "Senior" means "can work on roughly defined goals with minimal supervision". Contrast that with "Intern" := "Needs micromanagement" and "JuniorDev" := "Can work independently, but needs to be assigned well specified tasks". Please note that this is only weakly correlated with your technical expertise, and has more to do with your ability to work around issues beyond your direct control: How do you learn stuff on your own. How do you reach out for help when you get stuck. How do you resolve conflicts when your perceived goals get in the way of those of your team member's, or viceversa.
You learn to do this by doing (that's why HR uses the proxy of "N years of experience"), but more than that you learn by striving to keep a good attitude and not allow roadblocks to stop you from completing your assigned tasks. It also help a lot if you learn to listen to people and try to figure out how to fix the problem at hand for good (instead of doing the bare minimum to get a perfect row of check marks on your weekly report).
Finally, from developers perspective "Senior" means "is an expert in X, Y or Z technology". This usually gets in conflict with the manager's definition and causes a lot of unneeded friction and resentment. You obviously do this by working on something that interest you, but the not so obvious part is that you have to try to avoid doing work too far from your intended area of expertise. This is what some people call "quality work" (vs simply "chores"). You cannot always avoid chores, neither should you aim to... but if you get too sucked into them, you will have a hard time building up expertise.
"But that would put you in the pay band of a senior engineer!"
shrug