Ownership and leverage

More tickets and longer hours have a ceiling. Own painful problems nobody owns, fix root causes and make the whole team faster.

Also called extreme ownership, end-to-end ownership

What: Taking responsibility for an outcome from start to finish, including the parts nobody assigned: rollout, monitoring, docs, follow-ups and fixing what breaks.
Why: Managers trust owners with bigger problems. Ownership is what separates delivering a ticket from delivering a result.

Watch out

Considering work done when the pull request merges, not when users get the value.

What: Impact produced per hour of your time. High-leverage work multiplies output beyond your own tasks, such as a tool, a fix or a decision that helps many people.
Why: Your hours are fixed. Choosing high-leverage work is how your impact grows without working longer.
Example: Fixing a flaky test suite that wastes every engineer 30 minutes a day beats shipping one more small feature yourself.

What: Pain everyone feels but no one is responsible for, such as flaky tests, slow builds, painful releases, noisy alerts or a neglected service.
Why: They are visible, affect many people and nobody else is competing for them, which makes them ideal senior-level wins.

Watch out

Fixing one silently on weekends, so nobody knows it was fixed or by whom.

Also called five whys, root cause, root cause fix

What: Finding and fixing the underlying reason a problem happens, often by asking "why?" repeatedly, instead of patching the symptom each time.
Why: Workarounds pile up and cost time forever. Root cause fixes remove whole categories of future problems.
Example: Instead of restarting a service each week, find that a cache never evicts entries and add a size limit with a metric.

Also called prioritisation, prioritization

What: Choosing the few pieces of work with the most impact for the effort, and declining or deferring the rest openly, with reasons.
Why: Senior engineers get more requests than they can handle. Saying yes to everything spreads you thin and delivers nothing well.
Example: I can take the migration if the reporting fix moves to next sprint. Which matters more for this quarter's goal?

Also called automation, internal tooling

What: Scripts, bots and small tools that remove repetitive manual work, such as release scripts, local setup commands or dashboards.
Why: Automation saves time on every future use and removes human error, which is the purest form of leverage.

Watch out

Automating a task that runs twice a year at the cost of weeks of work.

Also called before and after numbers

What: Recording a baseline number before a change, such as build time, error rate or on-call pages, and the same number afterwards.
Why: Numbers turn "I improved things" into evidence your manager and a promotion committee can use.
Example: CI time went from 38 to 11 minutes across 40 engineers, saving roughly 90 engineer hours a week.

What: Preferring the solution with fewer moving parts, dependencies and concepts that still solves the problem.
Why: Simple systems are easier to change, debug and hand over. Choosing boring, proven technology is a senior habit.

Watch out

Adding a new framework or service because it is interesting rather than because the problem needs it.

Go deeper