Large software companies usually have a leveling model and a body of documentation to help people-managers guide their direct reports on what level they’re at and how to improve and advance. They’re never great but they are a necessary evil once you get beyond about 20 developers and 3 managers in order to have at least the semblance of a level playing field when it comes to assessing people for their annual reviews.
Following is my lightweight leveling guide that keeps it simple and lets you get right to the point. I’ve used this guide for years as a manager of engineers, and have found it an effective way to communicate the essence of what I expect of engineers at different levels.
I guarantee you that (a) my model is compatible with your company’s standard level guide and (b) by using my model (in conjunction with your standard guide) you will be able to give your direct reports more meaningful feedback and coaching.
Here we go.
There are exactly four levels for engineers:
- Junior
- Intermediate
- Senior
- Principal
A junior engineer does not yet have complete knowledge of any domain, is still learning and needs a more senior person to guide them on most projects. They are still building their self-sufficiency and require supervision.
An intermediate engineer has built up complete knowledge of some domain or domains, and is capable of self-sufficiently carrying out work in those domains competently, without guidance and without need for rework. While they competently and reliably carry out work in those domains, they are not yet innovating new methods or products. They don’t require supervision but their work may require review.
A senior engineer is completely self-sufficient in that he or she has complete knowledge of some domains, and can autodidactically learn new domains. Developing new products or engineering techniques is also the mark of a senior. A senior engineer requires no supervision or work-review, but they do seek out peer reviews and discussions with other engineers to challenge themselves in their quest to increase their knowledge.
The principal engineer has complete knowledge of many domains, has developed several new products and new techniques that have been adopted by other engineers, and is able to join a new project in a new domain and quickly absorb the domain and make good engineering choices based on past experience from other domains. Very few people are truly principal engineers.
Are there degrees to principal engineers? Yes and no: one principal engineer will have more experience and capability than another, so in that way there are degrees to principalship that we could further qualify if we wanted to. However all principal engineers are adaptable, open-minded, and committed to learning and sharing - these qualities are the equalizers that should be used to identify principals.
This all boils down into the following levelling matrix. Note that to be considered to be at a level, every dimension must be satisfied at that level:
| Dimension | Junior | Intermediate | Senior | Principal |
|---|---|---|---|---|
| Domain Knowledge | Partial knowledge, requires guidance | Self-sufficient within known domains | Autodidactically learns new domains | Command of many domains. Able to join a project in a foreign domain and quickly absorb and understand it. |
| Competence | Requires extensive supervision | Requires review | Does not require supervision or review | Does not require supervision or review |
| Innovation | Does not innovate new products or methods | Does not innovate new products or methods | Innovates new products or methods | Has innovated several new products that have been shipped or methods that have been adopted by other engineers. |
| Learning Culture | Captures the knowledge that is being taught to them and does not need to be taught the same thing more than once. | Seeks new knowledge and techniques from more experienced engineers. | Actively seeks review and discussion from other engineers. | Proactively shares innovations with other engineers. |
Some additional context for these four dimensions:
Domain Knowledge encompasses both business domain and technical domain knowledge. For example an engineer may require domain knowledge both in healthcare informatics and Java microservice development to be able to meet the bar for intermediate in your organization.
Competence is a measure of their reliability, attention to detail, and ability to get the job done right.
Innovation is self-explanatory - juniors and intermediates are not innovating because they are focused on learning their own domains. To be a senior or beyond you must have demonstrated the ability to innovate.
The learning behaviors of juniors and intermediates are more oriented towards being taught, while senior and principal behaviors are around peer discussions and promoting good practices within the team.
It is or course entirely possible for an individual to be exhibiting behaviors on some of these dimensions at a level higher than what they are currently on - for example a junior engineer may not require supervision, but may still have only partial domain knowledge. This means they’re on their way from junior to intermediate, but are not there yet. Similarly an intermediate engineer may teach a colleague about an innovative technique, but still only be comfortable working within the domains they’re familiar with.
As an aside and in keeping with my view of software engineering being more akin to a craft than a science the levels described above happen to map to the medieval craftsmen levels:
- Junior - Novice / Student
- Intermediate - Apprentice
- Senior - Journeyman
- Principal - Master Craftsman