Seniority: The Responsibility That Doesn't Come with the Title

A few years ago I worked alongside a developer who had just been promoted to senior. His technical skills were solid — he wrote code, completed tasks, delivered. But every time a new requirement came in, his first instinct wasn’t “how do we approach this?” It was “tell me how to do this.” The title was in place; the seniority wasn’t yet.

That observation led me to a question I’ve been sitting with ever since: what is seniority, really?

The gap between title and seniority

In the job market, titles are inflated. Someone with “mid-level” on their profile sometimes delivers junior-quality work; someone called “senior” sometimes meets staff-level expectations. This isn’t an illusion — it’s a structural reality. Titles are shaped by market conditions, a company’s growth rate, and who wants to retain whom.

Acknowledging this gap matters. The moment you receive a title, you don’t have to be senior yet. On the other hand, you can act senior regardless of your title.

The real question is: when does seniority actually happen?

Seniority is not the volume of technical knowledge

Technical knowledge is an input to seniority, not the output. Over the years I’ve seen plenty of highly knowledgeable but non-senior engineers, and I’ve seen people act senior early on with relatively little knowledge.

The real indicator of seniority, as far as I can observe, shows up in three capacities:

Making decisions under ambiguity. Requirements aren’t fully defined, the senior on the team isn’t around. What do you do? Junior and mid-level engineers wait or ask for guidance. A senior developer makes the best call with the available information, records it, and is ready to revise if needed. The decision doesn’t have to be perfect — it has to be made.

Owning the outcome of your decisions. Seniority is not about claiming credit; it’s about carrying responsibility. You made an architectural call and it turned out to be wrong. A senior developer says: “That was my decision — where did I go wrong, and how do we fix it?” A non-senior says: “The requirements were clear enough, this isn’t really on me.”

Making others’ work easier. This is the least discussed indicator, but in my view the most telling one. A developer’s seniority is measured by the multiplier effect they have on the people around them. Do the people near you do better work independently because of you, or do they depend on you for everything?

From asking questions to framing them

There’s a transition I’ve noticed over the course of a career. Early on, you ask questions: “How do I do this?” “Which approach is right?” “What should I use?” That’s appropriate and necessary — it’s how learning works.

Over time, those questions shift. Instead of asking questions, you start framing them. “This can be done in two ways — the first has this trade-off, the second has that one. I’d recommend the second, but the call is yours.” Anyone who can put that sentence together is already acting senior — regardless of their title.

Framing is not a passive act. It means distilling ambiguity and setting up the ground for whoever has to make the decision. That requires both technical depth and contextual awareness.

The traps of “playing senior”

When the title arrives, some developers slip into performative seniority — weighing in on everything, taking the floor in every meeting, constantly lecturing junior engineers. Those are the symbols of seniority, not seniority itself.

The most common trap I’ve seen: acting like you know the answer when you don’t. A senior developer has no hesitation saying “I don’t know, let me look into it.” That’s not a weakness — openly acknowledging the limits of your knowledge is a sign of confidence, not insecurity.

Another trap: trying to win every technical debate. Winning the argument and finding the best decision are not the same thing. The first one is ego satisfaction; the second is the job.

Acting senior before the title arrives

This is both possible and valuable. More precisely, the title is usually recognition of seniority — the seniority itself gets built before that recognition comes.

If you can carry ambiguity, if you own the outcomes of your decisions, if you make the work of those around you easier — then you’re acting senior, whatever your title says. Recognition may come late; that’s frustrating, but what you’ve built is durable.

One thing I’d say to developers standing at the threshold of a senior title: don’t wait for the title to change you. You change first — the title follows.