17 May 2026 · Rehurz

Tracking True Competency Progression in Engineering Teams

Engineering leaders know the frustration: you watch a developer commit code regularly, yet you're unsure whether they're truly growing. Traditional output proxies (lines of code, pull requests merged, features shipped) feel hollow when you're trying to assess genuine competency progression. How do you know if your junior engineer is developing the problem-solving reasoning of a mid-level engineer? How do you spot when a senior developer's technical judgment has plateaued, or when they're building mastery?

Competency progression in engineering teams is one of the hardest things to track. Unlike sales metrics or support resolution times, engineering competency hides inside conversations, code reviews, and design decisions. This guide explores what real competency progression looks like, why common measurement approaches fall short, and how L&D leaders and engineering managers can design checkpoints that actually reveal growth.

The Measurement Problem: Why Traditional Metrics Mislead

The first barrier to tracking competency progression is that most organizations default to the wrong metrics.

A developer with high commit volume might be writing defensive, inefficient code. Another developer with fewer PRs might be architecting systems that prevent future problems. A senior engineer who ships less than junior peers might spend half their time unblocking team members, but that value never appears on a dashboard.

The core issue: output proxies don't measure thinking. They measure activity.

When you rely on commits, PRs merged, or features shipped, you're measuring output velocity. You're not measuring whether the engineer understood the problem, considered alternative approaches, anticipated edge cases, or explained their reasoning clearly. A developer can produce outputs without growing. They can copy a working pattern from a colleague, commit it, and appear productive while learning nothing about the underlying principles.

Code review feedback is more meaningful than commit counts, but it's subjective. One reviewer might focus on style; another on architecture. Feedback is inconsistent, rarely aggregated, and often forgotten within weeks. When a developer gets conflicting feedback across reviews, they have no way to synthesize it into a progression narrative.

Self-assessment is even more problematic. Developers are poor judges of their own skill. A junior engineer might genuinely believe they've mastered async/await after a few weeks of working with it. A senior engineer might discount their own progress because they hold themselves to a higher standard. Neither produces reliable growth data.

What Genuine Competency Progression Actually Looks Like

Before you can measure competency progression, you need to define it.

True competency progression isn't about learning more facts. It's about developing judgment. A junior engineer knows syntax; a mid-level engineer chooses when to break convention. A mid-level engineer solves problems in isolation; a senior engineer anticipates second and third-order consequences. A senior engineer knows their domain deeply; a staff engineer knows how to teach the domain to others without drowning in detail.

Across engineering, genuine competency progression follows these threads:

From Pattern Repetition to Principled Decision-Making A junior engineer learns patterns: "To check if a number is even, use modulo." A mid-level engineer understands when those patterns apply and when to break them: "Modulo is fast for single checks, but bitwise AND is faster in a loop, so here's why I chose it." A senior engineer can trace the trade-offs back to hardware behavior and knows when the pattern matters and when it doesn't.

From Task Completion to Problem Framing A junior engineer takes a task and executes it. A mid-level engineer questions the task: "Are we solving the right problem?" A senior engineer shapes the problem before it arrives: "We could build X, but if we solve Y first, X becomes trivial." Senior engineers raise competency because they reframe what the team works on.

From Following to Guiding A junior engineer follows design docs and architecture. A mid-level engineer contributes to design conversations. A senior engineer owns the conversation: "Here's the shape of the solution, here's what we're optimizing for, here's the trade-off, here's what we're not doing and why." They guide others up the competency ladder.

From Tool Expertise to Systems Thinking A junior engineer learns a language. A mid-level engineer learns languages. A senior engineer understands why languages exist and how to pick the right one for the next hire. They think in systems, not tools.

Genuine progression looks like expanding the scope of what you own, the time horizon you plan for, and the number of people who depend on your judgment.

Defining Competency Levels: Junior, Mid, Senior

L&D teams need a clear frame for what competency looks like at each level in your organization. This frame will vary by company (a FAANG staff engineer and a startup senior engineer face different problems), but the structure is consistent.

Junior Engineer (Years 0-2) Typical competency markers:

Writes working code within defined scope and guidance.
Asks clear questions when stuck.
Learns patterns from code review feedback and remembers them the next time.
Contributes ideas in design discussions, but defers to senior judgment.
Owns a task end-to-end with mentorship.
Can explain code behavior in simple terms; struggles with "why" questions.
Makes mistakes; learns from mistakes; doesn't repeat them.
No judgment yet about trade-offs; sees most problems as optimization problems with one right answer.

Mid-Level Engineer (Years 2-7) Typical competency markers:

Owns a subsystem; identifies and fixes design gaps without prompting.
Can design a solution, weigh trade-offs, and articulate the decision in writing.
Anticipates edge cases and failure modes; doesn't just react to bugs.
Gives code review feedback that teaches others; explains the principle, not just the rule.
Can mentor a junior; explains not just what, but why.
Owns hiring decisions for their level and below.
Communicates across teams; clarifies requirements that are fuzzy.
Begins to see patterns across codebases and projects.

Senior Engineer (Years 7+) Typical competency markers:

Owns a domain or critical system; shapes its long-term direction.
Makes architectural trade-offs that span multiple teams or years.
Raises problems the organization didn't know it had.
Code review feedback establishes standards; others cite it as a reference.
Mentors mid-level engineers; invests in their growth, not just their output.
Drives technical decisions through influence, not authority.
Communicates complex technical work to non-technical stakeholders.
Sees systemic problems and proposes solutions before they're crises.

These levels are not time-based. A talented engineer might reach mid-level in two years. A comfortable engineer might stay junior for five. But the competency markers stay consistent.

Designing Checkpoints That Reveal Real Growth

To measure competency progression, you need checkpoints. Not annual performance reviews (too infrequent and too biased). Not continuous surveillance metrics (too noisy and demotivating). But structured moments where you assess whether someone is developing the judgment, communication, and scope that defines the next level.

Structured Technical Conversation

The most reliable way to assess competency progression is a technical conversation with a clear scope. Not a pop quiz. Not a trick question. A thoughtful discussion about a real problem the engineer has worked on.

Structure: One hour, your engineer, an interviewer from inside or outside their team. Prompt: "Walk me through a system you've built or modified. What problem were you solving? What alternatives did you consider? How did you decide between them? If you built it again tomorrow, what would you change?"

What you're listening for:

Can they articulate the problem clearly?
Do they mention constraints and trade-offs?
Did they consider alternatives, or did they jump to the first solution?
Can they explain why their choice was right for this context?
Do they see limitations in their own approach?
Can they teach the reasoning, not just the code?

This conversation is far more predictive of competency progression than commits or PRs. And unlike code review feedback, it's consistent, documented, and comparable across multiple engineers.

Domain-Specific Skill Checkpoints

Different domains have different competency markers. Backend infrastructure demands different judgment than mobile development or data engineering. A progression framework should include domain-specific checkpoints.

For example, a backend engineer's progression might include:

Checkpoint at junior: Can design a simple schema for a new feature, explain trade-offs between normalization and denormalization.
Checkpoint at mid: Can propose a schema redesign that improves query performance and mentor juniors on the approach.
Checkpoint at senior: Can architect a schema evolution strategy that works across teams, minimizes downtime, and scales beyond the current data model.

These checkpoints test the same domain, but at different depths. And they're tied to business outcomes: shipping features, fixing performance, unblocking the team.

Longitudinal Assessment

The most important insight about competency progression is this: you can't measure it at a single moment. You measure it over time.

If you assess a junior engineer once in their first year, you get a snapshot. If you assess them every quarter, you get a progression curve. The curve is what matters. Are they learning? Are they learning faster or slower than peers? Where are they stuck?

A longitudinal framework might look like:

Month 0: Baseline assessment (first 30 days)
Month 3: First checkpoint (are they learning?)
Month 6: Second checkpoint (are they contributing independently?)
Month 9: Third checkpoint (are they solving novel problems?)
Month 12: Growth assessment (are they ready for mid-level scope?)

You don't need to do this for every engineer every quarter. But for high-potential engineers, or engineers in roles that matter to your business, longitudinal checkpoints are worth the time.

What to Measure Over Time: A Competency Progression Framework

Competency progression has several dimensions. If you measure all of them, you get a complete picture of growth.

Technical Judgment Can the engineer weigh trade-offs and make good decisions without guidance? Do they see the implications of their choices? This is the hardest to measure and the most important to track.

Progression at each level:

Junior: Makes reasonable choices within a defined scope; asks for help on trade-offs.
Mid: Makes trade-offs across subsystems; can explain the decision in written form.
Senior: Makes trade-offs that span multiple teams or years; the trade-off becomes the standard.

Communication Clarity Can they explain what they did and why? Can others learn from their decisions? This matters because senior engineers grow other engineers.

Progression at each level:

Junior: Explains code behavior; struggles with "why" questions.
Mid: Writes design docs that others reference; gives feedback in code review that teaches.
Senior: Communicates complex technical work across the company; writes posts others cite.

Scope and Ownership What size of problem do they own? Do they own a task, a feature, a subsystem, or a domain?

Progression at each level:

Junior: Owns a task (days to weeks of work).
Mid: Owns a subsystem or feature (weeks to months).
Senior: Owns a domain or critical system (months to years).

Teaching and Mentoring Do they help others grow? Senior engineers scale themselves by growing others.

Progression at each level:

Junior: Learns from mentorship; doesn't yet mentor others.
Mid: Begins mentoring juniors; explains principles clearly.
Senior: Actively invests in mid-level growth; raises standards through mentorship.

Speed and Autonomy Do they need guidance to move forward? How fast do they solve new problems?

Progression at each level:

Junior: Needs guidance regularly; ships slowly but accurately.
Mid: Works autonomously; ships at a good pace; asks for guidance selectively.
Senior: Extremely autonomous; speed increases through better judgment, not just experience.

Building a Competency Progression Framework for Your Team

Here's a simplified framework you can adapt to your organization:

Competency Progression Matrix
=====================================================================

Dimension      Junior       Mid-Level       Senior
=====================================================================
Technical      Within scope Cross-subsystem Org-wide trade-offs;
Judgment       with guidance with decisions  drives decisions via
               from seniors  and trade-offs  influence

Communication  Explains      Writes design   Shapes technical
               code behavior documents;      vision across
               in reviews    others cite     organization
                            them

Scope          Task/         Subsystem/      Domain/Critical
               Feature       Feature         System
               (days-weeks)  (weeks-months)  (months+)

Teaching       Learns from   Mentors         Actively invests
               mentorship    juniors;        in mid-level growth;
                            raises          establishes standards
                            standards       through mentorship

Speed &        Needs         Autonomous;     Extremely autonomous;
Autonomy       guidance      good pace;      speed via superior
               regularly     asks            judgment, not
                            selectively     experience

=====================================================================

To use this framework:

Define clear behaviors for each level in each dimension.
Assess each engineer quarterly against these behaviors.
Track changes over time.
Use the progression curve (not one-time snapshots) to make decisions about promotion, mentorship, or reskilling.

Frequently Asked Questions

Q: How often should we assess competency progression? A: Quarterly checkpoints are ideal for tracking meaningful change. Annual reviews are too infrequent to catch learning curves. Weekly metrics are too noisy. Quarterly gives you four data points per year and enough time for real change to occur.

Q: What if an engineer is competent at mid-level but doesn't want to grow to senior? A: That's fine. Competency progression doesn't have to mean vertical growth. A mid-level engineer might choose to stay individual contributor rather than move to management. Track progression in depth (becoming world-class in their domain) rather than scope (managing more people or systems).

Q: How do we measure competency progression for remote teams? A: The checkpoints change medium, not method. A structured technical conversation works via video. Code review feedback is the same whether you're collocated or distributed. Documentation is arguably more important in remote teams. The assessment principles don't change.

Q: Can we use AI to assess competency progression automatically? A: AI can help with data collection (summarizing code review feedback, tagging commits by type), but judgment about growth still requires human evaluation. An AI can flag potential talent or concerns, but the decision about progression should involve someone who knows the engineer's context.

Q: How do we avoid bias in competency assessments? A: Use structured conversations with the same questions for each engineer at each level. Document the assessment in writing so it's reviewable. Have multiple assessors (not just one manager). Compare across cohorts to catch systemic bias. Track whether women, underrepresented groups, and other engineers progress at similar rates.

Q: What if our senior engineers don't have time for quarterly checkpoints? A: You don't need formal checkpoints for every engineer. Focus on high-potential engineers or critical roles. For others, use lightweight signals: code review feedback, technical writing, mentorship activity. The goal is to catch growth, not to measure every engineer constantly.

Measuring Competency Progression with Rehurz

Competency progression requires seeing beyond outputs. But most L&D teams lack the structured moments to assess judgment and reasoning at scale. Code review feedback is scattered across conversations. Mentorship is informal. Self-assessment is biased.

Rehurz enables L&D leaders and hiring managers to define custom interview briefs tailored to your training program and competency framework. Your engineers take a short, real-time voice interview on their own time. The interview includes adaptive cross-questioning that reveals reasoning quality: if a candidate gives a surface answer, the AI probes deeper, asking "why" questions that expose whether they truly understand the principle or just memorized the pattern.

Rehurz generates per-employee retention reports showing what each engineer demonstrated during the interview, plus a cohort view so you can see how your team is progressing together. This gives you structured, comparable data on competency progression across your organization, capturing the same signal as a high-quality technical conversation but at scale.

Ready to move beyond output metrics and measure what actually matters? Book a demo to see how Rehurz enables competency assessment at scale. Learn more about corporate training solutions.

Closing

Competency progression is one of the most important metrics engineering leaders should track. Yet most organizations measure it poorly, defaulting to output proxies that reveal activity, not judgment. By defining clear competency levels, designing structured checkpoints, and measuring longitudinally over time, you create a foundation for growing your team intentionally. The engineers who understand their progression curve grow faster. The teams that measure it systematically build stronger technical cultures.