Senior is something other people see in you

Seniority is not a thing you possess. Other people decide whether they see it in you.

That sounds obvious until you notice who those people usually are. Most of the time, they are coming in cold. They did not grow you, hire you, or watch the long arc of your work. What they have is narrower: the pull request in front of them, the estimate you gave on Tuesday, the way you handled a standup, and the shape of your thinking over the last two weeks.

That changes what becoming senior means.

I've been writing software for 23 years. For five and a half of those years, I also interviewed engineers through 1000+ technical interviews. I've been the junior, the senior, the team lead, and now the fractional CTO who walks into other people's companies for a living. The longer I do this, the less I think "senior" is a level you achieve. It is trust other people are willing to give you.

If you accept that, how you operate has to change.

The 30-year career at one company is gone

There was a version of a software career where an engineer spent decades in the same company. Context built slowly: the people, the codebase, old incidents, and the story behind the strange choices. By the time that engineer became senior, half the company already trusted them, and the other half had heard why.

That is not how most careers work now.

Most developers spend their working lives in systems they did not build. They join teams already in motion, work on code written before they arrived, answer to managers in other time zones, and sometimes serve clients they will never meet in person. Every job change restarts the trust loop.

The full-time developer at a five-year-old startup, the contractor on a six-month engagement, and the fractional CTO walking in for ten hours a week are all operating in someone else's system. Only the timer is different.

So the people evaluating your seniority are often working from a narrow sample. They are not judging the whole arc of your career, the project you turned around in 2021, or the messy stretch where you grew into the role. They are judging what is available now: a pull request, a Slack thread, a meeting, a decision note, and the rough impression you have made so far.

Most career advice still talks as if the old model applies: accumulate skill quietly, do good work, and wait for someone to notice. That advice fits a world with more shared history than most teams have now.

The current world rewards developers who understand they are being read in real time. The senior developers I trust most do not perform seniority; they leave less ambiguity around their judgment.

That sounds harsh. It is also useful. You can do something about it.

Ask questions that carry work

The first place this shows up is how you ask for help.

A junior developer asks, "Which library should I use?"

It sounds efficient. It usually isn't. The person being asked now owns the research: options, trade-offs, risks, and final recommendation. The asker gets unstuck, while the helper does a chunk of work that never appears on a ticket.

A senior developer asks differently:

I've looked at three options. This one fits best because we already use the dependency, the licence is permissive, and the maintenance signals look healthy. Any objection before I go ahead?

Same decision. Different burden.

The asker did the thinking. The helper can spend thirty seconds confirming or redirecting instead of thirty minutes researching. Multiply that across a year and the team's capacity changes.

This is not about politeness or about avoiding senior people. It is about who is doing the work. Junior-style questions push work upward. Senior-style questions carry the work and escalate only the decision.

The same pattern applies to standups, bug reports, design reviews, and almost every teammate interaction. Show the thinking in enough detail that the response is cheap: options, trade-offs, recommendation, then confirmation or correction. Do not make someone else start from zero.

Say what you don't know

The second shift is harder because it requires admitting things developers are trained to hide.

During those five and a half years of interviews, across different companies, stacks, and levels, the strongest senior signal I saw was not a perfect answer. It was this:

I don't know, but here's how I'd find out.

Not the sentence on its own. What came next.

Strong candidates would name the first thing they would check, the assumption they were testing, and the signal that would tell them they were wrong. That was navigation, not pretending.

Weaker candidates bluffed. They built an answer from adjacent knowledge and tried to sell it. Interviewers see this, even when the candidate thinks they got away with it.

The point is not confession. The point is navigation.

"I don't know, but here's how I'd find out" contains the things that matter. You are honest about the current state, you own the gap, and you have a plan for closing it. That is a small demonstration of how you would handle a much harder problem.

Estimation works the same way.

A junior says, "Three days." Confident, probably wrong.

A senior says, "Three days if the API behaves the way I expect, a week if it doesn't, and I'll know which by Wednesday."

The goal is not to be right every time. The goal is to avoid surprises. Name the unknowns, bound the risk, and tell people when you will know more.

The instinct to sound certain is usually backwards. Clear uncertainty beats fake certainty.

Leave evidence

The third shift is the one most developers under-invest in.

If a risk gets mentioned in standup and never written down, assume it will be lost. Three weeks later, when it bites, nobody will remember who flagged it. The decision about why you chose Postgres over the alternatives is useful to the next person only if it was written down at the time.

A pull request reviewed with clear reasoning becomes a teaching artifact. A pull request approved with "looks good" is forgotten by Friday.

Senior developers leave artifacts.

That can sound like bureaucracy, but future readers are part of the work. They will judge the quality of your thinking from what remains after the meeting, the call, or the review thread is over.

That means writing decisions down, following verbal flags with written ones, and explaining why in code review, not just what. Important conversations should leave records someone can search later.

This is obvious in remote and async teams, but it is true everywhere. Documentation is what the colleague six months from now sees, what the manager can point to in a performance review, and what the contractor reads before extending your work.

If you want to be seen as senior, make it easy to see the senior work. Leave evidence.

When you have weeks, not years

All of this matters in any company. It matters most when you enter a team that already had a culture before you arrived, and you have weeks, not years, to be useful.

I see this in my own work. A founder brings me in as a fractional CTO, usually for a few hours a week. I have no shared history with the team, no map of who is strong, who is quietly burnt out, or which decisions were principled versus rushed.

The team does not know me either. Nobody owes me trust. We have to find out quickly whether I help.

Everything gets compressed. In week one, the questions I ask tell the team whether I am going to be a load on them or a help. The first honest "I don't know" sets the tone for whether they can trust me with hard problems. A written decision with clear reasoning shows whether I am there to leave useful artifacts or just opinions.

There is little margin. Signals that normally compound over a year have to show up in the first month.

The same is true for an embedded engineer on a client team, a contractor on a six-month engagement, or a new hire being evaluated against people who have been there for years.

Time is short. You do not have the luxury of demonstrating seniority slowly. You have to make it visible from week one.

The moves are not complicated: ask questions that carry work, communicate uncertainty cleanly, and write down the decisions and risks earlier than feels necessary.

Senior is recognized, not claimed

You do not become senior by claiming it. You become senior when other people recognize it in your work.

The difference matters.

If you treat seniority as something you possess, you focus inward: what you know, which frameworks you have used, how many years are on your CV, what title you have. Some of that matters, but less than developers hope.

The people deciding whether to trust you will usually read your recent behavior first. Not the whole story. Just the last pull request, Slack thread, estimate, or decision note. They will judge from the work and the evidence in front of them.

If you treat seniority as something other people can see, you build differently. You make your thinking visible. You reduce work for others. You name uncertainty and write things down.

None of this requires permission, a title, or someone else recognizing you first.

Eventually, people notice. Not because they watched you grow. Because the last two weeks made the next two years feel less risky.

I work as a fractional CTO with EU-based B2B SaaS founders. I help small teams make technical decisions, reduce risk, and keep delivery moving. If that would be useful, get in touch.

This post grew out of a talk I gave to the Onja Developers in Antananarivo, Madagascar. They are frontend engineers working full-time inside Western product teams. The talk was 35 minutes. This is the part I kept thinking about afterwards. You can view the slide deck here (PDF, 34 slides).

If you run a tech meetup, conference, or in-house training program and want a practical talk on engineering judgment, technical leadership, or how AI is changing engineering teams, I'm open to it.