Scaling Yourself

Your time is fixed. The org's needs are not. Early on you close the gap by working harder — more hours, more tickets, more fires put out personally. That works until it doesn't, and the point where it stops working arrives sooner than most people expect.

Past that point you cannot scale by adding effort. You scale by increasing leverage — the impact you produce per hour. A staff+ engineer who is still trying to out-work the problem is a senior engineer with a bigger backlog and worse sleep.

The whole job is learning to spend your fixed hours where each one moves the most.

The Leverage Hierarchy

Not all hours are equal. Roughly, in increasing order of leverage:

1. Doing the work. You write the code, you fix the bug. Linear: one hour, one hour of output.
2. Improving how the work is done. Tooling, golden paths, automation, review standards. One hour now saves the team an hour every week.
3. Improving who does the work. Mentoring, hiring, sponsorship, growing people. The compounding lane — capability you build stays built.
4. Changing what work is done. Killing a project, picking the right bet, redirecting a roadmap. The highest leverage and the easiest to get wrong.

As you grow, the center of gravity should move up this stack. A new senior spends most time at level 1. A staff engineer who still spends most time at level 1 has been promoted in title only.

This is not "stop coding." Staying hands-on keeps you calibrated and credible. It's a question of where the marginal hour goes — and the marginal hour of a staff engineer is almost never best spent on the next ticket.

Glue Work

Tanya Reilly's term for the unglamorous work that holds projects together: the coordination, the documentation, the noticing-that-two-teams-are-about-to-collide, the follow-up that turns a decision into a shipped thing. Nobody writes a promo packet about glue work, and most projects fail without it.

A good force multiplier does enough glue work to keep the system running:

• Writing the doc nobody else will write.
• Unblocking the person who's been stuck for three days.
• Noticing the integration nobody owns.
• Keeping the thread alive until the decision actually lands.

But glue work has a trap, and it has to be named honestly:

• It's invisible by construction. It shows up as the absence of disasters, which is hard to point at in a review.
• It expands to fill available time. There is always more coordinating to do, and it crowds out the technical work that gets you promoted.
• It falls disproportionately on women and underrepresented engineers, who get steered into it, praised for it, and then held back because they "haven't shown technical depth." This is a documented, gendered, career-limiting pattern — not a personal failing.

So do glue work deliberately, not by default. Make it visible. Better, make it unnecessary: a template, an owner, a process that does the gluing so a person doesn't have to. If you are senior and the glue work is landing on a junior, that is yours to redistribute.

Sponsorship vs Mentorship

These get conflated constantly and they are not the same thing.

Mentorship is advice: you sit with someone and make them better. Sponsorship is spending your own standing to put someone into a room, a role, or an opportunity they wouldn't otherwise reach — recommending them for the high-visibility project, naming them in the promo discussion, handing them the talk you were invited to give.

Mentorship is necessary and cheap. Sponsorship is scarce and powerful, because it transfers something the sponsored person cannot get for themselves: access. Staff+ engineers are expected to sponsor, not just mentor. If you only ever give advice, you're hoarding the more valuable resource.

Sponsor people who are good and under-seen, especially those who don't self-promote. And sponsor with judgment — your name is on it. For the advice-giving side, see Mentoring.

Multiplier, Not Bottleneck

The fastest way to feel indispensable is to be the only person who can touch X. It is also the fastest way to cap your team's throughput at exactly one of you.

This is the single-point-of-failure trap. If the deploy only works when you run it, if the legacy service only you understand, if every cross-team decision routes through you — you are not leverage, you are a queue. The team can go no faster than your attention, and you cannot take a vacation.

Bus factor: how many people have to be hit by a bus before a critical capability is lost. If the answer for any important system is "one," that's a defect, and if that one is you, it's your defect to fix.

The instinct to fix is exactly wrong. The job is to deliberately work yourself out of jobs:

• The thing only you can do — teach someone, write it down, automate it, until it's no longer true.
• The decision that always routes through you — publish the principles so others can make it without you.
• Measure success by what keeps running when you're out, not by how much breaks.

A multiplier makes the team faster than the sum of its people. A bottleneck makes it slower. Indispensability feels like security; it's a ceiling.

Leverage Through Artifacts

The highest-leverage things you build are the ones that work while you sleep. People scale by headcount; artifacts scale past it.

• Docs — the design doc, the runbook, the "why is it like this" ADR. Answers the question once instead of every time it's asked.
• Tools — a script, a linter rule, a generator. Encodes a decision so nobody has to re-make it.
• Templates and golden paths — the paved road that makes the right thing the easy thing. The strongest scaling move available, because it changes the default behavior of everyone who comes after.
• Automation — anything done by hand more than twice is a candidate. The bot that does the boring correct thing never gets tired or forgets.
• Teaching — a brownbag, a written explanation, a worked example. One hour of preparation, N engineers leveled up, permanently.

The test: does this thing keep producing value when you stop paying attention to it? If yes, it's leverage. If it needs you in the loop forever, it's another job you just gave yourself.

Delegating Without Authority

You have no reports. You still have to delegate, because doing everything yourself is the bottleneck you're trying to escape — and an IC delegates through trust and framing, not through the org chart.

• Delegate via clear problem statements, not task lists. "Here's the problem, here's why it matters, here are the constraints — you own the solution." Handing over the what and the why develops people; handing over only the how develops nobody.
• Delegate via sponsorship. The way you give an IC a stretch project is to get them assigned to it and vouch for them, then stay available without taking the wheel.
• Resist taking the interesting problem yourself. This is the hardest part. The gnarly distributed-systems bug is exactly what you want to grab — and exactly what someone else needs in order to grow into the engineer who can grab the next one. Take the boring problem; sponsor someone else onto the interesting one.
• Let them do it differently. If you delegate the outcome and then dictate the method, you delegated nothing. Different and good beats identical-to-you.

The IC who can't let go stays a high-output individual forever. The one who can becomes a force that produces other high-output individuals.

See Delegation for the manager's version, much of which transfers. And much of this runs on influence without authority — getting things done through people who don't report to you.

Managing Your Own Attention

Leverage is about where hours go, which makes your calendar the real artifact. Most senior engineers leak their highest-value hours into low-value work by default.

• Say no. Every yes is a no to something else; the question is whether you're choosing the trade or letting it choose you. A staff engineer's most undervalued skill is declining the meeting that doesn't need them.
• Protect maker time. The deep technical work — the design, the prototype, the hard read of a system — needs uninterrupted blocks. A day shredded into thirty-minute slots produces no design.
• Pick a few high-leverage bets. You can have outsized impact on three things or mediocre impact on twelve. Diffuse senior engineers are everywhere and remembered for nothing.
• Mind the cost of context-switching. Touching ten projects shallowly isn't ten times the leverage of one; it's the tax of reloading context ten times, paid daily.

If your week is full and you can't name the two or three things it moved, the week was busy, not leveraged.

Sustainability

This role burns people out reliably. The work is unbounded, the impact is diffuse and slow to show, and the most natural failure mode — absorb everything, be the glue, be indispensable — is precisely the one that ends in collapse.

The multiplier who collapses helps no one. A version of you running at a sustainable pace for five years beats a version running flat-out for eighteen months and then gone. This is not a wellness slogan; it's a leverage calculation. You are the asset. Burning it down is the least leveraged thing you can do.

Concretely:

• Sustainable pace is a feature, not a weakness. Heroics that aren't repeatable aren't a strategy; they're a debt with interest.
• Know when to be hands-on vs hands-off. Hands-on for the genuinely critical and the genuinely instructive. Hands-off for everything someone else can own — which, if you've been building leverage, is most things.
• Your unavailability is a test. If the team is fine when you're out, you built leverage. If it's on fire, you built dependency. Take the vacation partly to run the test.

Pre-Commit Question

Before you grab the next task, ask:

Am I the only one who can do this — and if so, is my job to do it, or to make that stop being true?

If you're the only one and you do it again, you just made the ceiling lower.