Part 1 - The Problem with Engineer Growth

"What do I need to do to get promoted?"

This is probably the most common question I've received as an engineering manager. It seems like there should be a straightforward answer - after all, most companies have career ladders that spell out the requirements for each level. Yet engineers often struggle to translate these requirements into actual actions they can take.

The problem isn't just about promotions either. Throughout my career, I've noticed patterns that make engineering career development particularly challenging:

• Career ladders define end states but not how to get there
• Performance reviews look backward instead of forward
• Goal-setting often becomes a checkbox exercise
• Day-to-day work feels disconnected from career growth
• Engineers are left to figure out their own path
• Long gaps between check-ins allow people to get far off-course

Most importantly, we often fail to clarify what success looks like at each growth stage. This leads to anxiety, especially for newer engineers who aren't sure if they're meeting expectations.

The Origin of Developer Roadmaps

I stumbled upon the concept of Developer Roadmaps while trying to improve our onboarding process. For each new engineer, I would create a detailed plan for their first 90 days:

• Day 1: Read specific documentation, meet key team members, and set up a development environment
• Week 1: Fix a carefully chosen bug, attend team ceremonies, learn deployment processes
• Month 1: Complete first feature, participate in code reviews, understand team practices
• Quarter 1: Lead a small project, contribute to planning, and become fully productive

The results were surprising and immediate. Not only did new engineers get up to speed faster, but they also reported feeling much less anxious about their new role. Why? Because at every step, they knew exactly what was expected of them and what success looked like.

This led to an insight: What if we applied this same systematic approach to ongoing career development?

What is a Developer Roadmap?

A Developer Roadmap is a living document that maps out an engineer's growth journey. Unlike traditional career development tools, it creates clear connections between daily actions and long-term career growth. It combines elements from several existing frameworks:

• Like a career ladder, it defines what success looks like at different levels
• Like OKRs, it sets clear, measurable objectives
• Like agile methodologies, it adapts and evolves based on feedback
• Like a good onboarding plan, it provides clarity and reduces anxiety

But it goes beyond these frameworks by:

1. Creating a clear path between the current state and the desired future state
2. Breaking down long-term goals into actionable steps
3. Establishing supporting habits that drive consistent growth
4. Providing regular checkpoints to assess and adjust
5. Balancing delivery impact with personal development

Why Developer Roadmaps Work

Developer Roadmaps are particularly effective because they align with how engineers typically approach problems. When faced with a complex technical challenge, most engineers will:

1. Define the desired end-state
2. Break it down into manageable pieces
3. Identify dependencies and prerequisites
4. Create a plan of attack
5. Implement incrementally
6. Measure progress and adjust

A Developer Roadmap applies this same systematic thinking to career development. It turns the nebulous challenge of "growing your career" into a series of concrete steps and measurable progress.

When Roadmaps Are Most Valuable

While Developer Roadmaps can benefit any engineer, they're particularly powerful in certain situations:

New Team Members

As in our onboarding example, roadmaps provide clarity and structure during the crucial first few months. They help new team members understand not just what they need to do, but why they're doing it.

Level Transitions

When engineers are working toward a promotion or role change, roadmaps help break down the journey into manageable steps. Instead of just pointing at a career ladder, we can create a clear path to reach the next level.

Uncertain Direction

Some engineers know they want to grow but are unsure in what direction. Roadmaps help them explore different paths, making incremental progress while keeping options open.

Skill Development

When engineers need to develop new capabilities - whether technical or leadership - roadmaps help structure the learning journey and measure progress.

Core Components of a Developer Roadmap

A Developer Roadmap consists of four main elements:

1. Long-term Vision: Where does the engineer want to be in 5+ years? This isn't just about job titles—it's about impact, expertise, and personal fulfillment.
2. Yearly Milestones: What specific capabilities and achievements will mark progress toward that vision? These align with both personal goals and organizational needs.
3. Quarterly Objectives: What concrete progress can we make in the next three months? These follow a 70/20/10 split:
   • 70% focused on delivery impact
   • 20% on learning and growth
   • 10% on innovation and exploration
4. Supporting Habits: What daily and weekly practices will drive consistent progress? These turn aspirational goals into actual behavior change.

The Role of Existing Frameworks

Developer Roadmaps don't replace existing frameworks—they enhance them. For example, let's examine how roadmaps interact with a Competency Matrix. (We will talk more in-depth about competency matrices later in this article)

The competency matrix provides an excellent map of what capabilities look like at each level. A Developer Roadmap uses this as input to:

1. Identify the current position in the matrix
2. Select specific competencies to develop
3. Create concrete plans to build those competencies
4. Track progress against clear examples

Similarly, roadmaps work alongside:

• OKRs by connecting personal growth to business objectives
• Agile practices by integrating growth into sprint rhythms
• Performance reviews by providing concrete evidence of progress and specific, actionable feedback

Part 2 - Creating and Implementing Developer Roadmaps

The Roadmap Creation Process

Creating an effective Developer Roadmap isn't a one-time event - it's an ongoing collaboration between manager and engineer. Let's walk through the process step by step.

Step 1: The Career Exploration Discussion

The journey begins with a deep conversation about career aspirations. This isn't your typical 30-minute one-on-one. Schedule at least two hours, and be prepared to really explore.

Setting the Stage

I like to start these conversations by explicitly stating that we're not looking for the "right" answer. Many engineers, especially those early in their careers, feel pressure to have everything figured out. They worry about committing to the "wrong" path or saying something that might disappoint their manager.

Make it clear that this is an exploration. It's okay to be uncertain. It's okay to change direction later. The goal is to understand where they'd like to go so we can start moving in that direction, even if the destination changes along the way.

Key Questions to Explore

Rather than jumping straight to "Where do you want to be in five years?", I find it more productive to explore around the edges:

• What parts of your current role do you find most energizing?
• What kinds of problems do you most enjoy solving?
• When have you felt most proud of your work?
• What do you envy when you look at more senior engineers?
• What would you like to be known for in the engineering community?
• How do you want to influence the organization?

Another technique I have lifted from “Deep Work” author Cal Newport is the idea of “Ideal Lifestyle Design”. What does your perfect day look like? Are you sitting by the side of a lake in your cabin while you review architecture diagrams? Are you living in New York City and visiting the city’s hottest nightspots and museums? I think many developers get stuck on “I want to get a job at a FAANG company” or “I want to be a CTO,” and don’t always stop to think about what doing those things gives you. Is it just money, freedom, and respect?

Common Patterns

Through these discussions, several common patterns typically emerge:

1. The Technical Expert: Engineers who want to dig deep into specific technical domains, becoming the go-to person for thorny problems in their area of expertise.
2. The Technical Leader: Those who want to guide technical decisions and help other engineers grow while maintaining hands-on involvement in coding.
3. The Future Manager: Engineers who find themselves increasingly drawn to software development's people and process aspects.
4. The Product Partner is someone who wants to work closely with product teams and turn business needs into technical solutions.
5. The Generalist: Engineers who prefer to maintain flexibility, developing broad capabilities rather than specializing.

Most engineers don't fit perfectly into any one category, and that's fine. The goal is to understand their interests and motivations, not to put them in a box.

Step 2: Setting the One-Year Horizon

With a sense of long-term direction, we can focus on the next year. This is where we start turning aspirations into actions.

Using Competency Matrices

This is where frameworks like the CircleCI Engineering Competency Matrix become invaluable. Rather than trying to improve everything at once, we can identify specific competencies to focus on.

For example, a mid-level engineer wanting to move toward senior might focus on:

• Technical Execution: Moving from "follows existing patterns" to "adapts patterns appropriately"
• Project Management: Moving from "needs help to break down work" to "effectively scopes and plans work"
• Collaboration: Moving from "participates in discussions" to "drives technical discussions"

Setting Achievable Goals

The key is to identify growth that is:

1. Observable: We should be able to see evidence of improvement
2. Achievable: Possible within a year with focused effort
3. Valuable: Matters to both the engineer and the organization

Rather than vague goals like "improve system design skills", we want specific objectives like:

• Lead design discussions for at least two major features
• Successfully break down a large project into implementable pieces
• Improve feature planning through better technical discovery

Notice that these goals are about demonstrating capabilities, not hitting metrics. While some metrics (like deployment success rate or PR cycle time) can provide supporting evidence, they shouldn't be the primary focus.

Step 3: Quarterly Planning

This is where the rubber meets the road. We use the 70/20/10 framework to break down our yearly goals into quarterly objectives.

The 70% - Delivery Impact

The majority of goals should focus on delivering value through your primary responsibilities. This ensures growth aligns with business needs.

For a mid-level engineer, delivery goals might include:

• Successfully own feature development from refinement through deployment
• Improve ability to identify and communicate technical risks early
• Strengthen collaboration with product managers during planning
• Build capability to handle multiple parallel work streams

Notice that these goals don't concern specific features (those come from your product process) but building delivery capabilities.

The 20% - Learning and Growth

This portion focuses on explicit learning and capability building:

• Complete relevant courses or certifications
• Study specific codebases or systems
• Practice new skills in controlled environments
• Participate in formal mentoring

The 10% - Innovation and Exploration

This is time for experimentation and creative work:

• Explore new technologies
• Contribute to internal tools
• Write technical blog posts
• Participate in hackathons

Making It Real

For each quarter, we want a mix of goals that:

1. Build on previous progress
2. Stretch into new areas
3. Provide clear evidence of growth

For example:

Q1 Focus: Project Leadership
Delivery (70%):
- Lead technical planning for team features
- Improve requirement refinement process
- Strengthen cross-team coordination

Learning (20%):
- Study system architecture through codebase reviews
- Practice technical writing through documentation

Innovation (10%):
- Experiment with new testing approaches

Step 4: Supporting Habits

Goals without habits rarely succeed. This is where we identify daily and weekly practices that will drive progress.

Effective Engineering Habits

Good habits for engineers often include:

Technical Growth

• Reading code in unfamiliar areas
• Contributing to code reviews
• Writing technical documentation
• Studying system architecture

Leadership Development

• Participating in technical discussions
• Mentoring other engineers
• Leading team ceremonies
• Writing technical proposals

Delivery Excellence

• Breaking down work into reviewable chunks
• Communicating progress clearly
• Identifying risks early
• Seeking feedback regularly

Setting Up for Success

Rather than trying to build many habits at once, start with one or two that will have the biggest impact. For each habit, define:

1. When it will happen (specific trigger)
2. What exactly you'll do
3. How you'll track it
4. What might get in the way

For example:

Habit: System Understanding
When: First 30 minutes each morning
What: Read code and documentation in one unfamiliar area
Track: Keep a learning journal
Blocker Mitigation: Block calendar time, set specific area to explore each week

Regular Check-ins

The roadmap comes to life through regular check-ins. These should be a regular part of your 1-on-1s.

Weekly Quick Checks (15 minutes)

• Review habit progress
• Discuss any blocks
• Celebrate small wins

Monthly Deep Dives (1 hour)

• Review progress in detail
• Adjust goals if needed
• Plan next month's focus

Quarterly Reviews (2 hours)

• Comprehensive progress review
• Set next quarter's objectives
• Refine long-term direction

Part 3 - Practical Implementation Guide

Getting Started

Preparation Phase

• [ ] Review existing frameworks (career ladder, competency matrix)
• [ ] Gather recent feedback about each engineer
• [ ] Block time for initial meetings (2-3 hours per engineer)
• [ ] Prepare example goals and growth areas for discussion
• [ ] Set up tracking system (documents, shared folders)

Initial Rollout

• [ ] Start with 1-2 engineers as pilot
• [ ] Schedule kickoff meetings away from sprint boundaries
• [ ] Set up recurring check-in calendar invites
• [ ] Create initial document templates
• [ ] Plan first monthly and quarterly review dates

Communication

• [ ] Explain roadmap concept to the team
• [ ] Set clear expectations about time commitments
• [ ] Clarify roles and responsibilities
• [ ] Establish communication channels
• [ ] Define update and review processes

Core Framework Documentation

1. The Roadmap Document

# Developer Roadmap: [Name]
Last Updated: [Date]
Next Review: [Date]

## Long-Term Vision (5+ Year Horizon)
[A paragraph describing long-term career aspirations and impact goals]

Key Elements:
- Career progression goals
- Technical expertise goals
- Impact and influence goals
- Personal development goals

## Current State Assessment
Role: [Current Role]
Level: [Current Level]

Key Strengths:
- [Strength 1]
- [Strength 2]
- [Strength 3]

Growth Areas:
- [Area 1]
- [Area 2]
- [Area 3]

## One-Year Goals

Technical Excellence:
[3-4 goals focused on technical capability development]

Leadership & Impact:
[2-3 goals focused on influence and team contribution]

Delivery & Execution:
[3-4 goals focused on shipping and impact]

## Current Quarter Focus (Q[X] [Year])

70% - Delivery Excellence:
[3-4 specific objectives with clear evidence of completion]

20% - Learning & Growth:
[1-2 specific learning objectives]

10% - Innovation & Exploration:
[1 exploration or innovation objective]

Supporting Habits:
Daily:
- [Habit with specific trigger and action]

Weekly:
- [Habit with specific trigger and action]

Sprint-based:
- [Habit tied to sprint ceremonies]

## Progress Log
[Running log of significant milestones, learnings, and adjustments]

Example Roadmap Entries

Progress Log - What Good Documentation Looks Like

June 15, 2024:
- Led design review for notification service refactor
  * Presented initial proposal to team
  * Incorporated feedback about message queue design
  * Final design approved with positive feedback from senior engineers

- Established code review routine
  * Reviewing 2-3 PRs daily before standup
  * Team noted improved depth of feedback
  * Created reusable checklist for API endpoint reviews

- Improved planning capabilities
  * Successfully broke down auth service migration into 8 manageable pieces
  * All sprints completed within estimated timeframes
  * Documented approach for future similar projects

Quarterly Goals - What Good Documentation Looks Like

70% - Delivery:
- Lead technical design for at least two major features
  Evidence: Design docs approved, implementation successful
  Impact: Reduces bottleneck on senior engineers
  Timeline: Complete first design by sprint 3

- Improve API endpoint reliability
  Evidence: Error rates below 0.1%, automated tests for all edge cases
  Impact: Better user experience, fewer support tickets
  Timeline: Implement monitoring by sprint 2, achieve metrics by quarter end

- Own feature planning for auth service migration
  Evidence: Clear breakdown, accurate estimates, on-time delivery
  Impact: Critical path for Q3 security initiatives
  Timeline: Planning complete by sprint 1, execution through quarter

20% - Learning:
- Master distributed systems patterns
  Evidence: Successfully apply in notification service design
  Impact: Enable scaling for enterprise customers
  Timeline: Complete MIT distributed systems course by sprint 4

10% - Innovation:
- Develop API testing framework improvements
  Evidence: Reduce test setup time by 50%
  Impact: Faster PR reviews, better test coverage
  Timeline: Prototype by sprint 3, team adoption by quarter end

2. Regular Check-ins

Weekly Quick Check (15 minutes)

# Weekly Development Check-in
Date: [Date]
Attendees: [Names]

## Habit Review
- What habits were successful?
- What got in the way?
- Any adjustments needed?

## Progress Update
- Key accomplishments
- Current challenges
- Support needed

## Next Week
- Primary focus
- Specific actions

## Action Items
[ ] Action 1 (Owner, Due Date)
[ ] Action 2 (Owner, Due Date)

Monthly Deep Dive (1 hour)

# Monthly Development Review
Date: [Date]
Attendees: [Names]

## Progress Review
Habit Development:
- Working well:
- Needs adjustment:
- Potential new habits:

Goal Progress:
- Major movements:
- Blocked areas:
- New opportunities:

## Growth Discussion
Successes:
- Achievements:
- Learnings:
- Positive patterns:

Challenges:
- Obstacles:
- Support needed:
- Resources required:

## Next Month
Focus areas:
- Primary objectives:
- Specific actions:
- Success indicators:

## Action Items
[ ] Action 1 (Owner, Due Date)
[ ] Action 2 (Owner, Due Date)

## Notes
[Key decisions and important context]

Example Monthly Review - What Good Documentation Looks Like

Goal Progress:
- Completed design review process improvement
  * Created template used by 3 other teams
  * Reduced average review time from 5 days to 2 days
  * Documented process in engineering wiki

Challenges Addressed:
- Time management: Created focused work blocks (9-11am, 2-4pm)
- Context switching: Reduced active projects from 4 to 2
- Technical debt: Dedicated Friday afternoons to refactoring

Learning Achievements:
- Completed 12 chapters of "Designing Data-Intensive Applications"
- Applied learnings to cache implementation
- Created lunch & learn session on CQRS pattern

Next Month's Focus:
- Lead auth service migration design (Sprints 4-5)
- Mentor new team member on API design patterns
- Complete distributed systems course modules 3-4

Support Needed:
- Review session with Principal Engineer on system design
- Clear project dependencies for auth service work
- Budget approval for advanced AWS training

Quarterly Review (2 hours)

# Quarterly Development Review
Date: [Date]
Quarter: [Q1/Q2/Q3/Q4]
Attendees: [Names]

## Quarter Review

70% Delivery Goals Progress:
- Goal 1: [Status with specific evidence]
- Goal 2: [Status with specific evidence]
- Goal 3: [Status with specific evidence]

20% Learning Goals Progress:
- Goal 1: [Status with specific evidence]
- Goal 2: [Status with specific evidence]

10% Innovation Goals Progress:
- Goal 1: [Status with specific evidence]

Habit Development:
- Established habits:
- Still developing:
- New habits needed:

## Impact Assessment

Technical Growth:
- Observable capabilities gained
- Areas still developing
- Evidence and examples

Leadership Development:
- Influence expanded
- Team impact
- Communication effectiveness

Delivery Excellence:
- Project successes
- Quality improvements
- Process contributions

## Next Quarter Planning

70% Delivery Goals:
[3-4 specific objectives with clear success criteria]

20% Learning Goals:
[1-2 specific learning objectives with measurable outcomes]

10% Innovation Goals:
[1 exploration or innovation objective with defined output]

Supporting Habits:
[2-3 specific habits with clear triggers and actions]

Success Indicators:
- Observable behaviors
- Concrete deliverables
- Feedback mechanisms

## Annual Goal Alignment
- Progress toward yearly goals
- Adjustments needed
- New opportunities identified

## Action Items
[ ] Action 1 (Owner, Due Date)
[ ] Action 2 (Owner, Due Date)

Writing Effective Goals

Goal Components

Each goal should include:

1. Clear objective
2. Observable evidence
3. Impact measure
4. Time frame

Example Structure

Goal: [Specific objective]
Evidence: [How we'll know it's achieved]
Impact: [Why this matters]
Timeline: [When we expect to see progress]

Example Goals - What Good vs Poor Documentation Looks Like

Poor Goal Documentation ❌

- Get better at system design
- Improve code quality
- Help with planning

Effective Goal Documentation ✅

Goal: Lead technical design for notification service refactor
Evidence: Design doc approved, successful implementation, team can explain design
Impact: Reduces bottleneck on senior engineers, improves system scalability
Timeline: Design doc by sprint 2, implementation complete by quarter end

Goal: Improve API endpoint reliability
Evidence: Error rates below 0.1%, automated tests for all edge cases
Impact: Better user experience, fewer support tickets
Timeline: Monitoring by sprint 2, metrics achieved by quarter end

Common Goal Anti-patterns

• Vague objectives without clear evidence
• Pure metric-based goals
• Goals outside the engineer's control
• Too many goals at once
• Overly rigid timelines

Creating Supporting Habits

Habit Components

1. Specific trigger
2. Clear action
3. Defined outcome
4. Way to track

Example Structure

When: [Specific trigger]
I will: [Specific action]
Until: [Completion criteria]
Track: [How to monitor]

Example Habits - What Good vs Poor Documentation Looks Like

Poor Habit Documentation ❌

Daily:
- Do code reviews
- Read documentation

Effective Habit Documentation ✅

When: First 30 minutes after standup
I will: Review 2-3 open PRs, focusing on:
- API design consistency
- Error handling patterns
- Test coverage
- Documentation completeness
Track: PR review comments log in notion
Blocker Mitigation: Blocked calendar time, configured PR notifications

When: Last 30 minutes of day
I will: Study one section of system documentation
- Take notes on patterns
- List questions for team
- Identify areas needing updates
Track: Learning journal entries
Blocker Mitigation: Set daily calendar reminder, list next day's section before leaving

Common Implementation Challenges

1. Maintaining Momentum

Challenge: Initial enthusiasm fades after a few weeks
Solutions:

• Build check-ins into existing rhythms
• Celebrate small wins consistently
• Adjust habits that aren't sticking
• Keep documentation lightweight

2. Balancing Workload

Challenge: Development activities get pushed aside for delivery pressure
Solutions:

• Integrate growth into daily work
• Make learning visible and valuable
• Protect innovation time
• Align growth with team needs

3. Measuring Progress

Challenge: Difficulty showing concrete growth
Solutions:

• Document specific examples
• Gather peer feedback
• Track habit consistency
• Note behavior changes

4. Keeping Documentation Current

Challenge: Roadmap documents become stale
Solutions:

• Update during check-ins
• Keep format simple
• Focus on key changes
• Use shared documents

Best Practices

Documentation

• Update in real-time during meetings
• Keep progress log current
• Document decisions and context
• Track adjustments and reasons
• Maintain evidence examples

Meeting Preparation

• Review previous notes
• Gather progress examples
• Identify discussion points
• Prepare specific questions
• Plan potential adjustments

Follow-up

• Document action items
• Set clear owners
• Define due dates
• Schedule check-ins
• Track completion

Adjustments

• Review regularly
• Make incremental changes
• Document reasons
• Communicate clearly
• Monitor impact

Summary: Making Developer Roadmaps Work

The Developer Roadmap framework provides engineering managers with a structured approach to engineer growth that bridges the gap between career ladders and day-to-day work. Its effectiveness comes from:

1. Clear Connection to Daily Work
   • Translates abstract career goals into concrete actions
   • Integrates development into existing workflows
   • Makes progress visible and measurable
2. Systematic Implementation
   • Starts with thorough career exploration
   • Breaks down long-term vision into achievable steps
   • Provides regular check-ins and adjustments
   • Builds supporting habits for sustained growth
3. Practical Framework
   • 70/20/10 split ensures balanced development
   • Regular check-ins maintain momentum
   • Templates and tools support consistent execution
   • Clear processes for documentation and follow-up

The key to success is maintaining the right balance: enough structure to drive progress, but enough flexibility to adapt to each engineer's unique journey and your team's specific context. Start small, iterate based on feedback, and remember that the goal isn't perfect documentation—it's supporting your engineers in building fulfilling careers.