The caveat
Starting this post off with a strong caveat, career frameworks are tightly coupled to the type of engineering culture you have. Whether that be small (<20 engineers) -> large (>100 engineer) and either engineering led or not as a business. For this post I'm going to assume there are some engineering principles established and that you as a leader have relative autonomy in defining what success looks like for an individual contributor (IC) at your company.
Why they matter
Career development is one of the most meaningful levers an engineering leader has. But without a clear framework, growth becomes ambiguous and inequitable. Let’s explore how to build a career framework that actually works.
A high level approach
Building a career framework takes many forms, and it should certainly not be a checkbox exercise (i.e. do X amount of bug tickets per month, run A, B and C ceremonies). The wider engineering ethos should lean in to your entire evaluation of an engineers performance. You can think of this like a matrix. Each level of your IC ladder should have corresponding principles and ways of execution that demonstrate a higher level of competency on those principles. It's important that this exercise is a collaborative one with both other leaders & ICs alike so ensure a shared understanding of what could ultimately be described as impact.
Let's dive into a high surface level example to quickly articulate this point.
Assuming you have identified what "principles" are the defining factors of the business (team canvas exercise anyone?), a example matrix could look like this
n.b. these are example principles and should not be copied
| Technical Competency | Risk Appetite | Empathy | Delivery | Team Multiplier | |
|---|---|---|---|---|---|
| IC1 - Junior | Demonstrates curiosity and persistence when tackling unfamiliar code or concepts. Asks thoughtful questions to understand system behaviour | ||||
| IC2 - Mid | Completes moderately scoped features independently and with minimal rework. Begins to contribute to system design conversations. | Owns delivery of medium to large-scale features across multiple sprints. Helps unblock others. | |||
| IC3 - Senior | Supports others' growth through coaching and thoughtful feedback. Navigates conflict constructively. | ||||
| IC4 - Lead | Builds tools, patterns, or documentation that accelerate others. Coaches others into more impactful roles. | ||||
| IC5 - Staff | Shapes how the org thinks about technical risk. Balances innovation with safety, influencing risk posture at a strategic level. |
Defining behaviours
Now you have a clear vision on what your guiding lights so to speak are on what areas of success look like holistically for your engineering department, you can begin identifying what types of attributes and behaviours at each level look like. As mentioned, don't make this a tickbox exercise.
Once you have a list of attributes and behaviours that everyone is aligned on you can now put this framework to work.
Notice how the examples above are flexible enough to allow your engineers autonomy to define what an implementation of that may look like
In practice
Now you've got your broad strokes in place you can begin to empower your engineers to own their development. There's a few ways to achieve this but what’s worked best for me is maintaining a simple brag doc that mirrors the matrix above with examples, evidence and timestamps of when these behaviours occurred.
This type of documentation is invaluable when it comes to mid/year-end reviews and also promotion cases.
A career framework isn’t a static document, it’s a living agreement between you and your team about what growth looks like. Build it with them, revisit it often, and use it to celebrate the journey.
Luke Curtis
Engineering Leader with over 10 years of experience in building and leading high-performing teams. Passionate about transforming organizations through technical excellence and empowered engineering cultures.