The review cycle closes, the conversation happens, and you hear it: "you need to be more senior." You ask what that means and get more adjectives: "more vision," "more initiative," "more ownership." Nobody points to anything your team actually did. The bar exists, but it lives in someone's head, and you only learn its shape after the rating is already out.
This piece isn't about studying harder or changing jobs. The goal is to leave your next 1:1 with one short, dated page: three observable criteria, one real example from your team for each, and a date to check progress. Out of scope here: your CV, open roles, and lists of frameworks.
"More senior" is a label, not a criterion
A vague bar causes real problems, not just irritation. Rent the Runway wrote that their first engineering ladder had only a few descriptors per attribute and led to arguments about levels, anxiety, and fights over technicalities. Their fix was to rewrite the ladder with more detail so it could be used in reviews, in promotion committees, and in hiring.
Having a document doesn't fix everything either. Dropbox's engineering career framework says on its clarifications and myths page that the framework is not a checklist. It describes where you're trying to get to, not how to get there. What they recommend is talking directly with your manager to agree on where to spend more or less of your time.
As for how the feedback is phrased, CCL's Situation–Behavior–Impact model (SBI) separates labels ("lazy," "not a team player") from useful feedback: a situation, a behavior someone could observe, and its impact. "Be more senior" is the same kind of label. It just happens to sound like a compliment.
You can test this in the 1:1 itself. If your manager can't name one recent piece of work from this team that would count as "senior here," the feedback isn't a bar yet. If nobody can find the adjective anywhere in last week's work, it's not a criterion. It's a hope.
Three questions for your next 1:1
This conversation belongs in the 1:1, with a shared agenda. Google re:Work's guide to effective 1:1s recommends that both people add to the agenda, that career development be one of the topics, and that the meeting end with agreed next steps. Put the topic on the agenda ahead of time. Bring it up in the hallway and your manager is entitled to answer with another adjective.
The three questions below are a DevDojo script, not any company's rubric. They separate the result, the behavior, and the proof:
- Delivery: "If someone asked you tomorrow whether I'm already working at the next level on this team, what recent piece of work would you point to? Or what work is still missing? Please name one of our projects or services."
- Behavior: "In that same situation, what observable behavior, not personality trait, do you want to see more often? Something like: in meeting X you did Y, and the impact was Z."
- Evidence: "What would you open to check? A doc, a merge request, a decision, a review, an incident. Ideally from someone on the team who already does this, if that someone isn't me yet."
The third question gets you the most. If someone on the team already shows the behavior, the bar stops being abstract and becomes something concrete you can open and read.
Two kinds of answers mean you should ask again. The first is the star from another team, or a post from some industry blog. Write it down, but ask for a case from this team. The second is the full list of everything that could possibly count. That same Dropbox myths page says the point isn't to tick every box. Ask which two or three areas this manager cares about most right now.
The one-screen page, with a date
The agreement has to fit on one screen and live somewhere you can both see it, ideally in the same doc as your 1:1 agenda. The fields:
| Field | What to write |
|---|---|
| Date and names | Date of the agreement, your name, and your manager's name |
| Cycle | Open, or rating already given (without reopening the rating) |
| Criteria 1 to 3 | One observable sentence each, marked as delivery or behavior |
| Example from this team | A project, service, or person on the team, with no sensitive data |
| Evidence | What your manager would open to check |
| Check-in | A date about 90 days out, plus one line saying what "done" means |
| Out of scope | Stack, open roles, CV |
The 90 days are an editorial heuristic. Nobody has published them as a promotion deadline. It's just an interval that fits on a calendar and is short enough that neither of you forgets the agreement. What matters is that the date exists. GitLab's career development handbook describes the same principle: the manager and the team member agree on the date of the next career conversation and the outcomes expected by then. Cespedes' HBR article, republished by SHRM, says a review is only complete once it answers "so what?" and "now what?", with a timetable and benchmarks. Most of the impact comes from what happens after the conversation, not from a one-off annual meeting.
To check the page, ask your manager to read it out loud. If a fourth criterion that nobody mentioned shows up during the reading, the page has failed, and it's better to find that out now than next cycle. Ask directly: "Is it just these three until the check-in date?" If any criterion is still something like "be more proactive" or "have more vision," rewrite it in SBI form: in what situation, doing what, with what impact.
A stack list is not a bar
A common answer to "what does more senior mean here?" is a list of technologies: Kubernetes, messaging, that language the team hasn't even adopted yet. You ask for a project name and get a stack list instead. A stack list is easier to say and harder to hold anyone to.
Published matrices point somewhere else. When CircleCI described how they built their competency matrix, technical skills made up about 20% of the competencies, and growth meant a wider scope of impact (task to team, team to organization), not more languages on your CV. Dropbox's What is Impact? page measures success by impact on the business and the customer, not by complexity for its own sake.
None of this makes those ladders your company's rubric. It only shows that even the people who published their ladders don't treat stack as a synonym for level. When the answer arrives as a list, swap it for three requests:
- the next-level result your manager wants to see in the team's current systems;
- the how, in a named setting: a review, an incident, planning;
- who else on the team already does this today.
If your company has a ladder, internal or public, use it for shared vocabulary and still ask for a local example. If your manager only offers a course or a list of tools, go back to the three questions. A course might help, but it won't tell you which piece of this team's work your manager would point to tomorrow.
If you've already read technical career: the next step is not another framework, here's the difference: that one is a 30-minute self-audit of the evidence you already have, and this one is about getting your manager's bar out of them during the cycle.
If the cycle has already closed: agree on the next one, don't relitigate the rating
Once the rating is in, it's tempting to use the 1:1 to reopen the review. That usually eats the whole meeting and ends with no date at all. Reopening a closed rating is the most expensive way to avoid scheduling the next conversation.
According to the HBR article, a review has two jobs: evaluation and development. Even after the rating, the next steps, timetable, and benchmarks are still missing. So change what the conversation is for:
> "I'm not going to reopen the rating. For the next cycle, I want to leave here with three observable criteria, one example from the team, and a check-in date. If anything from last rating still applies, let's write it as a behavior plus evidence, not an adjective."
One diagnostic question is worth asking too, because it changes the rest of the conversation: does the rating say you're doing well in your current role and aren't at the next level yet, or does it say something is missing in your current role? GitLab treats these as different situations that call for different actions from the manager. In the second case, the page is about your current level, not a promotion. GitLab's own engineering careers handbook treats senior as a destination role: staying at your current level can be a legitimate choice. "More senior" isn't mandatory. It just needs to be written down if that's what you agreed on.
DevDojo's recommendation: treat "be more senior" as unfinished feedback until there are three written criteria, each with an example from the team, plus a check-in date. If the conversation only produces a course or a stack list, ask again. If your manager says the gap is in your current role, or you don't want the next level right now, use the same page with that goal instead.
Your next step this week
Add one line to the shared agenda for your next 1:1: "Next-level criteria: three examples from this team and a check-in date." Bring the table above with the fields blank. Ask the three questions, fill it in together with your manager, ask them to read it out loud, and leave with the check-in date on both your calendars.
If at the end of the meeting the page has three observable sentences, three examples from the team, and a date, the bar now has a shape. If it still says "more vision," you don't have a criterion yet. You have an adjective in writing.