Career Path

Quote

The future depends on what you do today.

–Mahatma Gandhi, Indian Politician

What is a Career Path

A career path is the roadmap that helps anyone in a company understand how they can grow over time in skills, responsibilities, and salary. It shows where you are today and which options exist for that progression, including titles, levels, skills, and ownership expectations.

A good career path makes the following explicit:

• Current role
• Next possible roles
• Skills needed for each step
• Milestones or expectations for growth

It should cover both vertical growth (increasing depth and expertise) and lateral moves (broadening scope, domains, or responsibilities).

Inside a company, career pathing is the shared plan between the employee and the organization for how growth can happen. It clarifies whether someone can grow as an individual contributor, move into management, or shift across areas like product, platform, or architecture.

When there is no clear career path, three things usually happen: turnover rises, engagement drops, and internal development becomes weaker. For new joiners in fast-growing companies, it also creates confusion about what “good” looks like and how to grow without guessing.

Main risks

• People assume they must leave the company to progress, which raises attrition and weakens retention. If there is no visible path to growth, changing jobs becomes the only obvious option.
• Motivation drops when effort does not seem tied to visible growth, promotion, or broader responsibility. Growth is a major driver of motivation; if criteria are not clear and objective, people disengage.
• Managers make ad hoc promotion decisions, creating inconsistency and perceived unfairness across teams. When rules are not explicit and shared, promotions depend on each manager’s personal criteria.
• The company loses internal mobility and struggles to grow leaders from within. A role should mean the same thing regardless of team, project, or squad; otherwise moving people across the org becomes painful.
• Promotions are expected purely based on time served in the company instead of impact, skills, or scope. This feeds entitlement, misalignment, and frustration on both sides.

Effect on new joiners

New joiners need clarity from day one. They should understand why they have their current level, why their salary fits the band for that level and role, who they can go to for help, and what it takes to reach the next level.

If they have to spend weeks decoding who is who, why each person has certain responsibilities, and what “senior” actually means, they waste energy learning the org’s politics instead of focusing on onboarding and contributing.

A clear career path becomes a core part of onboarding: it explains expectations, shows what “good” looks like for their level, and gives them a concrete direction for growth instead of leaving them to guess.

Why fast growth makes it worse

In fast-growing companies is specially key to have this process well-defined as you will start labeling new joiners, and setting initial salaries. You want to avoid unfair salaries to new joiners that can create a bad environment when seen as a justification for the need of growth. It also allows you to clearly justify why the offer you made is based on a clear, objective, and established criteria. In fast-growing companies, roles shift quickly and structure often lags behind hiring. That makes unclear career paths more damaging, because people may be doing real work without knowing whether they are building toward seniority, specialization, or leadership.

Defining a Career Path

Visual representation

To help us clarify how we can build a Career Path, we can use this sample for a software development company or department inside an organization.

The main components defined in this career path are, from the most basic profile you will hire, to the highest position in the organization. Let’s analyze some of the components, and which criteria could we follow for promotions.

Junior Software Developer

It is an early-career developer who has the foundations of programming clear, has some experience in writing code on one or more programming language, but never worked on production ready work, or shipped any professional code except of, maybe, being part of a team where responsibility never was on him. Dependence on other developers is expected, and the most valued skill should be a good attitude, steady process, and curiosity to learn from the experienced ones.

Level 1

Learning basics, working under guidance. At this point, reading and shadowing other developers is what is expected. Working on small, supervised changes, will guide this profile into the process of understanding how to be integrated in the team.

Level 2

Small contributions, asks for help sometimes. The next level should involve the acquisition of the skills needed to be a contributor. Don’t expect autonomy at this point, but request the ability to contribute after a clear definition of what is required, always being specific contributions, and expecting to have clarifications and help from the more experienced developers.

Level 3

Takes independent tasks, code reviews. This is the final level of a junior developer and, so, it is expected to be able to work autonomously on tasks, not complete features, without the support of a more experienced developer beyond the initial instructions. This level is also expected to do code reviews and so, contribute to the SDLC.

Software Developer

A Software Developer at this stage is a fully contributing engineer who has already shipped production code and understands how real systems behave under real constraints. They are no longer learning “how to code” but rather “how to build reliable, maintainable software in a team.” They can work independently on well-defined problems, collaborate effectively with others, and start influencing technical decisions within their scope. Ownership increases here, as well as expectations around quality, delivery, and problem-solving.

Level 1

At this level, the developer transitions from guided execution to consistent contribution. They can take clearly scoped features and deliver them end-to-end, including basic testing and integration.

• Works independently on small features or enhancements with clear requirements
• Actively participates in team ceremonies (planning, standups, retros)
• Understands the team’s development workflow (CI/CD, code reviews, branching)
• Writes clean, maintainable code but may still need feedback on design decisions
• Begins to understand system boundaries, but mostly operates within known areas

Level 1 → Level 2 Promotion

• What you want to see (signals)
  • Delivers small features end-to-end without hand-holding
  • Asks better questions upfront, not during implementation chaos
  • Starts proposing simple solutions, not just executing tasks
  • Handles basic debugging independently (logs, tracing, reproducing issues)
  • Code reviews show growing awareness of quality (naming, structure, tests)

Think of it as: “I can trust this person with a ticket and not worry.”

• What holds them back (anti-patterns)
  • Still needs step-by-step breakdowns for most tasks
  • Frequently blocked but doesn’t unblock themselves (waits instead of investigating)
  • Treats requirements as fixed instead of clarifying gaps
  • Repeats the same mistakes flagged in code reviews
  • Focuses only on “making it work,” not maintainability
• How to evaluate
  • Look at the last 4–6 delivered tasks: were they independent or guided?
  • Review PRs: are comments decreasing? Are they more nuanced?
  • Ask: “Could I give them a slightly ambiguous task and expect a reasonable solution?”
  • Check debugging behavior: do they bring problems + hypotheses, or just problems?

Level 2

Here, the developer becomes a reliable problem solver. They don’t just implement—they think through solutions and make reasonable design decisions within a defined scope.

• Designs and implements components or subsystems with minimal guidance
• Debugs and resolves issues independently, including production incidents of moderate complexity
• Makes trade-offs (performance, readability, scalability) with increasing awareness
• Proactively identifies gaps or improvements in code and processes
• Collaborates cross-functionally (QA, product, DevOps) with confidence

Level 2 → Level 3 Promotion

• What you want to see (signals)
  • Designs parts of the system with clear reasoning and trade-offs
  • Solves non-trivial issues independently, including some production problems
  • Anticipates edge cases and thinks beyond the happy path
  • Improves existing code (refactors, simplifies, removes tech debt) without being asked
  • Starts informally mentoring juniors (reviews, pairing, guidance)

Think: “This person doesn’t just execute—they improve things and people.”

• What holds them back (anti-patterns)
  • Jumps into coding without thinking through design
  • Solutions work but don’t scale or fit the system well
  • Avoids ownership of messy or unclear problems
  • Doesn’t share knowledge or help others grow
  • Over-engineers or under-engineers due to weak trade-off thinking
• How to evaluate
  • Review 1–2 design decisions they made: were trade-offs explicit?
  • Look at incident handling: did they own resolution end-to-end?
  • Ask teammates: “Do they make your work easier?”
  • Check if juniors gravitate toward them for help (organic mentoring signal)

Level 3

This is the top of the mid-level range—impact expands beyond individual contributions into team and system influence.

• Mentors junior developers through code reviews, pairing, and guidance
• Contributes to architectural discussions and proposes improvements
• Breaks down complex features into actionable tasks for the team
• Ensures code quality and consistency across the codebase
• Acts as a “force multiplier” by unblocking others and improving team efficiency

Level 3 → Senior Promotion

• What you want to see (signals)
  • Consistent mentoring impact across multiple juniors
  • Influences technical direction, not just contributes to it
  • Breaks down complex work for others reliably
  • Raises the overall engineering bar (quality, practices, clarity)
  • Thinks in terms of systems and teams, not just tasks

Think: “If they disappeared, the team would feel a gap—not just in output, but in direction.”ß

Senior Software Engineer

A Senior Software Developer is responsible not just for delivering complex software, but for ensuring that systems are scalable, reliable, and aligned with long-term goals. They operate with high autonomy, influence technical decisions across the team, and elevate others through mentoring and example. Their impact is measured less by what they code and more by how they shape systems, practices, and people.

Level 1

At this level, the developer is a go-to person for complex work. They can take ambiguous, high-impact projects and drive them to completion with strong technical judgment.

• Leads end-to-end delivery of complex features or projects (multiple components, dependencies, edge cases)
• Applies deep expertise in one or more areas (e.g., backend, frontend, infrastructure)
• Makes solid design decisions with clear trade-offs
• Handles difficult debugging and production issues confidently
• Ensures quality through strong coding, testing, and review practices

Level 1 → Level 2 Promotion

• What you want to see (signals)
  • Moves from solving problems to preventing them through better direction
  • Technical decisions are adopted by others, not just correct in isolation
  • Mentors multiple developers with visible growth outcomes
  • Identifies and drives improvements beyond their own projects
  • Communicates trade-offs clearly to both engineers and stakeholders

Think: “This person is shaping how the team builds.”

• What holds them back (anti-patterns)
  • Strong individual contributor but limited influence on others
  • Mentoring is reactive or inconsistent
  • Good designs, but not socialized or adopted
  • Focuses on local optimizations instead of team-level improvements
  • Avoids stepping into ambiguous or cross-team decisions
• How to evaluate
  • Look at decisions they influenced: did the team follow them?
  • Track mentoring: did specific people improve because of them?
  • Ask: “Do they change how the team works, or just what they deliver?”
  • Review cross-project impact, not just single-project success

Level 2

Here, the scope expands from project ownership to team-level influence. The developer starts shaping how the team builds software.

• Guides technical decisions across multiple projects or components
• Mentors several developers (mid + junior), adapting guidance to different levels
• Defines and promotes best practices (architecture, testing, observability, CI/CD)
• Anticipates risks and steers the team away from poor technical choices
• Improves team effectiveness by clarifying approaches and reducing ambiguity

Level 2 → Level 3 Promotion

• What you want to see (signals)
  • Drives strategic initiatives (reliability, scalability, architecture evolution)
  • Has a strong sense of system health over time, not just delivery
  • Influences multiple teams or a broader domain
  • Establishes frameworks (e.g., SLOs, incident processes, architectural guidelines)
  • Balances business needs with long-term technical sustainability

Think: “This person protects and evolves the system and the team.”

• What holds them back (anti-patterns)
  • Focuses on architecture without considering operational reality
  • Drives initiatives that don’t stick (lack of adoption or follow-through)
  • Over-indexes on perfection instead of pragmatic improvements
  • Limited awareness of business impact or priorities
  • Acts as an expert, but not as a driver of change
• How to evaluate
  • Look at long-lived improvements: are things measurably better months later?
  • Check reliability metrics (incidents, MTTR, stability trends) tied to their work
  • Ask: “If they step away, do these practices continue?”
  • Evaluate influence scope: team vs multi-team vs domain

Level 3

This is the top of the senior range—impact shifts toward system-wide thinking, long-term strategy, and operational excellence.

• Influences team or domain strategy (scalability, reliability, performance, maintainability)
• Acts as a reliability expert: drives improvements in uptime, monitoring, incident response, and resilience
• Shapes technical roadmaps in alignment with business goals
• Drives cross-team alignment on architecture and engineering practices
• Elevates engineering standards across the organization

Level 3 → Staff Readiness

• What you want to see (signals)
  • Consistent impact across multiple teams or domains
  • Shapes organizational-level technical strategy
  • Aligns engineering decisions with business outcomes
  • Acts as a connector between teams, reducing silos
  • Creates systems (technical + human) that scale without them

Think: “They design systems that outlive their direct involvement.”

Unified Career Ladder

Think of it as a progression across 3 dimensions:

• Scope (task → system → domain)
• Autonomy (guided → independent → directional)
• Impact (self → team → organization)

Junior Developer

Core theme: Learning how to contribute

• Scope: Individual tasks
• Autonomy: Low → Moderate

• Impact: Self

• L1: Learns basics, shadows, small supervised changes
• L2: Contributes small pieces with guidance
• L3: Handles well-defined tasks independently, starts reviewing code

Trust test:
“Can I trust them to deliver a clear task correctly?”

Software Developer (Mid-level)

Core theme: Owning execution

• Scope: Features and components
• Autonomy: Moderate → High

• Impact: Team (through delivery)

• L1: Builds small features end-to-end, participates actively
• L2: Designs parts of the system, solves issues independently
• L3: Mentors juniors, contributes to architecture

Trust test:
“Can I trust them with a problem, not just a task?”

Senior Developer

Core theme: Owning direction and system health

• Scope: Systems and cross-cutting concerns
• Autonomy: High

• Impact: Team → Multi-team

• L1: Leads complex projects, deep technical expertise
• L2: Guides technical direction, mentors multiple developers
• L3: Influences strategy, drives reliability and long-term quality

Trust test:
“Can I trust them to guide others and improve the system over time?”

In general, this is a graphic representation of How the Levels Connect:

• At junior level, you work on small, well-defined problems, own individual tasks, focus on immediate work, and mainly learn from others.
• At mid level, you deal with more ambiguous but contained problems, own complete features, think in short-term (sprint-level) outcomes, and actively support teammates.
• At senior level, you tackle open-ended, systemic problems, own outcomes end-to-end, think about long-term sustainability, and intentionally shape and influence other people’s work and growth.

Tip

Simple rule: If someone is already operating at the next level for ~2–3 months, they’re ready.

But, what actually triggers promotion? here you can see a visual scheme:

• Moving from junior to mid: you stop needing constant guidance, start actively solving problems (not just executing tasks), and your code needs less correction.
• Moving from mid to senior: people rely on your judgment, you raise team productivity and codebase quality, and you handle ambiguity without spinning.
• Moving from senior to staff: your impact goes beyond your team, you connect technology decisions with business goals, and you design systems that scale without you being involved day to day.
• We find three anti-patterns:
  • the “fake senior” who is strong individually but doesn’t elevate others
  • the “stuck mid” who avoids ambiguity and just executes
  • the “overpromoted junior” who lacks - foundation, creates rework, and slows the team down

Leveling your team members

Now that we have a solid ladder, we need to find a fair and repeatable way to map our team members into the different levels we defined.

Clarify what you’re assessing

You should anchor everything in the 3 dimensions we defined: scope, autonomy, impact. For each level, turn your existing descriptions into 5–8 observable behaviors, for example:

• Junior L2: “Delivers small features with guidance; asks for help before getting stuck; PRs still need structural feedback.”
• Mid L2: “Designs parts of the system, owns incidents of moderate complexity, informally mentors juniors.”
• Senior L1: “Leads complex projects end-to-end, makes trade-offs explicit, handles tough production issues.”

This becomes your evaluation rubric: everyone is judged against the same behaviors, not gut feeling. This is a very important aspect of the leveling as it should be as objective as possible, everyone can bring personal and convincing reasons to deserve a higher level, but you should be able to demonstrate that the method is fact based, and not opinion based.

You should present this exercise as a fair and comprehensive tool to ensure everyone is at the right career level, and that brings stability into the team. Consider that not everyone will be happy with the results and some team members, specially the ones with more time in the company, will tend to feel downgraded due to the knowledge they have of the system itself, but, even that you need to consider it, the capacity of working in the three dimensions should prevail over the time.

Use a 360° evidence-based assessment

Think in three passes: self, manager, and peers. Each pass uses the same rubric. This is a very powerful tool, as it uncovers, in many occasions, aspects that your team members never saw. You need to be careful about the personal issues inside the team, and be very clear about what you are assessing and ask for an objective exercise.

Self-assessment

Ask each engineer to do a self-leveling using your ladder:

• “For each dimension (scope, autonomy, impact), which level best reflects how you’ve been operating over the last 3–6 months?”
• “List 3–5 concrete examples (tickets, incidents, projects) that show you’re operating at that level.”

This forces them to bring evidence and tells you how they see themselves.

Example questions they answer:

• When was the last time you led something end-to-end? What was your role?
• Tell me about a time you unblocked others or mentored someone.
• Describe a tricky production issue you handled: what did you do?

Manager assessment: apply the “trust tests”

In your 1:1 calibration, you basically answer the trust question for each person.

For each level band:

• Junior → “Can I trust them to deliver a clear task correctly?”
• Mid → “Can I trust them with a problem, not just a task?”
• Senior → “Can I trust them to guide others and improve the system over time?”

Concrete prompts you can use:

• Scope
  • “What kind of work do I actually give them: tasks, features, or projects?”
  • “Do I route messy/ambiguous work to them, or avoid it because they might sink?”
• Autonomy
  • “If I went on holiday for two weeks, would this person keep moving or stall?”
  • “Do they come back with questions only, or with options and trade-offs?”
• Impact
  • “Who works better because this person is here?”
  • “What is measurably better in the codebase or system because of them?”

You compare your answers and examples with their self-assessment, how they match can give you a good starting point on where conflicts may appear.

Peer input: calibrated, not popularity-based

Keep peer feedback structured and small to avoid politics:

Ask 3–5 colleagues (mix of same-level, juniors they help, and people from other functions):

• “In what situations do you rely on this person?”
• “What have they taught you in the last 3–6 months?”
• “How do they behave in high-pressure situations (incidents, deadlines)?”

You’re looking for consistent patterns that match your level definitions:

• “Always steps in during incidents and keeps everyone calm → senior-like impact.”
• “Good executor but avoids unclear tickets → mid-level anti-pattern.”

Turn your ladder into a simple scoring grid

To make the process repeatable and easier to explain, you can use a lightweight scoring method:

For each person:

• Scope: rate from 1–3 (junior, mid, senior) based on where they operate most of the time.
• Autonomy: 1–3
• Impact: 1–3

Examples:

• 1–1–1 → clearly junior
• 2–2–1 or 2–2–2 → mid, early vs solid
• 3–3–2 or 3–3–3 → senior

Then refine with your within-band levels (L1, L2, L3) using your promotion “signals” and “anti-patterns” already defined in the article. skillpanel

You can turn this into a small table in your post:

Calibration and fairness practices

To avoid “loudest voice wins”, do a short calibration session with other managers or senior engineers:

• Bring anonymized examples: “Engineer A: owned checkout refactor, led 3 incidents, mentors 2 juniors…”
• Place people on your ladder visually (a grid or sticky-notes board).
• Challenge each other with: “If we renamed everyone and changed teams, would this still be their level?”

Also, apply the rule we saw before: someone should be operating at the next level for 2–3 months before promotion.

How to communicate levels to the team

When you share results with each person:

• Start with strengths in the language of the ladder: “You’re consistently acting as a mid L2 in scope and autonomy.”
• Then gaps, mapped to concrete behaviors: “To reach mid L3, we need to see you mentoring juniors and contributing more to design discussions.”
• End with a 3–6 month growth plan tied to those behaviors (specific projects, responsibilities, and support).

That turns the leveling exercise into a growth conversation, not a judgment.

Recap

Now you have all the information you need to be aware of what you have and what you need to create a truly balanced team. The next steps, when possible, should be adaptation of the salary levels to the ones you mapped in the career path. This is a very tough question that might need collaboration from other departments, and does not need to be done immediately, but you should keep something in mind:

• Everyone should be paid accordingly to their level
• New joiners should be paid inside the boundaries of the levels they are being hired.

Key ideas

• A clear career path is a shared roadmap between company and employee that aligns titles, skills, scope, and expectations over time.

• Lack of a defined career path increases attrition, hurts engagement, and makes promotions feel arbitrary and unfair.

• Fast-growing companies suffer more without a framework because roles, salaries, and expectations get misaligned very quickly.

• A good ladder is built around three dimensions: scope (task → system → domain), autonomy (guided → independent → directional), and impact (self → team → organization).

• Junior, mid, and senior levels differ less by years of experience and more by the kind of problems they own and the trust you can place in them.

• Promotions should be based on observed behavior over 2–3 months at the next level, not on time served or self-declared potential.

• Leveling must be evidence-based: combine self-assessment, manager “trust tests,” and structured peer feedback, all mapped to the same rubric.

• A simple scoring grid for scope, autonomy, and impact (1–3) makes leveling repeatable, explainable, and easier to calibrate across managers.

• Communicating levels well means turning results into concrete growth plans, so people leave the conversation with next steps instead of labels.

• Aligning compensation bands with the career path is hard but essential so pay reflects level, not negotiation skill or hiring timing.