What actually changes between mid and senior

Nothing about the volume of code changes. A mid engineer is handed a decision that has already been made and builds it well; a senior is asked before there is anything to build. Scope, influence, mentoring, judgement — every other item on the ladder is downstream of that single difference in timing.

The question underneath the search is usually more specific than the search itself. Either you are shipping more than anyone on the team, your reviews are clean, and the promotion did not come — or it did come, the work feels identical to last year, and you are quietly waiting to find out what you are supposed to be doing differently.

The shift is in timing, not volume#

The reason timing carries so much weight is that the cost of changing a decision is not constant across its life. While a decision is still a sentence, it costs a sentence to change. The same decision, once it has shipped and three other teams depend on it, costs a migration and everyone’s next quarter. Your judgement is worth what it is worth on any given day — what varies by an order of magnitude is the price of acting on it.

So the promotion is less a claim about the quality of your opinion than about when your opinion arrives. This is also why the step is rarely handed over and almost always taken: nobody grants you an earlier seat as a reward. People start asking you earlier because they have watched you be right at a stage where being right was cheap, unprovable and completely undemoable — where there was no diff to point at afterwards and no ticket that closed.

Read that in the other direction and it turns into something you can act on. “They never listen to my objections in review” and “I am asked too late” are the same complaint, and only the second one has a fix. An objection raised in review is not being ignored out of disrespect; it is arriving after the point where accepting it was still affordable, and the people declining it are doing arithmetic, not politics.

What it looks like from the inside#

Here is the whole argument in one decision small enough to state in a sentence. An order is placed, and the billing service has to find out. Either the order service calls billing over HTTP inside the transaction that writes the order, or it writes a row to an outbox table in that same transaction and a separate worker delivers it. While the question is open, each option is one sentence and the choice costs an afternoon of argument.

Take the synchronous call, and the bill arrives later in three parts, none of which is the code itself. First, coordination: once two other services also call that endpoint, changing the contract is a scheduling problem across three teams before it is an engineering one. Second, a backfill — every order accepted while billing was down was never billed, so somebody reconstructs which ones from the order table and replays them, and has to be sure they are replayed once. Third, the fix is the outbox you did not build, plus a period running both paths while the existing callers move across. The outbox itself never got harder to build — it is still one row, written in a transaction that was already open. All three of those costs come from when it was built, not from what it is.

That is what the earlier seat buys, and it is why the signals that you have it are so unglamorous. The shape of a good day changes first. Your best day’s work can produce no code at all, because what it produced was a thing not built, or a boundary that will not need unpicking in two years. Diff-shaped self-assessment stops working at exactly this point, which is why so many people making this move report feeling less productive during the months they become most useful. Nobody warns them, because the feeling is embarrassing to admit to.

Then the kind of question you get asked changes. Not “how should we build this” but “should we build this, and what do we give up if we do” — questions with no correct answer, only defensible ones. The defence has to survive being read a year later by someone who was not in the room and has no memory of the constraint you were under, which is the whole argument for writing the decision down where the code lives, with the options you rejected and why. An early decision with no record of its alternatives is indistinguishable, later, from an accident.

The last signal is the slowest and the most disorienting: being wrong stops being fast. A mid engineer finds out they were wrong when a test fails, which is unpleasant and takes ninety seconds. An early decision is scored quarters later, by whether the shape you chose still fits the thing the business turned into — and by then several people have built on top of it, including you.

What you give up#

The first cost is information. The earliest moment in a decision’s life is also the moment when the least is known about it: nobody has tried the approach, the requirements are a paragraph in somebody’s head, and the constraint that will eventually decide the whole thing has not been discovered yet. A senior’s answer is more consequential and worse-informed than a mid’s, every single time. What compensates is not certainty. It is that a decision taken early is still cheap to reverse, so the right skill is not being right — it is choosing options that stay open, and saying out loud which assumption would need to break for the answer to change.

The second cost is the feedback loop. Code is scored in minutes and scored honestly. A boundary drawn early is scored in years, often by nobody at all, because you almost never find out about the migration you prevented. The one place you can sometimes see the bill is on the other side of the trade, when a boundary drawn badly in year one turns into the routing and data-ownership problem somebody has to solve while the system stays up. That is the same decision as yours, priced at the far end of its life.

The third cost is the one people miss until they are living it. You give up the uninterrupted day — the one where you close the laptop with a diff that proves you existed. Interruptions stop being a tax on the job and become the job, because the conversations you are being pulled into are the ones that happen while things are still changeable. If you protect your focus time perfectly, you have protected yourself out of the seat.

Where it goes wrong#

The common failure is not being denied the earlier seat. It is being given the earlier seat and bringing the same thing into the room that used to work in review: a preference. Review rewards a strong, specific opinion, because by then there is one artefact and the question is whether it is good. An open question rewards something else entirely — two or three options with their costs named, and a statement of which one you would take and what would change your mind. Turn up to an open question with a preference and you get talked past, once politely and then not at all. Nobody announces that they have stopped asking you early; the invitations simply stop, and the room is smaller for months before anyone notices.

The billing decision from earlier is a fair worked example of how that looks from the inside. Somebody is asked, genuinely early, which way the notification should go. They answer that it should be an outbox — the message written into the database in the same transaction as the order, with a separate process delivering it — because that is the correct pattern, and it is. They are asked why, and the honest answer available to them is that it is the one they would choose. The room takes the synchronous call, not out of ignorance but because the person arguing for it attached a date to it, and a preference has no date. Six months later the backfill happens exactly as predicted, and the prediction was worth nothing, because nothing about it was checkable at the time it was made.

That is the mechanism rather than the anecdote: a preference has no failure condition attached, so a room cannot act on it except by trusting the person holding it — and trust is the exact currency you do not yet have on the day you first get the earlier seat. The same claim with a condition on it is a different object entirely. “The synchronous call is fine while billing is the only consumer; the afternoon a second team subscribes, the contract change becomes a three-team scheduling problem” can be agreed with, disputed, or scheduled around. It also survives being wrong, which a preference does not.

The second failure runs the other way and is more comfortable to fall into. The seat is given, the calendar fills with conversations that produce nothing to show, and the response is to protect the throughput by taking tickets in the gaps. The tickets get done late because the conversations keep interrupting them, and the conversations get half your attention because the tickets are the part that feels like work. Both jobs are performed badly, and the diagnosis almost everyone reaches first — that they are not managing their time well — sends them to a calendar tool for a problem that is really about which of the two they have decided is their output.

Past this point the ladder stops being one line, and the next question is not how much earlier you are asked but which kind of problem gets brought to you at all — what separates senior from staff, and whether that seat exists where you work is a question about the organisation as much as about you.