/resources/career-growth

Career growth notes for the jump you are trying to make. 📈

Almost every mentorship call I take eventually lands here. Someone is doing good work, has been doing it for a while, and cannot tell whether they are actually growing or just accumulating time. These are the notes I end up repeating, written down so you can come back to them at the next crossroads.

How the ladder actually works

Every company words its ladder differently, but the thing being measured is remarkably consistent. It is not how hard you work or how clever your code is. It is how much of a problem you can be handed and still return something safe.

The ladder measures scope, not years

Levels track how much ambiguity you can absorb and how much of a problem you can own without anyone checking on you. That is why one engineer reaches senior in four years and another sits at mid level for ten. Years are correlation. Scope is the actual variable.

Scope has three parts: the size of the problem, how undefined it arrives, and how many people your decisions affect.
A useful self test: if your manager disappeared for six weeks, which of your projects would stall and which would keep moving?
Nobody gets promoted for doing more hours at the same scope. That road leads to being tired at the same level.

Junior: the task is defined, the correctness is yours

At the first level someone else decides what needs building and roughly how. Your job is to make it genuinely work, learn the codebase and the tools, and get good at asking early instead of guessing for two days.

A Tuesday looks like: a ticket with acceptance criteria, two rounds of review feedback, and a clarifying question in the team channel before lunch.
The skill to build here is not speed. It is finishing properly: tests, edge cases, and a pull request description someone can review without booking a call.
Asking for help after thirty focused minutes of being stuck is a strength signal. Silently burning three days is the actual failure.

Mid level: the feature is yours end to end

Mid level engineers are the people who reliably turn a written requirement into working, shipped software. You need less direction, your code lands with light review, and you can break a feature into tasks and sequence them yourself.

A Tuesday looks like: taking a product requirement, writing the technical approach yourself, splitting it into tickets, and telling the team the moment your estimate slips.
You still mostly get told what to build. The difference from junior is that nobody has to tell you how.
The trap here is comfort. Shipping features competently for four years produces an excellent mid level engineer, not a senior one.

Senior: the problem is yours, including the undefined parts

This is the first level where your responsibility is larger than one person can deliver. Something vague arrives, and the work now includes deciding what it means, who else needs to be involved, and what you are deliberately not building.

Mid level sounds like: build the notification service to this spec. Senior sounds like: users are missing important updates, work out why, fix it, and tell us what it costs.
A Tuesday looks like: a design doc in review, two conversations that unblock other people, a scope cut you argued for, and maybe three hours of your own code.
The measurable version: you own something spanning weeks or months with two or three engineers on it, and the people above you stop asking for status because you send it first.
You catch problems in the requirements, not only in the code. The most valuable senior review comment is often that we should not build this at all.

Read your ladder like a spec, then diff yourself against it

Most companies have a written ladder, and most engineers have never carefully read the level above their own. It is the closest thing you have to a rubric, and it usually says something more specific than you expect.

Copy out the next level. Mark each expectation green if you have evidence, amber if you have done it once, red if you have never done it.
Take the reds to your manager and ask which two matter most this year. You do not have to be strong at all of them.
No written ladder at your company? Borrow a public one. Several companies publish theirs and the shape is similar enough to be useful.

A promotion is a lagging indicator, not a reward

Committees are not asking whether you are good at your current job. They are asking whether you have already been doing the next one, visibly, for long enough that promoting you is not a risk. Six to twelve months of sustained evidence is typical, and longer at staff and above.

This inverts the usual instinct. You do not get the scope because you were promoted. You get promoted because you took the scope and it went fine.
So the useful question is not whether you are ready. It is which next level work you are doing right now, and who has watched you do it.

If you cannot name the scope you own in one sentence, that is your growth problem, and no amount of extra output will fix it.

Past senior: staff, principal, or management

Senior is the last level most companies will actively push you toward. After that the escalator stops and you have to choose a direction, because the paths genuinely diverge.

Above senior, nobody is driving but you

Until senior there is usually a system pulling you along: a manager with a growth plan, a ladder, a review cycle that nudges. Past that the company mostly stops needing you to level up, so promotion becomes something you propose and build a case for rather than something that arrives.

A meaningful share of staff engineers, roughly a third by some counts, got the title by changing companies rather than being promoted internally. That tells you how often the work simply is not available where you are.
The practical consequence: you need a written plan and at least one sponsor, not just good review ratings.

Four shapes that staff level work tends to take

It helps enormously to know which kind of staff engineer you are trying to be, because the day to day differs completely and so does the evidence you need. Four shapes come up again and again, and they are worth naming out loud with your manager.

Tech lead: you set direction and execution for one team, paired closely with its manager.
Architect: you own the technical direction and quality of one critical area, on a multi year horizon.
Solver: you get dropped into the hardest current problem and find a path through it.
Right hand: you extend a senior leader's scope and work on whatever the organization most needs this quarter.
Ask which of these your company actually promotes. Some only really reward one, and finding that out early saves you a year.

Three things staff work is made of

Underneath the archetypes the job breaks into big picture thinking, execution across team boundaries, and levelling up the people around you. Most engineers arrive strong in one of the three and have to build the other two on purpose.

Big picture: you can see past what is locally optimal for your team and say what the right answer is for the whole system in two years.
Execution: you can drive something involving four teams that no single manager owns, and keep it from quietly dying.
Levelling up: the engineers near you get measurably better, and other people say so without you prompting them.

Management is a change of profession, not a promotion

This is the most useful reframe I can hand you. Moving into management is a lateral move into a different job with a different skill set, and you will be bad at it for a while. If you want it mainly for the status, both you and your team are in for a miserable year.

The work becomes hiring, performance, prioritization, and unblocking. Your output is now other people's output.
You will write far less code, and your feedback loop stretches from hours to quarters. Some people find that genuinely unbearable.
Do it if the people part energizes you on a bad week, not because it looked like the next box up.

Switching tracks is normal, and there is a shelf life

Plenty of strong engineers move between the individual contributor track and management more than once. The best frontline managers are usually the ones who have not been away from hands on work for long, and two or three years away is roughly where technical context starts to rot.

If you try management and hate it, going back is not a demotion. It is expensive information you now own.
If you stay in management, protect some technical contact: read designs, review code, take part in incidents. Just do not put yourself on the critical path.

Test the management question cheaply first

You do not have to guess about this. Almost every management responsibility has a smaller version you can try inside your current role, usually within one quarter.

Lead a project with three other engineers on it, including the part where you tell someone their approach will not work.
Onboard the next new joiner properly and notice whether their progress feels as satisfying as your own shipping.
Run your team's interview loop for a month and write the debriefs.
Cover for your manager while they are on leave: run standups, own priorities, handle the one awkward conversation.
Then ask honestly which parts you looked forward to. That answer is far more reliable than any career quiz.

Pick the track that matches what you want to be doing all day, not the one with the shorter path to a bigger title.

What ownership looks like on a Tuesday

Take ownership is the least useful advice in this industry, because nobody ever says what it means at 11am on an ordinary working day. So here is the concrete version.

You are the person who notices

Ownership is mostly noticing things that are technically not your problem, then either fixing them or making sure the right person knows. Nobody hands this to you. It is a habit you build one small annoyance at a time.

The deploy has failed intermittently for a week and everyone just reruns it. You spend Tuesday afternoon finding out why, then write it up.
The requirement says users can export data and never says what happens at a hundred thousand rows. You ask before you build, in writing, on the ticket.
A teammate has been quiet in standup for four days. You message them directly instead of waiting for a manager to notice.
The runbook you followed at 2am was wrong. You fix the runbook before you close the incident, not next sprint.
You promised an answer by Thursday and you now know you will miss it. You say so on Wednesday morning, with a new date attached.

Output is what you did, impact is what changed

This is the single biggest rewrite most mentees need, and it improves their performance reviews, their resumes, and their promotion cases at the same time. Nobody senior is impressed by volume. They are looking for consequences.

Output: migrated the payments module to TypeScript. Impact: cut payment related production incidents from about four a month to under one, which is a number the on call rotation actually felt.
Output: wrote sixty unit tests. Impact: made the checkout refactor safe enough to ship in one week instead of the quarter we had budgeted.
Output: mentored two juniors. Impact: both now ship features without design review from me, which gave the team back a reviewer.
If you genuinely cannot state what changed, you may have done work that did not matter. Better to learn that now than in a calibration room.

Write the thing down before you build it

The habit that moved me fastest was writing a short document before starting anything longer than a week. It is not bureaucracy. It converts a private opinion into something people can disagree with cheaply, while the code does not exist yet.

Keep it to two pages: the problem, who has it, the proposal, two alternatives you rejected and why, the risks, and what you are explicitly not doing.
Name the tradeoff out loud. If we optimize for shipping speed here, we accept these rough edges and we instrument them.
Circulate it before you are attached to the answer. Comments on a draft are free. Comments on a merged pull request are expensive.
This document quietly becomes promotion evidence later, with a date on it and other people's names in the margins.

Finish the unglamorous last ten percent

The gap between an engineer people trust and one they do not is almost never the hard part of the problem. It is whether the loose ends got tied. Half finished work becomes somebody else's tax, and they will remember.

Checklist before you call it done: docs updated, dashboard or alert in place, runbook entry written, feature flag removed, old code path deleted, data backfilled.
A migration is not finished when the new system works. It is finished when the old one is switched off and deleted.
If you leave the last ten percent for the team every time, you earn a reputation you cannot see and nobody will tell you about.

Say the risky true thing early

A large part of senior judgement is being willing to say the uncomfortable thing while it is still cheap to act on. The estimate is wrong. The requirement contradicts itself. This project should be cancelled.

Say it with a proposal attached. I think this slips by three weeks, and here are two things we could cut to hold the date.
Say it where the decision lives, in writing, not only in a private message. A written assumption beats a silent guess.
Say it once, clearly, then support whatever gets decided. Being right and unpleasant about it is a career ceiling all by itself.

Ownership is not a mindset. It is a set of small Tuesday behaviors that other people can observe.

The paper trail that gets you promoted

Undocumented work is invisible work. That is not a conspiracy, it is just how memory works: your manager is tracking six or eight people and cannot recall what you shipped in March any better than you can.

Keep a brag document, and update it badly every Friday

One file, one heading per month, ten minutes on a Friday. This is the highest return per minute habit in your whole career, and almost nobody keeps it up, because it feels self indulgent in month one and obviously essential in month nine.

Categories worth keeping: projects and their outcomes, design docs and writing, people you helped or reviewed or mentored, process and tooling improvements, things you learned, and anything outside work such as talks or open source.
Write the metric down while you still have access to the dashboard. Six months later the query is gone and the number becomes roughly better, which persuades nobody.
Record other people's names. A case is far stronger when a reviewer can be told exactly who to go and ask.
Bad entries are fine. Fixed the flaky deploy, saved the team an hour a week, is a real entry. Polished prose can wait for review season.

Turn entries into evidence, not a diary

The document only pays off if each entry carries the change and not just the activity. When review season arrives you want to be copying and pasting, not reconstructing a year from your calendar.

Weak: worked on the search rewrite. Strong: led the search rewrite with two engineers, took p95 latency from 1.8s to 400ms, and wrote the design doc three other teams later reused.
For each entry note the scope in one word: was this your task, your feature, your project, or something across teams? That word maps directly onto the ladder.
Include the failures, with what you changed afterwards. Senior people are trusted partly because they narrate their own mistakes accurately.

Your promotion packet is written for strangers

At most companies of any size the decision happens in a calibration meeting where your manager argues for you in front of five to eight peers, half of whom do not know your name. Your job is to make their argument easy to defend by people who have never seen your work.

Structure it as three or four projects, each with the problem, what you decided, what changed as a result, and who else was involved.
Map each project explicitly onto the ladder language for the level you want. Never make the reader do the translation for you.
Lead with the strongest project. Committees do not read carefully all the way to the end.
Add one line on breadth: work across teams, mentoring, incidents you led. A single project rarely carries a case on its own.

Numbers you can defend beat adjectives you cannot

Vague superlatives get discounted the moment they are read. A modest number with a traceable source survives scrutiny, and surviving scrutiny in a room you are not in is the entire game.

Prefer before and after pairs with a date range: incidents per month, p95 latency, build time, support tickets, conversion, days to onboard.
With no metrics available, use time saved and show your arithmetic. Six engineers, two hours a week each, is defensible.
Never claim revenue you cannot trace. One inflated number makes a reviewer distrust the entire packet.

Write it down while it is happening. Nobody has ever reconstructed a good promotion case from memory in the last week of a review cycle.

Working with your manager

Your manager is the highest leverage relationship in your career, and most engineers underinvest in it wildly, treating a weekly half hour as a status meeting to be endured.

The one on one is your meeting, so bring an agenda

It exists for you, not for status reporting, because your manager can read the board. If you turn up with nothing, you will get a pleasant and useless catch up about how things are going, every week, forever.

Keep a shared running doc and add items during the week as they occur to you, so you are not inventing an agenda in the first minute.
A workable shape for thirty minutes: one thing going well and why, one thing you are stuck on and what you want from them, one question about direction or priorities.
Be explicit about what you want: a decision, an introduction, air cover, or just to be heard. Managers guess wrong constantly when you do not say.
Some weeks you need to vent about something frustrating, and that is a legitimate use of the slot. Say up front that you are not looking for a fix.
Never park an urgent problem until the next one on one. The meeting is a floor, not a queue.

Ask what is missing, not when you will be promoted

Asking when you will be promoted puts your manager on the defensive and invites a vague answer. Asking for a gap analysis gets you a list, and a list is something you can actually act on.

The opener: here is the work I believe is at the next level. Where are the holes?
The commitment question: what would you need to see from me over the next two cycles before you would be willing to write my case?
The reality question: is there room at that level in our group this year, and if not, where in the company is there?
The blunt one: if the decision were made today, what would the strongest objection to me be?
Bring three or four concrete examples with you. Without them the conversation stays abstract and nothing changes.

Get the answer in writing, then recalibrate quarterly

A verbal understanding in April is worth close to nothing in November, because the two of you will remember it differently and one of you may not still be in the same role. Write the summary yourself and send it.

After the conversation send a short note: here is what I heard, here is what I will do, here is what you said you would do. Ask them to correct anything.
Revisit it once a quarter against the work you actually did, not the work you planned to do.
If the goalposts move twice with no new information, that is data about the situation rather than about you.

Tell them the bad news first

The fastest way to build a manager's trust is to be the person who surfaces problems before the problems surface themselves. It feels risky and it is the opposite of risky. Surprises are what damage confidence in you.

Flag a slipping estimate the day you believe it, not on the deadline.
When you break something, lead with the impact, the current status, and what you need. The explanation can come afterwards.
Never let your manager hear about your work from someone else first.

A manager change resets the clock

Reorgs happen constantly, and a new manager arrives with no memory of your last two years and no personal stake in a promise someone else made. This is the most common way a promotion quietly evaporates.

In the first two weeks, send them your brag document and ask for thirty minutes to walk through what you own.
Ask directly what they were told about you, and what they understand the team's promotion pipeline to be.
Establish the written expectations again from scratch. Assume nothing transferred, because usually nothing did.
If your old manager was your advocate, work out who else can vouch for you now, and start there.

Manage this relationship deliberately. A good manager makes your growth much easier, and no manager can advocate for work they never heard about.

Feedback, sponsorship, and being seen

Mentorship gets talked about constantly and sponsorship almost never, which is unfortunate, because sponsorship is the one that changes what actually happens to you.

Mentors give advice, sponsors spend their own credibility

A mentor tells you what they would do. A sponsor puts your name into a room you are not in and takes a personal hit if you disappoint. You need both, and most people only ever ask for the first.

What sponsorship looks like in practice: recommending you to lead a project, nominating you to present at a wider forum, forwarding your write up with context on why it matters, telling your manager unprompted that your work was strong, naming you as the person who solved something in a room where decisions get made.
Sponsorship transfers opportunity, mentorship transfers information. Plenty of advice and no new opportunities means you have a sponsorship gap, not a skills gap.
Sponsors are usually not your manager. They are people one or two levels up who have watched you finish something difficult.

How to earn sponsorship, and how to ask for it

You cannot ask a stranger to stake their reputation on you. You earn it by being visibly reliable on something they care about, then you make the specific ask small enough to say yes to.

Do one thing exceptionally well for someone senior and finish it completely. That is the entire prerequisite.
A workable ask: I am aiming for the next level this year. Would you keep me in mind when a project at that scope comes up?
A smaller ask that lands more often: the review committee will not know my work. Would you be willing to write two paragraphs about the migration?
The easiest one of all: could you introduce me to whoever owns this decision?
Then make them look good. Sponsorship only compounds when the person who vouched for you is glad they did.

Ask for feedback people can actually answer

Asking whether anyone has feedback for you reliably produces nothing, because the question is too open and volunteering criticism is socially expensive. Narrow it until answering is easy and low risk.

Instead of asking for any feedback: what is one thing I could have done differently in that design review?
For growth: if you were arguing against my promotion, what would you say?
For a specific skill: was my write up clear enough that you could have made the decision without asking me anything?
Ask within a day or two of the event, while the memory is still specific.
Then say thank you and do something visible about it. People quietly stop giving feedback to anyone who argues with it.

Make your work legible, not louder

Visibility is not self promotion. It is reducing the effort someone else needs to understand what you did and why it mattered. That is a service to your colleagues, and it happens to be how careers move.

Send a short update to your team channel every week or two: shipped, in progress, blocked, decisions made. Three or four lines is plenty.
Demo things. A two minute recording of a working feature travels further inside a company than any status document.
Write pull request descriptions and incident write ups that a stranger could follow six months from now.
When you fix something painful, say what the pain was and that it is gone. People rarely notice the absence of a problem.
Take the visible unglamorous jobs: run the postmortem, own the on call handover, write the summary nobody volunteered for.

Give credit first, and avoid volume without substance

The engineer who names the people who helped, and who privately keeps the list of what they actually shipped, is the one who ends up trusted. The failure mode at the other end of this is real and it limits careers.

Say who did what, specifically, in public. It costs you nothing and almost nobody does it.
Do not tour your work around leadership while peers quietly cover your unfinished edges. That reputation reaches the calibration room too.
Alienating your peers to get promoted is a bad trade, because those same peers write your feedback next cycle.

Advice is cheap and widely available. Opportunity is not, so build the relationships that create it before you need them.

Choosing work that compounds

Across five years, which projects you pick matters more than how well you execute them. This is where most careers quietly stall: excellent work on things nobody was ever going to care about.

Three questions before you say yes

You will not get to choose everything, but you will get to choose something a few times a year, and those choices set the trajectory. Run every optional project through the same short filter.

Will anyone above my manager hear about this?
Will there be a number at the end that shows whether it worked?
Does it require me to operate at the scope of the level above mine?
Two yeses out of three makes it worth pushing for. Three noes means it is probably necessary maintenance, and you want to know that going in rather than discovering it at review time.

Glue work is real work and it is systematically underpriced

Holding a team together, onboarding, unblocking, keeping designs aligned, chasing the thing across three teams: this is frequently why a project succeeded, and it is routinely absent from promotion decisions. The research here is uncomfortable. This work lands disproportionately on women and on people from underrepresented groups, both because they volunteer for it more and because managers assign it to them more.

Ask your manager directly whether this work counts toward the next level at this company. The answer is sometimes no, and you deserve to know before another year goes by.
Get a title that frames it as leadership, such as technical lead for a specific project, so the work reads as scope rather than helpfulness.
Leave artifacts behind: a plan, a design doc, meeting notes with the decisions and your name attached. Verbal glue work is invisible glue work.
If your promotion has stalled and your calendar is all glue, deliberately drop some of it for a quarter and block time for a technical deliverable. That advice is unfair, and it also works.

Depth in one area beats a tour of the toolbox

Early on, breadth is genuinely useful and you should try things. After a few years the compounding comes from being the person others come to about something specific, because reputation attaches to a recognizable shape rather than a list.

Pick one system or domain and go deeper than strictly required: how it fails, what it costs, its history, why the odd decisions were made.
The skills that keep paying are unglamorous: reading a stack trace without ego, tracing a bug across services and naming which layer lied, knowing when a library saves time and when it hides learning you still need.
Frameworks turn over every few years. Judgement, debugging, and writing do not.

Learn the business, not just the stack

The fastest change in how seriously people take you comes from understanding how the company makes money and what your team does to that number. It is also the shortest route to better project choices, because you stop guessing what matters.

Find out which metric your team is judged on this quarter and who reports it upward.
Read the last two quarterly updates or all hands decks. Most engineers never do, and it is sitting there internally.
Sit in on a support or sales call. One hour of hearing real users complain will reshape your prioritization instincts more than a year of tickets.
Then propose something. A proposal that names a real business problem gets funded far more often than one that names a technical annoyance.

Ask what this project will let you claim in eighteen months. If the answer is nothing, do it well, do it quickly, and go and find something else.

The parts of promotion nobody explains

Most career advice implies the process is a fair function of your performance. It is not, and seeing that clearly is what keeps you strategic rather than bitter.

The decision happens in a room you are not in

Your manager takes your case into a calibration meeting and defends it against candidates from other teams, in front of people who have never worked with you. They are not evaluating you. They are evaluating a document about you.

This means writing quality matters. A clear, evidenced two pages beats better work described vaguely.
It also means your manager's own credibility and political capital matter. A well regarded manager who argues well is a genuine advantage that has nothing to do with your work.
You cannot attend, so build a case that survives without you there to explain it.

Budget and headcount cap the outcome

There are often only so many slots at a level in a given cycle, and at senior and above there may be a fixed number of positions the organization will fund. You can meet the bar completely and still be told not this cycle.

The honest question for your manager: how many promotions at this level does our group expect to make this cycle?
In a hiring freeze or a cost cutting year, the effective bar quietly rises. Nobody announces this.
Being told you met the bar but there was no room is often literally true rather than a euphemism. It should change your plan, not your self assessment.

The work you need may not exist where you sit

The most common reason strong engineers stall is not capability. It is that their team simply does not have problems the size of the next level, and no quantity of excellence on small problems adds up to large scope.

Some teams and locations structurally get more opportunity: platform and infrastructure work, teams close to revenue, and offices where the decision makers actually sit.
If you have been excellent for two years on well defined work and nothing bigger is coming, the answer is a different team, not more effort.
Ask your manager to name the next staff level problem on this team. If they cannot, you have your answer.

The bar is not applied evenly

Timing, reorgs, who your manager reports to, whether your project succeeded for reasons outside your control, and plain bias all move outcomes. The pattern shows up in the data: among staff engineers, women were considerably more likely to have needed a company change to reach the title.

Someone less capable than you will be promoted before you at some point. That is evidence the process is noisy, not that the game is unwinnable.
A cancelled project is not your failure, but you will have to narrate what you learned and what you salvaged, because the outcome column will look thin.
If you are consistently the one doing invisible work that others present, name that pattern to your manager. Not as a complaint. As a scope conversation.

What to actually do about the unfairness

You cannot fix the system from mid level, but you can stop paying its full price. Almost everything inside your control reduces to evidence, sponsors, and a willingness to move.

Control the evidence: written, dated, with numbers and names in it.
Build more than one sponsor, so a single reorg cannot delete your advocacy.
Keep your outside option warm: know your market rate, keep your resume current, take an occasional interview even when you are happy.
Set yourself a deadline. If nothing has changed in two more cycles, you will look elsewhere. A deadline converts resentment into a decision.

Play the game as it actually runs rather than the one described in the handbook. Knowing the rules is not cynicism, it is just paying attention.

Stay, switch teams, or leave

This is the question mentees bring me most often, usually phrased as should I quit, when the real answer is frequently a different team at the same company.

Signals you are ready for the next level

Readiness is observable, and it looks similar everywhere. If most of these are true, have the promotion conversation now rather than waiting until you feel ready, because that feeling arrives late or never.

People bring you problems before they are well defined, instead of bringing you tickets.
You get asked to review designs outside your immediate area.
New joiners get productive faster because of something you built or wrote.
You have said no to a piece of scope and the decision held.
You describe tradeoffs in terms of the business, not only the code.
Your manager's manager knows what you are working on without your manager telling them.

Try the internal move before the external one

Switching teams keeps your relationships, your context, and your hard won understanding of how the company really works. It is the cheapest way to change your scope, and it is underused mostly because asking feels awkward.

Start with your own manager. Most reasonable managers would much rather keep you in the company than lose you entirely.
Talk to two engineers on the target team about what the work is really like before you commit to anything.
Ask what the biggest unowned problem on that team is. Arriving with a candidate scope is far stronger than arriving available.
One warning: an internal move usually resets your promotion clock a little, because a new manager needs time to see your work.

Signals it is genuinely time to go

Look for the durable ones, the patterns that survive a change of project, a change of manager, and one good quarter. A hard month is not a signal. A flat three years is.

Your responsibilities and your compensation have both been flat for two years while your skills grew.
There is no problem on the horizon at the scope you need, and no internal team that has one.
You have asked for the gap analysis twice and got something vague both times.
You no longer respect how decisions get made, and you have already said so to the people who could change it.
You are cynical about work you used to care about, and it is not lifting between projects.
The person you would become by staying two more years is not someone you want to be.

The money math is real, and noticing it is not disloyal

Merit budgets in technology usually land somewhere around four percent in a normal year, with a promotion adding a step on top. Changing companies has for years produced considerably larger jumps, often in the low to mid teens as a percentage, though that swings a lot with the market.

Over a decade that gap compounds into something large. Staying somewhere you are underpaid is a decision with a price tag, not a neutral default.
Moving is not free either. You lose context, unvested equity, and the trust you spent years building. Those costs are real and rarely counted.
The healthiest pattern I see is not constant hopping. It is staying while the learning is steep, and leaving when it flattens and no internal option fixes it.

Timing matters more than people admit

Two mistakes I watch people make repeatedly. Leaving weeks before a decision that was genuinely going to land, and staying two extra years on a promise with no date attached to it.

If a case is really in flight, ask when the decision lands and get that date in writing. Then choose with a real date in hand.
If the answer keeps being next cycle with no specifics, treat the third time as a no.
Do not resign in the emotional aftermath of one bad review. Interview first. An offer changes the conversation, and sometimes your current job looks different once you know you have options.

Leaving is a tool, not a verdict on anyone. Use it when the scope you need does not exist where you are.

Money, said plainly

Compensation is the topic mentees are most embarrassed to raise and least informed about, which is an expensive combination.

Know your number before you need it

You cannot negotiate a range you have never researched, and the person across the table has data on hundreds of offers while you have exactly one data point, which is your own current salary.

Gather at least three sources: public compensation databases filtered by level and location, recruiter conversations, and people you trust who will tell you real numbers.
Compare like for like: level, location, and total compensation including equity and bonus, never base salary alone.
Do this once a year even when you are not looking. It takes an afternoon and it is the only reliable way to notice you have fallen behind.

What to say when they ask your expectation

Whoever names a number first anchors the negotiation, and early in a process you have the least information in the room. Deflect politely and keep the door open. This is not a trick, it is just declining to be the only side negotiating without data.

Try: I would rather work out whether this is a fit first. If it is, I am sure we can find a number that works.
If pressed: what range is budgeted for this level? I am happy to tell you if that is not workable for me.
Never offer your current salary as your expectation. What you are paid now is a fact about your last employer, not about this role.
When you do name a range, put it slightly above your target and give a reason: scope, market data, or other conversations in progress.
Get every part of it in writing before you accept, including anything a recruiter promised verbally about a review in six months.

Negotiate the whole offer, not just the base

Base salary is often the least flexible number in the package, and engineers routinely leave value behind by treating it as the only lever. Ask about everything once, politely, in a single message rather than five.

Levers worth raising: level and title, equity amount and vesting, signing bonus, annual bonus target, start date, location flexibility, learning budget, and the date of your first review.
Stay warm and low drama throughout. You are about to work with these people, and the person negotiating with you is often a future colleague.
Have a genuine alternative if you can. A real competing conversation moves numbers more than any phrasing, and no phrasing substitutes for it.

The internal raise conversation is a different game

Internally there is a budget, a cycle, and a band, and your manager is allocating from a fixed pool rather than approving a number. Timing and framing matter far more here than assertiveness does.

Raise it two or three months before the cycle, not during it. By the time numbers are being written, the decisions are largely made.
Frame it as market and level, never need. Here is my scope now, here is where I sit in the band, here is the market data.
Ask where in the band you sit for your level. At many companies that is a question they are permitted to answer.
If you are underpaid by a wide margin, understand that internal processes rarely close a large gap in one step, whatever anyone intends. Sometimes only a move fixes it.

Research it before you need it, ask for the whole package, and stay pleasant. One calm, well researched ask is almost never held against you, and never asking is reliably expensive.

Plateaus, burnout, and the long game

Nobody grows in a straight line, and the flat stretches are where most people make their worst decisions: quitting something good, or grinding through something that is genuinely harming them.

The plateau after senior is normal and mostly structural

Promotions slow down as you climb, and that is arithmetic rather than a comment on you. Each level needs a bigger problem, bigger problems are rarer, so the gaps get longer. Senior is where a great many very good engineers spend the rest of their careers, entirely happily.

A useful frame: track capability, responsibility, and compensation over a rolling three year window. Any single year can look flat and still be fine.
A plateau where you are still learning is a rest. A plateau where you are not learning is the one to act on.
Staying at senior on purpose, because you like the work and the life it gives you, is a legitimate choice and not settling. The ladder is a company's tool, not a measure of a person.

Burnout is specific, and tired is only one third of it

Burnout is best understood as an occupational phenomenon with three dimensions: energy depletion, growing mental distance or cynicism about the job, and a reduced sense of your own effectiveness. The second and third are the ones people miss in themselves, and the ones a holiday does not fix.

Exhaustion on its own often responds to two weeks off. Cynicism and a collapsed sense of effectiveness usually do not.
Warning signs I have learned to take seriously: dreading one specific recurring meeting, no longer caring whether the thing ships, and being unable to start work you used to find easy.
The described cause is chronic workplace stress that has not been managed. That points at the workload and the environment, not at your resilience.

What actually helps, roughly in order

Rest is necessary and rarely sufficient, because two weeks away returns you to exactly the same conditions. Changing something structural is what tends to work.

Reduce how many things you are responsible for at once, even temporarily. Concurrency is usually the real cost, not hours.
Protect one uninterrupted block a day and defend it like an outage. Attention is finite, and it is the same resource you spend on judgement.
Say the true thing to your manager: I am at capacity and something needs to come off the list. Which one?
Change the shape of the work, not only the amount: a different project, a different team, some time spent being bad at something again.
If the cynicism has been there for months and nothing structural has changed, treat it as a health matter and talk to someone qualified, not only to a mentor.

This is measured in decades

A six month or one year delay on a promotion feels enormous at the time and is essentially invisible ten years later. What compounds is the reputation you build and the judgement you accumulate, and both of those survive a bad cycle intact.

Every engineer I know with a good long career had at least one flat year, one cancelled project, and one manager who did not advocate for them.
Busy is not the same as useful. Guard your attention the way you guard uptime, because it is the same finite resource.
Level is only the shorthand. The real goal is being the person your teammates trust with the hard, undefined thing, and that is available to you long before the title is.

Growth is not linear and it is not owed to you on a schedule. Keep the receipts, keep the relationships, and keep choosing work that leaves you more capable than it found you.