Thoughts & Ramblings Servers, circuits, and arguments that have to hold up.

Seniority is a bridge, not a level

The most useful mentorship question isn't what you want to be called. It's which parts of the work leave you with more energy than you started with.

Junior, intermediate, senior, principal. We talk about these as levels. As though there were a floor you arrive on, where you then stand around. Nobody experiences them that way. They are bridges. You cross them one plank at a time, and usually you don’t notice which crossing you’re in the middle of until you’re most of the way over.

I came back from time off today. It was my birthday, spent deliberately not thinking about work, and the first thing on my mind afterward was a developer I’ve been mentoring. Mid-career. Genuinely good. Stuck in the particular way that people get stuck when they’ve cleared every obvious bar and nobody has told them what the next one is.

The conversation I used to have in that situation was about requirements. Here is what senior means at this company. Here are your gaps. Close them.

That isn’t wrong, exactly. It just answers a question about identity with a checklist, and the checklist doesn’t satisfy forever. What they want to know is whether they are becoming someone they’d want to be.

So I stopped opening with the ladder. What I ask now is narrower, and more uncomfortable. Which parts of last quarter did you want to keep doing after the ticket closed?

Not which parts you were good at. Good is cheap. Most competent people are good at things they find tedious. I mean which parts left you with more energy at the end than you had at the start.

The answers cluster in ways I didn’t expect when I started asking. Some people light up describing infrastructure, and the quiet satisfaction of a system that stops needing them. Some come alive in front of a client, translating between what someone asked for and what they meant. Some want the architecture: the shape of the thing, the decisions that are expensive to reverse. Some just want to write better code than they wrote last year, and are slightly embarrassed that this is enough. Some want their work to be public, and useful to strangers.

This one landed on architecture. I had half expected that, and I had been careful not to suggest it. What he wanted was the shape of the thing. The decisions that are expensive to reverse, where you choose what the system will find easy and what it will find hard for the next four years.

Once you know that, the mentorship stops being abstract. You are no longer helping someone become senior in general. You are helping someone who is energized by architecture get more architecture, sooner, on something real, with enough cover that the first expensive mistake doesn’t end the experiment. Concretely: he owns a design decision on real work, and I review it before it ships rather than after.

That is a plan. “Demonstrate technical leadership” is not a plan.

This is also where the bridge idea earns its keep, because it changes what a project is for. Every feature is a chance to try one thing you haven’t done, or to sharpen one thing you’ve stopped thinking about. Most of the crossing happens in the second category. You don’t cross by taking on something enormous and heroic. You cross by noticing that the way you’ve always handled a migration is a habit rather than a decision, and deciding on purpose this time.

I want to take the obvious objection seriously, because I have been on the receiving end of it. The external indicators are real. Titles gate access to rooms where decisions get made. Salary bands are not a metaphor. Telling someone to focus on what energizes them, while a promotion cycle decides whether they can afford a house, asks them to absorb a cost you are not paying. Anyone who has mentored people without acknowledging that has been giving advice that only works for people with a financial cushion.

So both things have to be handled. Get the person paid and promoted. That is my job, not theirs. But don’t confuse it with the other work. The promotion is a lagging indicator of a case someone else built. What I am trying to help with is the part that doesn’t show up in the packet: whether five years from now they are doing work that still interests them, or whether they optimized successfully toward a version of themselves they don’t much like.

The developers I have watched navigate this best were not the ones who climbed fastest. They were the ones who could tell you, specifically and without hedging, which part of the craft they were in it for. And who then arranged their next three projects around getting more of it. Sometimes that meant a smaller client. Sometimes it meant a title that looked sideways on paper.

Privately, I think of my part in this as riding shotgun rather than driving. I can read the map, say what’s coming, and mention when I think a turn is about to be missed. But it is their route. And the destination isn’t a level. It’s a morning some years from now when the work in front of them is work they would choose.