Tauseef FayyazA to Z
Glossary
Every concept in this sheet, plus the smaller terms it uses. Select a concept to open its card.
A
- Automation and internal tooling
- Scripts, bots and small tools that remove repetitive manual work, such as release scripts, local setup commands or dashboards.
G
- Gap to the next level
- An honest comparison of your recent work against each expectation of the next level, noting where you already have evidence and where you have none.
H
- Handling ambiguity
- Taking 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.
I
- Impact over output
- Judging 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.
L
- Level framework
- A company document describing each engineering level through expectations across areas such as technical skill, delivery, collaboration and impact.
- Leverage
- Impact produced per hour of your time.
M
- Measuring before and after
- Recording a baseline number before a change, such as build time, error rate or on-call pages, and the same number afterwards.
- Monthly progress check-ins
- A regular slot, often part of one-on-ones, to review evidence against the written expectations and adjust what to work on next.
O
- Ownership
- Taking responsibility for an outcome from start to finish, including the parts nobody assigned: rollout, monitoring, docs, follow-ups and fixing what breaks.
P
- Performing at the next level
- The 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.
- Prioritisation and saying no
- Choosing the few pieces of work with the most impact for the effort, and declining or deferring the rest openly, with reasons.
R
- Root cause over workaround
- Finding and fixing the underlying reason a problem happens, often by asking "why?" repeatedly, instead of patching the symptom each time.
S
- Scope
- The 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.
- Simplicity
- Preferring the solution with fewer moving parts, dependencies and concepts that still solves the problem.
U
- Unowned problems
- Pain everyone feels but no one is responsible for, such as flaky tests, slow builds, painful releases, noisy alerts or a neglected service.
W
- Written expectations
- A short document agreed with your manager listing what you need to show for the next level, with concrete examples of work that would count.