I once worked at a company where the PM defined the difference between senior and junior developer in terms of providing better estimates for the business. Nothing about knowing how computers work, how large codebases evolve, what works and what doesn’t in terms of security or performance or maintainability or anything else, or having a broad-based knowledge of computer science. (You know, actual senior engineer stuff.)
That company had substantial layoffs, a few months later.
I often use a slightly broader version of that definition, which is “senior engineers reduce risk”. This can encompass technical risk (everything you list), but also cultural risk (who do we hire, how do we deal with failure) and business risk (how do we deliver features and products in a timely manner).
It makes sense that a product person would focus on the business side of things, just like fresh CS grads tend to focus on their volume of code - it’s the most visible artifact of a complex process. It can be annoying to work with people who are so myopic, but opening their eyes to the bigger picture is just another thing that a senior engineer can and should be expected to do.
Oh, that’s really cool framing. Thank you.
I think “junior” and “mid” and “senior” management make as much sense as “junior” and “mid” and “senior” developer, but it means you need to stop giving “senior” as a prize: It’s not points on a track, or a level, or a token. It’s a completely separate job.
Senior means that you’re held accountable by the board. That’s the same for Senior Management, and it means that if the engineering team takes on a project and is late, or over budget, it comes out of your bonus. I don’t care if you’ve programmed for twenty years, or have a linux distribution named after you, if you tell me your job is to close bugs, then you’re not senior.
To do that job well, you need a certain fluidity and flexibility about where to nudge and mentor, and where to roll up your sleeves and hack. It all rests on you. It’s not a job for everyone, and If you’ve got some kind of weird business structure where you can’t do this– for example you have managers telling programmers how to program (for some stupid reason), then you need to fix that before you can have senior developers. But for some people, this is the job they want to do, and by giving the title “senior” out like gumdrops, you’re preventing them from coming and working for you.
Yours seems like an idiosyncratic definition. I’ve never heard the term used that way in software, and there are plenty of other industries in which “senior” is used to describe non-managerial positions that don’t report to the board.
I agree it’s not the normal definition: There is no normal definition of “senior software engineer” because of the current management trend to hand them out like balloons in lieu of pay.
I think people should stop accepting this and start demanding higher pay.
However if you don’t want to use the term “senior” to describe this, what do you want to call the persons who are responsible for making sure that the software being designed is actually good for the company?
If those people aren’t software engineers, then I don’t see how they can contribute meaningfully in a company that does software, and if those people are software engineers, then you have to give them some other kind of jerking off like “lead engineer” or something stupid.