Growing to senior

Getting hired is a milestone, not the destination. Most engineers' biggest career jump comes from growing from mid-level to senior: more responsibility, more autonomy, and usually a large step in compensation. It isn't about years of experience or knowing more frameworks. Some engineers reach senior in three years; others stay mid-level for ten. The difference is mostly what they choose to own and how they work. This lesson describes what changes at senior level, the habits that build it, and how to make your growth visible.

#What actually changes

Career ladders differ by company, but the shift from mid-level to senior follows the same pattern everywhere:

The common thread: a senior engineer reduces the amount of management and direction the team needs. Give them a fuzzy problem and they come back with a solved problem, not a list of questions — after asking the right ones.

#Own outcomes, not tickets

The single biggest habit: care whether the work achieved its purpose, not just whether the ticket is closed.

• Understand the why. Before building, know who the feature is for and what success looks like. If the ticket says "add a CSV export", ask what the users are trying to do; sometimes a filter or a scheduled email solves it better.
• Follow it to production. Check the dashboards after release. Is it used? Is it fast? Did errors rise? A feature that shipped but broke checkout isn't done.
• Close loops. If you said you'd look into something, report back, even to say you couldn't.
• Fix what's around you. The flaky test everyone reruns, the missing alert that hid last month's incident, the onboarding doc that's out of date. Senior engineers notice and fix — or get fixed — the things everyone else has learned to ignore.

#Handle ambiguity

Junior and mid-level engineers are mostly handed well-shaped problems. Senior engineers are handed problems like "checkout feels slow" or "we need to support a new country". The skill is turning ambiguity into a plan:

1. Clarify the goal with the people who own it: what outcome, by when, what constraints.
2. Investigate — measure the current state, read the code, talk to the teams involved.
3. Write it down as a short design doc with options and trade-offs.
4. Break it into milestones that each deliver value and can be checked, so the team learns early if the plan is wrong.
5. Communicate progress and risks before anyone has to ask.

#Technical judgment

Seniority shows less in knowing the rules than in knowing when they apply. Everything in this roadmap — SOLID, clean architecture, DDD, microservices — has a cost, and a senior engineer asks whether this problem justifies it. Signs of good judgment:

• Choosing boring technology by default, and new technology only when it solves a problem the boring one can't. Every new tool is a long-term operating cost.
• Matching effort to risk. Thorough review and testing for payments; fast iteration for an internal dashboard.
• Making reversible decisions quickly and irreversible ones carefully. A library choice inside one module can be changed later; a public API or data model is hard to undo.
• Simplifying. The best senior engineers often remove code, services and processes.
• Saying "I don't know — let me find out" instead of guessing confidently.

#Multiply the team

At senior level, your impact includes the impact you have through others:

• Code review as teaching. Explain the why in review comments, distinguish blocking issues from preferences (mark nits as nits), and review promptly — a PR waiting two days blocks a teammate for two days. The pull requests lesson covers good review practice.
• Pair and mentor. Pair with less experienced engineers on hard tasks — and let them drive.
• Write things down. Runbooks, onboarding guides, ADRs, a clear incident write-up. Writing scales your knowledge to people you'll never meet.
• Improve the system of work. Faster CI, a better local dev setup, a clearer on-call rotation — improvements that save every engineer time every day are some of the highest-leverage work there is.
• Share credit generously. People want to work with seniors who make them look good.

#Communicate like a senior

• Write clearly and concisely. Lead with the conclusion; give context after.
• Translate between technical and business language. "The migration reduces checkout failures by about 1%, roughly Rp 200 million a month" gets a project prioritised; "the new schema is more normalized" doesn't.
• Disagree and commit. Push back with data when you disagree; once a decision is made, support it fully.
• Escalate early. Raise a risk when it's a risk, not when it's an incident. Escalating isn't failure; surprising your manager is.
• Manage expectations. Give estimates as ranges, explain what drives the uncertainty, and update them when you learn more. Hofstadter's law applies to everyone.

#Make growth visible

Promotions are decided by people who can't see all your work. Make it easy for them:

• Know your company's career ladder. Read the senior expectations, and ask your manager which areas you're strongest and weakest in against it.
• Ask for senior-scope work — a project you'd lead end to end — and explicitly agree that it's a promotion opportunity.
• Keep a brag document. Each week, write a line or two: what you shipped, the impact with numbers, who you helped, what you improved. At review time, you'll have evidence instead of a fuzzy memory.
• Get feedback regularly, not just at review time. "What's one thing I could do to have more impact?" is a question most managers are happy to answer.
• Build relationships beyond your team. Senior impact usually crosses team boundaries, and the people in those teams will be asked about you.

#Avoid the traps

• Waiting to be given senior work. You usually need to start operating at the next level before you're promoted to it.
• Hero mode. Working nights to rescue projects alone looks impressive but doesn't scale and creates single points of failure. Senior engineers prevent fires and spread knowledge.
• Technology over problems. Pushing a new framework or rewrite because it's interesting, not because the business needs it.
• Neglecting fundamentals. Seniority rests on strong basics: debugging, testing, data structures, reading unfamiliar code fast. Keep them sharp.
• Comparing timelines. Someone being promoted faster at another company says little about you. Measure yourself against your ladder and your last year.

#Practice

Write a one-page growth plan for the next six months. Include: your current level and target level; two areas from your company's ladder (or the table above) where you're weakest; for each, one concrete project or habit that would produce evidence; how you'll track it; and the feedback you'll ask for and from whom.

Show solution

An example plan for a mid-level backend engineer:

Current → target: Software Engineer II → Senior Software Engineer, review in six months.

Gap 1 — Scope and ambiguity. I've delivered well-defined features, but haven't led a project from a vague goal.

• Project: volunteer to lead "reduce failed payments", currently an open goal on the team roadmap. Investigate and measure failure causes, write a design doc with options, break it into milestones, and coordinate with the payments team.
• Evidence: the design doc, milestone updates, and the failure-rate metric before and after.

Gap 2 — Multiplying the team. My reviews are slow and short, and I haven't mentored anyone.

• Habit: review PRs within one working day, and explain the reasoning in blocking comments.
• Mentoring: pair weekly with the new joiner on their first features, letting them drive.
• Evidence: review turnaround (visible in the Git hosting tool), feedback from the new joiner.

Tracking: a brag document updated every Friday — shipped work, impact with numbers, people helped.

Feedback: monthly one-on-one question to my manager: "Against the senior expectations, where am I strongest and weakest right now?" Ask the payments team's lead for feedback after the project's first milestone, and a senior engineer for feedback on my design doc before wider review.

Check-in: at three months, compare progress against the ladder with my manager, and adjust the plan.

#Key takeaways

• Senior isn't years or framework count; it's scope, ownership of outcomes, judgment, and influence beyond yourself.
• Own outcomes: understand why, follow work into production, close loops, and fix what everyone else ignores.
• Turn ambiguity into plans: clarify, investigate, write it down, deliver in milestones, communicate early.
• Show judgment by matching effort to risk, choosing boring technology, and simplifying.
• Multiply others through review, pairing, writing and improving how the team works.
• Make growth visible: know the ladder, ask for senior-scope work, keep a brag document, and seek feedback regularly.