14.9 — The Ladder, and Staying Employable

The most common wrong model of a career is that seniority means writing more code, faster.

Senior engineers frequently write less code than mid-level ones. What changes is the size of the thing you are trusted with, and how ambiguous it is allowed to be when it reaches you.

1. What actually changes between levels

The two axes that explain every level: scope of impact, and tolerance for ambiguity.

Junior — completes well-defined tasks with support. Learning the codebase, the tools and the team. The signal of a good junior is the quality of their questions, not the absence of them.

Mid-level — owns a feature end to end: design, build, ship, operate. Unblocks themselves most of the time, gives estimates that are roughly right, and reviews others' code usefully. The transition from junior is autonomy on a bounded problem.

Senior — owns a system rather than a feature. Makes design decisions and lives with them. Considers operations, cost and failure modes before the first line. Mentors. And — the underrated part — says no: pushes back on a requirement that will not work, and offers what will.

Staff — impact across several teams. The defining change is choosing what to work on, and much of the work stops being code: a document that gets three teams to agree, a migration that unblocks a roadmap, a prototype that settles an argument.

Principal and above — technical direction across an organisation, on a multi-year horizon. Decisions about what not to build. Sometimes an external presence.

The single sentence that captures the arc: you move from solving problems given to you, to identifying which problems are worth solving.

Two consequences worth stating.

A "senior" title means different things at different companies, sometimes by several years of equivalent experience. Compare the level's described scope, not the word.

And the levels are not a queue. Staff is not "senior for long enough" — it is a different job with a different failure mode, and plenty of excellent senior engineers stay there deliberately, which is a legitimate and well-paid choice.

2. The staff archetypes

Above senior, the role diverges into recognisable shapes, and knowing which one you are being asked to be prevents a lot of frustration.

The tech lead — leads a team's technical direction, closest to the traditional path.

The architect — owns the design of a large area over time, in the sense of Chapter 14.7's documents rather than a diagram in isolation.

The solver — parachutes into the hardest current problem. Wide-ranging, and it depends on an organisation that can point them at the right thing.

The right hand — works directly with leadership on whatever is most important, with the least defined remit.

All four are real, and organisations often want one while advertising another. Ask which.

3. What actually gets you promoted

Scope of impact, not effort. Working harder on a small thing does not promote; making a bigger thing succeed does. This is uncomfortable and it is how it works.

Evidence. "I made the service faster" is unpersuasive; "p99 checkout latency fell from 3.4 s to 400 ms, and support tickets about timeouts stopped" is not. Keep a running note of what you did and what changed — the memory is not there at review time, and the note takes a minute a week.

Visibility, which is not self-promotion. People who do not sit near you cannot see your work. Writing (Chapter 14.7), demos, and being the person who explains something clearly are how the work becomes known. A design document read by four teams is visibility earned by doing something useful.

And the structural fact: promotion is usually recognition of a level you are already operating at. So the route is to take on the next level's work — with your manager's agreement, because doing it invisibly gets you the workload without the recognition. "What would I need to be doing to be at the next level?" is the most useful question you can ask in a one-to-one, and the answer should be specific.

4. The management fork

At senior, a fork appears: the technical track (staff, principal) or the management track.

What an engineering manager actually does: hiring, one-to-ones, performance and growth conversations, unblocking, planning, prioritisation, cross-team negotiation, and the difficult conversations. Writing code is not on that list, and a manager who keeps a critical piece of code is usually doing both jobs badly.

The trade, stated plainly. As an engineer you are a maker: your impact is what you build. As a manager you are a multiplier: your impact is what your team builds, which is larger and much less directly attributable. Some people find that deeply satisfying and some find it hollow, and neither reaction is wrong.

Three things people get wrong about it:

It is not a promotion. It is a different job requiring different skills. Being the best engineer is weak evidence of being a good manager.

It is reversible, more often than people assume. Moving back to an individual contributor role is normal and is not a demotion — though it is easier at companies with a real technical ladder.

The skills overlap less than expected. The hardest parts are giving difficult feedback, hiring well, and holding ambiguity on behalf of a team so they can focus.

Try it before committing — lead a project, mentor formally, run the hiring loop. The signal to look for is whether you find other people's growth energising or draining, because that is the daily experience.

5. Glue work

Some of the most valuable work is invisible: noticing that two teams are building the same thing, writing the document that unsticks a decision, onboarding new people, keeping the runbook current, chasing the dependency that would have blocked a release.

Tanya Reilly's term for it is glue work, and her observation is the important one: it is essential, it is what makes a team function, and it is systematically under-rewarded — because promotion committees look for legible technical achievement. It also falls disproportionately on some people, often along gender lines, which compounds the effect.

Two practical responses.

Make it visible. Write it down, put it in your progress note, name it in one-to-ones. Unnamed work is invisible work.

And balance it deliberately. If all your time goes to glue, you are keeping the team functioning and building no case for progression. Doing some is what makes you a good colleague; doing only it is a career problem you did not choose. A manager worth having will help balance it rather than quietly relying on it.

6. Staying employable: the three tiers

Technology changes fast. Careers are long. The strategy is to know which layer changes slowly and put your investment there.

Tier 1 — the fundamentals that do not expire. Data structures and algorithms (Part 4), software design (Part 9), system design (Parts 10 and 11), data and storage (Part 7), networking (Part 5), security (Part 8).

They last because they are about problems, not tools. How to bound a search space, how to decouple two things that change for different reasons, what consistency costs, how a network fails — these were true in 1995 and will be true in 2045. Every framework that has come and gone was an application of them.

Tier 2 — the platform layer. Cloud (Part 13), distributed systems (Part 10), operations and observability. Durable in concept and vendor-flavoured in detail: the shape of a load balancer, a queue and a container is stable, and the specific product names and consoles are not. Learn the concept; treat the console as a lookup.

Tier 3 — the fast layer. AI engineering (Part 12), current frameworks, whatever is new. High leverage right now and fastest to change.

The rule: invest deeply in Tier 1, work fluently in Tier 2, and learn Tier 3 just in time.

And notice that Tier 3 has its own Tier 1 inside it. The API surface of a model provider will change repeatedly. Evaluation, retrieval design, cost and latency modelling, failure handling, and knowing what a probabilistic component does to a system — those are the durable parts, and they are the parts Chapter 12.6 spent its time on for exactly this reason.

7. What AI assistance changed, honestly

It shrank the tasks that were mostly typing: boilerplate, first drafts of well-understood code, translation between languages, reading unfamiliar code (Chapter 14.4).

It did not shrink understanding the problem, choosing a design, integrating with an existing system, debugging something subtle, reviewing, or deciding what to build.

Three career consequences, stated without either panic or dismissal:

The entry-level bar rose. Tasks that used to be a junior's apprenticeship are now generated in seconds. The way in is to be able to do the things that did not shrink, which means building complete systems rather than exercises, and developing judgement about what is wrong with generated code.

Review and judgement became more valuable. More code is produced and it still needs someone who knows whether it is right. The bottleneck moved from writing to knowing.

Taste became the differentiator — knowing which of three working approaches to choose, and why. That comes from having lived with the consequences of your own decisions, which is an argument for staying somewhere long enough to see them play out.

The practical response is not to avoid the tools. Use them, and make sure you can explain everything you ship. The failure mode to avoid is shipping code you do not understand, because the day it breaks you own it either way.

8. Depth, breadth and how to learn

The T-shape holds up: one area of genuine depth, broad literacy across the rest.

Depth is what makes you the person to ask. It is also what teaches you how deep any subject goes, which transfers — someone who has gone deep once knows what "I understand this" actually feels like.

Breadth is what lets you design systems and talk to other specialists. This book is breadth with depth available.

How the learning actually works:

Build things. A project you finish teaches more than five courses you complete. Finish is the operative word — the last 20% is where the real learning is, because that is where the edge cases live.

Read code. Open-source projects you use. This is the most under-used learning resource available, and it is how you learn what good looks like in a real codebase rather than a tutorial.

Teach it. Writing an explanation, or explaining to a colleague, tests understanding in a way that reading cannot fake. If you cannot explain it simply, you have found the gap — and this book exists on that principle.

Space the repetition. Reading something once produces recognition, not recall. Coming back to it after a gap is what makes it durable, which is why every page here ends with a recall box and self-test questions.

Learn from failure deliberately. Postmortems (Chapter 14.6) — yours and other people's — are concentrated experience. Public incident write-ups from large companies are free lessons in what actually breaks.

9. Sustainability

Burnout is not working too hard for a week; it is prolonged demand with no control and no recovery, and the reliable predictors are lack of autonomy, unclear expectations, effort with no visible outcome, and being permanently on call.

What genuinely helps: on-call rotations wide enough to be humane and follow-up work to reduce the pages (Chapter 14.6's detection action items), the ability to say no with a reason, recovery time after a crunch, and finishing things — shipping nothing for six months is corrosive in a way that hard work is not.

And the long game. A career is forty years. The engineers who are still excellent at fifty are the ones who kept learning and did not spend themselves at thirty. Sustainable pace is not a lack of ambition; it is the strategy with the best expected outcome.

10. Staying and leaving

Move when you have stopped learning and the situation will not change, the compensation is materially below market and cannot be corrected, you do not respect the leadership, or the work is not the work you want.

Stay when you are still learning, you have earned enough trust to work on interesting things, and — the one people undervalue — you have not yet lived with the consequences of your own decisions.

That last point is worth insisting on. Building something, operating it, watching it break, and fixing what you got wrong is where design judgement comes from. Leaving every eighteen months means never receiving that feedback, and it shows: engineers who have only ever built systems and never maintained them make characteristic mistakes.

On compensation, briefly — base, bonus and equity, within a band per level, benchmarked against the market. The largest single increases usually come from changing jobs or changing level, which is a fact about how bands work rather than a recommendation to move. Chapter 14.10 covers negotiation.

And keep a record of what you did, continuously. Not for a CV — for the moment someone asks what you have accomplished and the honest answer is that you cannot remember eight months of work. A line a week is enough.

Recall

• Levels are scope of impact and tolerance for ambiguity, not code volume. Junior (well-defined tasks, good questions) → mid (owns a feature) → senior (owns a system, and says no) → staff (chooses what to work on, aligns teams in writing) → principal (multi-year direction). The arc: from solving given problems to identifying which are worth solving.
• Staff has archetypes — tech lead, architect, solver, right hand. Ask which one is wanted. Staff is not "senior for longer"; staying senior is a legitimate choice.
• Promotion follows scope, evidence and visibility, and is usually recognition of a level you already operate at. Keep a weekly note, and ask what specifically the next level requires.
• Management is a different job, not a promotion — maker versus multiplier — and it is reversible. The signal is whether other people's growth energises or drains you.
• Glue work is essential and systematically under-rewarded, and falls disproportionately on some people. Make it visible, and balance it deliberately.
• Tier 1 (algorithms, design, systems, data, networking, security) does not expire because it is about problems, not tools. Tier 2 (cloud, distributed, operations) is durable in concept and vendor-flavoured in detail. Tier 3 (AI, frameworks) is learned just in time — and Tier 3 has its own durable core: evaluation, retrieval design, cost and failure modelling.
• AI shrank typing, not understanding, design, debugging or review. The entry bar rose, judgement became the bottleneck, and taste is the differentiator — which comes from living with your own decisions. Never ship code you cannot explain.
• Learn by finishing projects, reading real code, teaching, and spaced repetition. Burnout is prolonged demand without control or recovery. Stay long enough to maintain what you built — that feedback is where design judgement comes from.

Self-test: What are the two axes that define a level? · Which archetype is being described when a role has no defined remit? · Why is promotion usually recognition rather than a change? · What is the daily-experience signal for the management fork? · Which tier should you learn just in time, and what is durable inside it? · What do engineers who never maintain their systems get wrong?

Next: 14.10 closes the volume with the interview itself — what each round is actually testing, how to prepare using the rest of this book, and how to answer the questions that are not about code.