Engineering competencies are used to help identify when an engineer is ready for promotion. We divide competencies into levels.
Each level represents the work needed to be promoted from one role into another, so the name of each level contains two different job titles:
So, for example, a Junior Engineer should be working towards the competencies at the “Junior to Mid” level.
Each competency has a summary which is designed to prompt a yes/no response. For each competency, an engineer should feel able to answer either “yes, I’m meeting this competency”, or “no, I’m not meeting this competency yet”.
In order to be promoted, an engineer must specify which competencies they are meeting for a level. We don’t expect that every engineer will meet all of the competencies, but the promotions board will consider all of the competencies when making a decision. Domain-specific competencies that don’t apply to an engineer’s role or specialism will not be considered as part of a promotions case.
Engineers are expected to provide evidence that they are meeting a competency when it comes to writing a promotions case. We expect a sentence or two, and an engineer’s line manager should be ready to provide further detail if necessary. It’s fine to use the same evidence for multiple competencies. Evidence must also be provided for competencies that are not being met to explain why they have not or cannot be met.
An example of how you might provide evidence for met and unmet competencies:
|Contributes to the personal development of more junior people||Yes||Has been mentoring a junior member of staff for six months. Ran a department-wide Git workshop|
|Leads hiring process for new Engineers||No||The team has not had to hire new engineers in the last year, and so this competency cannot be met|
A copy of the Engineering Progression Tracker (Google Sheet) is useful for keeping track of progress.
Some competencies are domain-specific. This means that the competency is only applicable if an engineer is working in a specific domain. For example, an engineer who builds web pages is expected to know about web accessibility, but we wouldn’t expect the same of an engineer who works in operations.
Some competencies have one or more examples. The examples are purely illustrative, and will not apply to everyone. When working towards a competency, an engineer does not need to be meeting any of the examples given if they can provide evidence that they are meeting the competency in another way.