Mid-Level to Senior Developer: Skills, Evidence and a Growth Plan

What does senior mean in your team?

Moving toward senior development starts with a comparison between your employer’s expectations and evidence from your work. Identify a responsibility you need to demonstrate, agree on a suitable opportunity and ask for feedback while the work is still in progress. Another framework or course may help, but it should answer a specific gap.

GitLab’s published senior backend framework is one concrete employer example. It includes handling unclear requirements, communicating technical decisions, resolving complex problems and mentoring others. Use it to make your questions more precise, then check your own company’s expectations. It is not a universal definition of seniority.

Ask your manager for the current career framework and how it is applied. Clarify who evaluates progression, what evidence is considered and which opportunities are available. A strong development plan cannot promise that a role, budget or promotion decision will follow on a fixed date.

Review skills through examples, not confidence scores

Use this worksheet to organize a conversation. It is an editorial aid, not a validated assessment. For each row, name a concrete situation, your contribution and a person who can challenge your interpretation. Record uncertainty when you do not yet have enough evidence.

Work through a project with a clear boundary

Consider an illustrative project: a customer export sometimes fails after a deployment. You are asked to make the failure easier to diagnose and recover from. Begin by documenting the symptom, the affected users and the unknowns. Agree with the owner on what is in scope before proposing a larger redesign.

Compare options such as better diagnostic information, a bounded retry or a change to how the export is processed. Explain how each option behaves when the dependency stays unavailable. Discuss duplicate work and recovery with the team that operates the service. The most elaborate design may not be the appropriate first step.

Write acceptance criteria that another reviewer can use. Include the normal path, a controlled dependency failure and the recovery behavior. After implementation, ask an operator to use the diagnostic information and record where your instructions were incomplete. Separate what was observed in a test from what has been observed in production.

Your evidence record should include the initial question, the alternatives, the agreed boundary, review feedback and follow-up observations. If failures appear less frequent, describe the time window and other changes before claiming that your work caused an improvement. A useful outcome can also be a previously hidden uncertainty becoming visible.

Turn the evidence into a manageable growth plan

Choose one capability to practise in the next piece of agreed work. A goal such as “improve system design” is hard to review. “Write down two recovery options for the export failure and review them with its owner” has an observable output and a natural feedback point.

The plan below uses milestones rather than a guaranteed promotion timeline. The duration depends on the project, your existing experience and the support available. Avoid adding a second unofficial job to your workload; agree on how the opportunity fits the work you are already responsible for.

1. Agree on the expectation and choose one work example that could demonstrate it.
2. Record your current evidence and the part you cannot yet explain or perform independently.
3. Choose a scoped opportunity, reviewer and feedback point before starting.
4. Keep decisions and feedback as the work progresses; revise the plan when assumptions change.
5. Review the result against the expectation and agree on the next opportunity.

Ask for feedback that can change the next attempt

Replace a general question such as “Am I senior yet?” with a specific one: “In this design review, where did you still need to supply context or resolve the ambiguity for me?” Ask for an example and a way to practise the missing behavior. Check the interpretation with more than one relevant collaborator where possible.

Keep a short record of what you changed after feedback. If a reviewer says a proposal is difficult to evaluate, improve the problem statement and alternatives before adding more detail. If the work missed its intended outcome, examine the assumptions rather than presenting effort as impact.

Use reading to support the next attempt. Follow the concept that would change a decision in your project, then explain how you would apply it. CareerJump can provide a weekly newsletter on selected work and career topics, explained around your experience. It does not assess promotion readiness or generate a guaranteed career roadmap.

• Choose professional-development topics around your next decision
• Turn what you read into a small learning action