Work Only You Can Do

In senior technology roles, responsibilities rarely stay within a single lane. They can span technology programs, delivery, recruiting, training, internal tooling, pre-sales, and whatever else the organization needs at the time.

Every one of those areas generates legitimate requests. Each request comes from someone with a valid reason for considering it important. And none of them arrives with a shared queue, a sprint, or someone else deciding which one matters most this week.

That is the structural condition this piece is about. It is not unique to a director title; it is the normal state of any Staff+ role, where demand is unbounded and nothing arrives pre-prioritized. The failure it produces is specific and it does not feel like failure: you are present at everything, decisive at nothing, and at the end of a quarter the only honest description of your time is a list of meetings.

The way out is smaller and colder than I expected.

Effort stopped being the variable

Here is the thing nobody tells you at the transition. Up to senior, the distance between engineers is mostly capability and effort. Above it, everyone in the room is capable and everyone works hard. Effort stops discriminating.

What discriminates is which problems people pointed themselves at.

That sounds like a platitude until you notice the consequence: working harder on the current thing cannot fix having chosen the wrong thing, and no amount of executing well converts a defensible project into the right project. You can have a design doc, a roadmap, real progress, genuine improvement, and still be wrong, because something else in the organization was three times more valuable and nobody was on it.

I find this genuinely uncomfortable, which is how I know it is the real constraint.

Where the hours actually leak

Before the filter, it helps to name where senior attention goes to die. There are three, and all of them feel productive from the inside. That is the whole problem.

Snacking is the small satisfying work you choose because it closes. The tidy refactor, the script, the ticket you can finish before lunch. Each one is defensible; the pattern is the problem. It is most tempting immediately after a hard, ambiguous project, which is precisely when your capacity for the next hard thing is lowest and most needed.

Preening is work that photographs well and changes nothing. The talk about a system you no longer maintain. The working group that meets, produces slides, and touches no code. Preening is worse than snacking in one way: it is rewarded, so the feedback loop reinforces it.

Chasing ghosts is the one I watch for hardest in myself, because anyone who has worked across more than one organization is exposed to it. You spend a long engagement somewhere watching a particular design cause real pain. You carry that scar to the next organization and argue hard against the same design, in a context with different scale, different team boundaries and different constraints. The energy is sincere. The pattern-matching is real. The diagnosis was made somewhere else.

Experience gives you priors. At Staff+ your priors are expensive, because they do not stay private opinions. They become an architectural standard that teams follow for years. The rule I try to hold is that when I feel strongly about a technical direction somewhere I have not been long, the strength of the feeling is a signal to go investigate rather than a signal to go advocate.

The filter

So where should the hours go? There is a short list worth knowing: an existential issue, if one is in flight. An important area with room and attention, meaning a real problem with a vacancy rather than one with a competent entrenched owner. Making other engineers better, which compounds in a way your own output cannot. Finishing things, because value lands at completion and not at eighty percent.

And then the small, strange, high-value one: editing.

Editing is the well-placed intervention in someone else's work. The paragraph that unsticks a design doc. The question that reveals the plan will not survive contact with production. The introduction between two teams solving the same problem who have not met. It is cheap, it is high leverage, and it is nearly invisible, which is exactly why people who could do it go do something showier instead.

I would defend half a day a week spent reading other teams' designs and asking one sharp question as one of the highest-return blocks in a Staff+ calendar. I cannot prove that, and I am not going to pretend I have measured it. It is an argument, and the argument is that the intervention is cheap and the mistakes it catches are not.

The name test

All of that still leaves you with several good options, which brings us to the only filter I have found that actually cuts.

Of the many valuable things you could do this quarter, which ones does your particular position make possible?

Not which are most important. Not which you are best at. Which ones does your specific standing, history, context or relationships make possible that would otherwise not happen.

The operational version is a sentence. For each commitment, write down: this needs me because. Then substitute a different name into it. If the sentence still works with someone else's name in it, that work is delegable, and you are holding it for a reason that is not about the organization.

Applied honestly, the test is unflattering, and it is unflattering in a consistent direction.

Work that survives it tends to be work where your standing is the scarce input: a decision that needs someone with no stake in either team's preference, or a change to how something is done organization-wide that requires enough authority to make it stick. Work that fails it tends to be work you are good at and enjoy, where a name substitution reveals several people who would do it at least as well.

The uncomfortable part is which of those is more fun. The item that passes the test is frequently the one that has been quietly sliding down the list, because it is slower, less concrete, and nobody is standing in your office asking for it.

Every yes is a subscription

The other half of this is arithmetic, and it is the half that is easiest to get wrong.

Staff+ demand is unbounded and your hours are not. Which means you are always saying no. Always. The only question is whether the nos are deliberate or whether they happen by default, and default nos are invisible and expensive: the architecture problem nobody owned because your week filled with reviews, the mentee who stopped asking after the third reschedule, the strategy document that sat at eighty percent for two quarters and then stopped being relevant.

And the cost of a yes is systematically undercounted. Agreeing to "just advise" on a project is rarely the two hours it looks like. It is the standing meeting, the doc reviews, the thread you get pulled into on a Friday evening, and the ambient cost of holding one more context in your head for months. A commitment that looks like a tenth of a week tends to behave like considerably more.

Three practices I would defend:

• Treat every recurring commitment as a subscription with a renewal date. Write down when you will re-evaluate it, or it is permanent.
• Before accepting anything, name what you will stop doing to make room. If nothing comes to mind, you have not accepted it. You have overcommitted and deferred finding out.
• Keep a written list of what you are currently the accountable lead on. Three is a lot. Five means some of them are fiction, and the people depending on the fictional ones do not know yet.

The uncomfortable part

The reason this filter is hard is not that it is complicated. It is that applying it means disappointing competent people who asked you for something reasonable, and doing so on the basis of a judgment you cannot fully prove at the time.

But the alternative is the quarter of shallow presence: exhausting from the inside, and from the outside indistinguishable from low impact, because the only durable record of it is a calendar.

Ten delivered projects that anyone could have delivered is a strong senior year. Two projects that only someone at your scope could have moved is a Staff+ year. The difference is almost never effort. It is the filter, applied earlier than is comfortable.