Seniority and Soft Skills

"Seniority" is a pretty loaded term, which depends on the organization one is in, and what that organization wants to get out of it. After all, at Alice’s Software Factory there might be a bajillion gradations involving all possible combinations of [junior, senior, systems, lead, principal, etc.] and [developer, engineer, analyst, architect, wizard, etc.]. And additional combinations too — senior principal systems analyst wouldn’t be out of the question.

If you ignore the labels, there is a much more basic question at hand here, and that involves the people attached to the titles. To wit, what allows people to climb up these ranks? Mind you, this is more abstract than just straight up software engineering — it’s about pretty much any field, and how you differentiate “seniority” in that field.

Me, I tend to break this up at a very high level into a few basic categories, viz. Junior, Mid-Level, and Senior.
The difference? I’m glad you asked!

A Junior person is someone who you can’t really trust to come up with the correct solution to a problem, or to implement the solution correctly.
Note, I’m not saying that they won’t do it correctly. The point here is that if they happen to do it correctly, it’ll be happenstance, not circumstance. And even then, it won’t be for the right reasons.
Mind you, even if they did do it for the right reasons, that will have been through sheer luck — you can’t quite rely on them to get it right the next time, even if they’re faced with the exact same problem (“I thought I’d try something new this time!”)
The bottom line here is that being Junior is all about not having the experience to know right from wrong, and not quite having the breadth and depth of knowledge to know why what you’re doing is right or wrong. And hence, they need constant guidance and oversight — ideally around giving them the context around the things they’re doing..

A Mid-Level person is one who’s gotten past this. They’ve developed some level of mastery in a field or two, and can happily run with the ball in those fields. Constant oversight is really not needed here — you can, to a certain extent, trust them in their domain.
However (!!), they have two primary impediments on their path to becoming a Senior person.

1. They haven’t developed sufficient Pragmatism around their knowledge base, haven’t quite figured out that most of the time, there is no such thing as the “Correct” answer. Think of it as the different answers to the questions
   “How would you do this?”
   “in half the time?”
   “if we were going to throw it away a few months later?”
   in short, the ability to look at the problem space, not just from the technically feasible way of resolving it, but also based on as many of the constraints as can be identified, and, heck, with the certainty that these are going to change over time.
2. They all suffer from some level of Dunning-Kruger effect, the belief that having developed mastery in one field, they can opine on other fields too. Quite a few engineers (and people for that matter!) never make it past this stage, especially if they develop any level of significant success at this stage. #CowboyDevelopers are a prime example, as are most (not only tech!) CEOs who hit it big during a bubble.
   Then again, the good ones are usually blessed with some level of Humility, Teachability, and Self-Awareness, and consequently make it past this stage

To emphasize this point, the difference between Mid-Level and Senior people isn’t their domain specific expertise, it’s all the “soft skills”, i.e, Pragmatism, Humility, Teachability, Self-Awareness, and the like.

Of course, we suck at measuring these skills, and instead, focus on the things that we are good at measuring, like code-quality, problem-solving, and whatnot. The results are, of course, all too predictable — highly dysfunctional organizations.

So yeah, take a look around your own organization, and ask yourself how seniority works. If the answers aren’t to your liking, and you have agency, change it for the better!