Mid-level to senior cheat sheet

1. 1Seniority as scope, with a clear barSeniority is how much ambiguity and responsibility you handle without being told what to do. Find out what the next level means where you work.8 concepts

   1. 1ScopeThe size of the problems you are trusted with and the area your decisions affect: a task, a feature, a system, a team or several teams.
   2. 2Handling ambiguityTaking a vague problem, such as "checkout feels slow", and turning it into clear goals, questions, options and a plan without someone breaking it down for you.
   3. 3Impact over outputJudging work by the difference it made to users, the business or the team, rather than by the amount produced, such as tickets closed or lines written.
   4. 4Level frameworkA company document describing each engineering level through expectations across areas such as technical skill, delivery, collaboration and impact.
   5. 5Gap to the next levelAn honest comparison of your recent work against each expectation of the next level, noting where you already have evidence and where you have none.
   6. 6Written expectationsA short document agreed with your manager listing what you need to show for the next level, with concrete examples of work that would count.
   7. 7Monthly progress check-insA regular slot, often part of one-on-ones, to review evidence against the written expectations and adjust what to work on next.
   8. 8Performing at the next levelThe common rule at many companies that you are promoted after you have consistently done the work of the next level for a period, often six months or more.

   8 in this chapterOpen this chapter
2. 2Ownership and leverageMore tickets and longer hours have a ceiling. Own painful problems nobody owns, fix root causes and make the whole team faster.8 concepts

   1. 1OwnershipTaking responsibility for an outcome from start to finish, including the parts nobody assigned: rollout, monitoring, docs, follow-ups and fixing what breaks.
   2. 2LeverageImpact produced per hour of your time.
   3. 3Unowned problemsPain everyone feels but no one is responsible for, such as flaky tests, slow builds, painful releases, noisy alerts or a neglected service.
   4. 4Root cause over workaroundFinding and fixing the underlying reason a problem happens, often by asking "why?" repeatedly, instead of patching the symptom each time.
   5. 5Prioritisation and saying noChoosing the few pieces of work with the most impact for the effort, and declining or deferring the rest openly, with reasons.
   6. 6Automation and internal toolingScripts, bots and small tools that remove repetitive manual work, such as release scripts, local setup commands or dashboards.
   7. 7Measuring before and afterRecording a baseline number before a change, such as build time, error rate or on-call pages, and the same number afterwards.
   8. 8SimplicityPreferring the solution with fewer moving parts, dependencies and concepts that still solves the problem.

   8 in this chapterOpen this chapter
3. Own the design: write to decideWrite down options, trade-offs and a recommendation so an argument becomes a decision, and record it so the next person knows why.8 conceptsOpens with credits
4. Multiply the people around youYour own output has a ceiling; your team's does not. Review so it teaches, mentor on purpose and unblock people early.7 conceptsOpens with credits
5. Visibility without politicsGood work that leaves no trace is invisible at review time. Record what you did, update your manager and ask for feedback.9 conceptsOpens with credits
6. Influence and choosing your directionGet things done without authority through writing, reasoning and trust, and choose where to go next.7 conceptsOpens with credits
7. 7Glossary, A to ZEvery concept in the sheet and the smaller terms it uses, in one list.114 terms

Scope, ownership, influence.