Why you need an engineering ladder, and when to build one

As an engineering manager, have you ever had to ask, ‘What kind of skillset do we need for the team?’, ‘How do I evaluate my team?’, and ‘How do I compensate my team?’

Engineering is the most expensive and critical part of any tech company. As a manager, you want to build and lead high-performing teams, and you want to hire the right engineers for meeting your business needs. You then want those engineers to be motivated, challenged, and focused on the right problems. And you want to reward and recognize them equitably for the impact they are having. And if these are your goals, then what you need is an engineering ladder – a.k.a. a career framework.

But what does this engineering ladder look like? How does it differ for your fresh college graduate vs. your most senior engineer who drives the entire architecture and design of your tech stack? What does it look like when your organization has an engineering team size of 20, 200, or 2,000? And most importantly, as the business and the organization evolves, does the engineering ladder ensure that your biggest asset –  your talent –  are evolving and aware of what’s expected of them?

I don’t believe engineers lack motivation, I believe it is the systems that fail to create an environment for engineers to make magic. So instead of looking at engineering performance as an individual problem, I’ve found it useful to apply the systems-thinking lens to identify the set of interconnected elements, their relationships, and their function or purpose. 

An engineering ladder or a career framework is an organizational tool that provides an objective yardstick to anchor hiring rubrics, onboarding and ongoing expectations, performance evaluation, and compensation outcomes for the various systems of talent management. 

In this article, we’ll cover how individual performance relates to organizational culture, the complexity of objective assessment as an organization scales, and the necessity of evolving the framework itself as your business evolves.   

Individual performance, organizational culture, and the bridge

People are intrinsically motivated to excel when presented with a good mix of competence, autonomy, and purpose. We’ll assume that the vision for the team and its mission are well established, so the north star – the purpose – is mostly solved for. How do we then ensure that the engineers on our teams are feeling competent and autonomous, and how does an engineering ladder fit into that? How do we set up our engineers to be well-informed when asked: ‘Where am I at?’, ‘Where am I going?’, ‘How do I get there?’ and ‘What do I need to do more or less of?’.   

As an organization, you want to create an environment that fosters trust, eliminates bias, and drives high performance by building systems that facilitate the following:  

• A growth mindset and psychological safety allowing people to be vulnerable, adaptable, and challenged.  
• A culture of feedback through radical candor, recognizing accomplishments and setting expectations on areas of growth. 
• Respectful communication and collaboration norms, incentivizing knowledge-sharing, mentorship, and support.
• Transparency and consistency through equal access to opportunities; enabling all to stretch themselves and grow.
• Fair, equitable compensation in line with performance and rigorously structured pay parity processes.

All these require creating and sharing a clear, objective yardstick that serves to:

• Assess the scope of an individual’s impact and influence;
• Evaluate individual performance and impact against the organization’s business needs; 
• Drive accountability into the engineering culture and the values we want to see upheld.

This yardstick or rubric can take different forms: a ladder with levels (Rent the Runway, Patreon, CircleCI), or a career framework (Buffer). Each highlights a set of traits and expectations, along with a progression along certain criteria to articulate increasing scope, influence, and impact. 

For managers, it provides an ability to anchor performance conversations around these expectations. For individual contributors, it acts as a gut check on how they think they are doing against what is expected of them. It helps identify areas where they can stretch and grow themselves. It validates how the system perceives their contributions to those expectations. And for both, it creates a space to have conversations around the gaps they might need to address, or the challenges they need to take on to progress to the next level. 

An engineering organization evolves over time, and so must the engineering ladder. It is one of the few high-leverage tools in your toolbox that can help create and uphold the culture and values you want to enable. 

Organizations of 20 engineers and under

When you’re starting an engineering organization and hiring your first team of ~10 individual contributors (ICs), you know exactly what skillset gap you need to address. You’ve hired and successfully onboarded the new engineers, and you’ve communicated your expectations. You have a good understanding of what the team will work on, you know what you need to deliver and what impact looks like, and so do they. You may not even start a formal performance evaluation process, because the organization is successfully tapping into individual autonomy and competence.

When your team starts scaling, and gets to ~15 engineers, that understanding starts to dilute. There are various stakeholders and participants for every hiring decision: the interviewers, the moderator or recruiter facilitating the process, and the manager or leader making the hiring decision. There are very rapid changes to the organization as every new hire shapes and evolves the broader collective. 

Organizations of 20–200 engineers

When your team gets to ~20, your org structure starts to show some cracks. Misalignment between what’s expected and what’s delivered – or what’s delivered and its impact – creeps in. Your knowledge of individual contributors becomes hazy, because doing 20 regular 1:1s to keep an ongoing pulse becomes ineffective. Consequently, the ICs aren’t confident about what is expected of them.

Knowing if a certain engineer is partially meeting, meeting, or (greatly) exceeding expectations becomes a wild guess, proxied through word-of-mouth, social capital, and clout that some might have gained or lost. In short, calibrating performance for 20 ICs becomes highly subjective, and fast loses objectivity. This opens the door for various kinds of cognitive biases, including unconscious bias. 

When this team gets to ~40, things that worked well will cease. Areas that were starting to slow down will come to a grinding halt. Because with 40 engineers reporting to one individual, it is just not feasible to maintain a high bar for quality 1:1 engagements. So, you’ll evolve your organizational structure to hire or grow your first few engineering managers. Optimum team sizes recommend having 6–8 engineers to account for including on-call, junior, mid-level, and senior engineers. Your org structure now roughly has 5–7 teams of ~6–8 ICs each. You might even have a manager-of-managers to create organizations based on function or value. You might have a set of frontend, backend, and product design engineers rolled into one for each product offering; or you might have a mix of full-stack product engineering, and some horizontal infrastructure common across several products. 

At this stage, the org is still fairly small, so the cost of an underperforming individual is fairly high on the overall system. It is also big enough that your implicit system of ‘What are we hiring for?’ and ‘We know what high-performing looks like’ starts to disintegrate. And consequently, the third important pillar of talent management – compensation – becomes subject to pay disparity. 

Hiring – what are your needs?

At the hiring stage, you can drive clarity, alignment, and consistency across all the stakeholders by defining:

• The role and responsibilities that you’re hiring for; 
• The skills that best map to the role;
• An interview loop that best evaluates those skills; 
• A codified rubric for the interview panel to use for the hire/no hire decision. 

Evaluation – what are your expectations?

At the early stage, your company might need a senior engineer to be proactive and driven, and move fast and iterate to evaluate the right product-market fit. Or if your company is building a best-in-class security solution, you might need a senior security specialist to demonstrate critical thinking and rigor. 

You may not yet need a very thorough ladder but you’ll most definitely need to start identifying the traits you want to see demonstrated, the behaviors you want to incentivize (or disincentivize), and the outcomes you want to see driven; all for the engineering culture you want to create. You want to codify these for consistency across your 40+ engineering organization. And you want your managers trained and empowered to have these evaluation conversations with their teams. For further knowledge on this, Camille Fournier writes brilliantly about how to best evaluate your team’s performance. 

Review – how do you recognize, reward, and exemplify?

Culture is driven by the behaviors we reward or punish. Fostering a healthy, inclusive work environment that enables high-performing teams to deliver the highest impact sustainably requires:  

• Driving accountability. As a leader, you can set norms for how teams operate, how they collaborate, communicate, and treat each other with respect. However, systems also need to hold people accountable by disincentivizing bad behaviors and exemplifying good behaviors. For example, an engineer who provides high technical impact but has had repeated patterns of mistreating peers or other junior engineers, vs. a senior engineer who engages with the team through healthy dialogue and debate, provides technical mentorship, and is a force multiplier. 
• Recognizing impact. Consistent performance evaluation involves objectively assessing all individuals’ impact equitably, and weighing the impact itself through the lens of business value. For example, if your company has had serious availability and uptime concerns, you might need the engineers to think more about operational excellence, and building for scale and resilience vs. iterating and shipping new code.

Organizations of 200–2,000 engineers

As your business grows, the engineering function might also evolve into various sub-functions:  infrastructure, product engineering, operations, etc. 

The challenges around hiring, evaluation, and review can be in terms of differences in impact, scope of complexity, or related adversity. Here are some things you need to start thinking about:

• Hiring. When hiring across multiple teams, you need to drive an aligned understanding of the role you’re looking to fill, the teams you’ll need to staff, and the responsibilities that need to be owned. For example, hiring needs vary across an infrastructure backend engineer vs. a frontend engineer vs. a database expert vs. a new college graduate.
• Setting expectations. Communicating the scope of technical complexity and ownership becomes especially challenging as multiple teams could be at different phases of team or product maturity. For example, a newly-formed team that grows from 5–8 engineers is likely to go through forming and storming stages, vs. a well-established team of 8 that’s likely to be at a norming or performing stage. Setting up your new hires for success entails creating an onboarding plan aligned to the scope and complexity of the challenges they’re expected to tackle. Then through ongoing 1:1s, checkpoint and provide feedback on the outcomes against those expectations. 
• Calibrating performance & recognizing impact. Different stages of team composition, engineering functions, or software ownership can drive inconsistencies in assessing the impact of individuals across teams. Some projects may even have outsized business impact but lower technical complexity and effort. How does one then evaluate the impact objectively across teams and avoid having teams or functions being devalued and marginalized? For example, a team working on scaling its software and focusing on performance testing vs. a team whose focus is on enhancing UX for better supporting end-users. 

These are all opportunities to create fertile work environments that foster and nurture high performance. A well-designed engineering ladder can catapult the throughput and productivity of an engineering org, directly impacting the business growth for the broader organization. 

Conclusion

High-performing teams are not just hired, but nurtured, maintained, and retained. If designed well, a good career framework provides a transparent, clear view on an organization’s expectations. It helps assess an individual’s performance and impact against those expectations by providing relevant feedback and a roadmap for career progression. And in recognition of such impact, it enables a fair, consistent, performance-based compensation reward program. The framework itself must evolve as the organization scales and evolves, and as the needs of the business change.

Overall, a well-designed engineering ladder helps facilitate an engineering culture of fairness, transparency, and consistency, in line with an organization’s values, vision, and mission.