The Job Nobody Writes Down

The two inputs

There is a clean way to state what the job is, and it has two halves.

The first half is what your organization actually needs from someone operating at your scope. Not what the ladder document says. What is genuinely unowned, genuinely expensive, and genuinely nobody else's.

The second half is what you decide to make of the room you are given.

Your job is the intersection. Below Staff+, the first half dominates and is handed to you; there is a backlog, and doing it well is the job. At Staff+ the second half starts carrying real weight, and that is the shift almost nobody warns you about. Nobody hands you this job description because the job description is partly your output.

This is also why the level generalizes so badly across companies. The same four words on a business card can describe a person who owns a domain for three years and a person who is parachuted into whatever is currently on fire. Both are correct. They are answering different first halves.

The dials

The useful move is to stop asking "what is my job" and start setting specific dials, because dials can be discussed and a vague question cannot.

Four of them do most of the work.

The third one is the quiet killer. Primary focus is the dial people most often leave unstated, because naming it feels like making a demand. It is the cheapest conflict in the world to prevent and one of the most expensive to resolve a year later, when your manager has been evaluating you against a team's delivery while you have been anchoring yourself to a domain that crosses four teams.

None of these dials reset in your favor automatically. A new manager arrives carrying whatever the words meant at their last company. A reorg splits your domain across two directors and leaves you with a scope no single person can approve work inside. Your title does not move. Your job silently does.

Why the same title covers different jobs

If the dials describe the role from the inside, there is a matching view from the outside, and it is worth knowing because it explains what other people expect from you.

Roughly, the shapes are these. Someone guiding the approach and execution of one team or a small cluster, usually paired with a manager who owns the people. Someone owning the direction and coherence of one critical domain over a horizon measured in years. Someone who moves to whatever currently hurts most, rescues it, and moves again. Someone operating with a piece of a senior leader's authority on problems the size of an organization.

They are not a ranking. The last one sounds like the summit and is in fact the most fragile of the four, because it is bound to a single relationship; when that leader leaves, you are an engineer with an unusual calendar and no mandate.

What matters is that each shape makes different evidence count. The team-anchored version is judged on what the team delivered. The domain owner is judged on whether the domain got better and stayed coherent. The rescuer is judged on specific outcomes. Bring rescue evidence to a review that expected domain evidence and it reads as a scattered year rather than a strong one. The fix is not to do different work. The fix is to name the shape, out loud, so the reader is not left guessing.

Looking back at my own history, the shapes were not chosen so much as assigned by whatever the organization needed at the time. The pattern worth naming is that the difficult stretches were not the ones where the work was hard. They were the ones where the shape I was working in and the shape I was being measured against were not the same.

The two ways it goes wrong

The ambiguity that lets you move to the highest-leverage problem without a ticket cuts in the other direction too, and it produces two failure modes that look nothing alike.

The first is the escalation queue. You become excellent at being the person who unblocks things. Everyone is grateful. You are busy every day, visibly useful, and at the end of the year nothing compounds, because rescues rarely leave artifacts behind them. This one is dangerous precisely because it feels good. Gratitude is immediate and cheap; changing a condition is slow and quiet.

The second is invisibility. Because nobody assigned the work, nobody notices when it lands. Multi-quarter work can disappear from the organizational record entirely when the person doing it assumes that quality is self-announcing. It is not. Nothing is.

There is a third, which is drifting into a manager's job with none of a manager's tools and no clean route back. If you find yourself owning scheduling, headcount and interpersonal conflict without the authority or the support structure that a manager gets, that is not a stretch assignment. That is an unpaid second job.

The one page

The concrete practice that fixed more of this for me than anything else is embarrassingly simple.

Write a single page: your scope, your primary focus, what you are accountable for, and, most importantly, what you are explicitly not taking. Then bring it to your manager as a proposal rather than a question, and ask them to edit it rather than approve it.

The edits are the entire point. Approval tells you nothing. Disagreement tells you exactly where the two halves of your job are out of alignment, while the disagreement is still cheap.

A few things make it work:

• Ask your manager what they would say if a peer director asked what you own. The gap between their sentence and yours is your actual work for the next month.
• Prefer the smallest scope that still contains the problem you care about. Scope you cannot genuinely influence is a liability when someone eventually asks what changed.
• Pick an answer to "what are you working on" that a director can repeat accurately in a meeting you are not in. If it does not survive being repeated by someone else, it is not a scope, it is a mood.
• When you cannot get a dial set, name the ambiguity in writing and announce a default. An announced default is easy to correct. A silent guess is not.
• Revisit it after every reorg, every manager change, and every quarter. Scope drifts in both directions, and it drifts fastest when you are busy.

What it is actually for

Here is the version that took me twenty years to be able to say plainly.

In a promotion conversation, in a calibration meeting, in an interview loop, the question is never whether you are a strong engineer. That was settled at the previous level, and it is table stakes now. The question is whether the organization would be measurably worse off without someone operating at this scope, and whether you are visibly that someone.

A role you have defined, written down, negotiated and can state in one sentence answers that question. A role that amounts to "senior engineer, but for longer" does not, no matter how good the code is.

The job description is missing because writing it is part of the job. That is not an oversight in the ladder. It is the first real test of the level.