Take the thing nobody owns

The most staff-level thing I ever did looked, at the time, like volunteering for a problem.

There was a legacy mobile SDK that nobody owned. At risk, no team around it, the kind of thing every organisation has and nobody volunteers for because there is no glory in it and plenty of ways to be blamed.

Fifteen months later it was actively shipping. Along the way came the legacy cleanup and migration, the architecture and review standards, and then rebuilding the team behind it, including hiring and onboarding the engineers who would maintain it.

That reads as a staff-level story, and the reason is not technical difficulty. Plenty of features are harder. It is that the scope included a system nobody owned, a migration, standards that outlived my involvement, and other people's careers.

Here is the part worth internalising. Work at that scope is usually sitting right there, unclaimed, precisely because it is unglamorous. The flaky test suite everyone works around. The service with no maintainer. The build that takes twenty minutes. The module every team touches and nobody reviews.

Nobody is competing with you for it. That is the whole opportunity.

Most engineers wait to be given scope. Scope is rarely given, because giving it requires someone to notice you are ready, and they are busy. It is taken, by writing down what is broken and proposing to own it.

The exercise, and it takes an afternoon.

Find the thing in your codebase or your team that nobody owns. There is always one and you already know what it is.

Write one page. What is wrong. What it costs, in time or incidents or morale, with a number if you can get one. What you would do. What would be true in three months.

Send it to your lead.

Two outcomes and both are good. They say yes, and you now have a staff-shaped story with a beginning, a decision and a result. Or they say no, and you have demonstrated that you think at that altitude, which is the thing being assessed at your next promotion conversation anyway.