What actually changes between mid and senior
See what a step up in seniority really asks for, why it is not more code, and how to tell whether you are already doing it in your current job.
A move toward senior often expands independent delivery, technical judgement, collaboration and the scope of problems you can clarify. Being involved earlier is one useful opportunity, not a universal definition. Use your employer’s role expectations, evidence and decision authority to assess the step.
Think of two people on the same building site. One is handed the drawings and puts up a wall that stands for fifty years. The other also helps decide, with the site owner, whether the wall belongs there and what the ground can hold. Being asked before anything is drawn is one sign of that wider judgement, not the whole of it.
Seniority is not a universal count of lines of code, meetings or years. Organizations use different levels and scopes. A useful question is what decisions and outcomes you can own with appropriate support, and how your judgement helps the team deliver reliably. Being consulted before a design is fixed can reveal that responsibility, but it is one signal among several.
Scope and judgement, not volume#
An earlier discussion can make alternatives cheaper to explore: a design note is usually easier to change than a deployed contract with several callers. That does not make every early choice reversible, or every late objection unaffordable. A security or correctness problem may require changing shipped work. Review can reveal new evidence; disagreement can also reflect authority, incentives or bias.
Dropbox’s IC4 framework, one concrete example, includes autonomy on ambiguous problems, technical judgement, collaboration and mentoring. It does not reduce the role to when a question arrives. Compare examples against your own employer’s current framework and agree who can authorize architecture, rollout and cross-team commitments.
What it looks like from the inside#
Consider an illustrative order/billing decision. Calling billing during an order transaction adds an external failure point: the database cannot atomically roll back a completed remote charge. Depending on error handling, billing downtime may reject orders, delay them or leave a recovery problem. It does not automatically mean that accepted orders were never billed.
A transactional outbox stores the intent to notify billing in the same database transaction as the order. A relay delivers it later. That makes the local order and notification intent commit together, not the remote effect: the relay needs retry and recovery rules, and billing must handle duplicate delivery. It is a candidate when asynchronous completion fits the business requirement, not a universally correct pattern.
Try the decision
An early billing design must record a charge and notify another service. What makes the recommendation useful?
The name does not settle the required failure behaviour, delivery retries or who may approve the change.
Next step: Ask what must commit together and what the caller needs to know.
This is an illustrative decision with stated assumptions. It cannot establish your employer’s policy or predict an individual career outcome.
Useful evidence is the reasoning: whether the customer needs immediate billing confirmation, what an uncertain response means, how replay works, who owns recovery and which assumptions would change the choice. Record options and limits in an architecture decision record. Agree a small authorized test before committing several teams to a migration.
What you give up#
Broader responsibility can add coordination and delayed feedback. It does not require surrendering all focus time or treating every interruption as the job. Agree capacity for implementation, review, mentoring and decisions; delegate or escalate when obligations exceed it. Staying technically grounded and making room for other people’s work can both matter.
Collect observable outcomes rather than claiming that an unbuilt migration proves your value: a clarified constraint, a safer rollout, fewer recurring failures, or a colleague able to proceed independently. State the uncertainty in counterfactual claims. Ask for feedback early enough to correct direction, and preserve evidence across a sustained period.
Where it goes wrong#
A pattern preference without assumptions is hard to evaluate. Replace “an outbox is correct” with a requirement and failure analysis that the team can inspect. Conversely, repeatedly rejecting a well-supported concern is not explained away by “you spoke too late”. Establish how unresolved correctness risks are escalated and who decides.
Another failure is accepting a larger scope while keeping the same ticket load and receiving no authority or support. Ask for an explicit opportunity, reviewer, decision owner and review date. A promotion can depend on organizational constraints beyond your performance. The next step may be a different scope of technical work, as in senior versus staff engineering, rather than simply more meetings.
IF YOU REMEMBER ONE THING
Assess senior work through scope, judgement, delivery and collaboration under a stated framework. Earlier involvement helps when it makes a decision inspectable; it is neither permission nor a universal promotion test.
Questions people also ask
4 QUESTIONSDo I need to lead a team to be senior?
People management is a different role. Senior IC expectations may include leading a project, mentoring or coordinating work without direct reports; the specific framework determines the scope.
How long does it take?
There is no universal number of years. Ask for the current expectations, evidence needed and decision process. Opportunity, support, organizational structure and promotion capacity can affect the outcome as well as your work.
Can I be doing senior work without the title?
Possibly. Compare sustained examples with the relevant framework and discuss them with the people responsible for calibration. An early invitation or one successful project is useful evidence, not an objective title test or promise of promotion.
What if nobody on my team asks me before a decision is made?
Agree with your manager or project owner on a bounded opportunity to clarify an open decision. A short options note can help, but does not grant decision authority. Investigate missing access, role boundaries or bias rather than assuming timing explains every objection.