Engineering competencies are used to inform conversations about career progression between an engineer and their line manager. This is covered in the “how to use the competencies” guide.
There is no separate individual contributor route for progression, but the aim is to have a single set of competencies that are flexible enough to allow for a variety of ways that an engineer can demonstrate seniority.
A key idea here is that the more senior you are as an engineer, the more you should be helping those around you to achieve. There are many ways to do this:
Choosing not to pursue line management will mean you need to demonstrate that you are having a positive impact on others’ work in other ways.
The Product & Technology Executive/Technology Leadership Group made a decision in 2018: Principal roles and beyond must have a position open and advertised. The recruiting manager for each Principal Engineer role defines what the criteria for that role will be.
There is no specific cap on the number of Principals; it is governed by open roles and decisions about the organisation’s structure. To advance to Principal Engineer either a position needs to become vacant, or a new Principal Engineer role must be created, typically when forming a new team, significantly expanding an existing one, or some other significant change occurs in a technology group’s circumstances.
We do aim to include competencies for Principal Engineers within the FT engineering competencies, to act as a guide for recruiting managers and existing Senior 2 Engineers.
You should be considering them, however we do not ask for evidence on competencies from earlier levels. For example we expect our Senior 1 Engineers to still be exhibiting the competencies from the “Engineer” level as well as the “Senior Engineer 1” level, but they do not need to record them in their tracker.
Assuming that competencies from earlier levels are met means that we do not need to duplicate competencies across different levels.
This is covered in the “how to use the competencies” guide.
No. Competencies define what an engineer is expected to be doing at a particular level, and an engineer should be striving to meet as many of them as possible. However sometimes it may not be possible for an engineer to meet certain competencies in their current role.
For example, the competency “Regularly collaborates with team members from other disciplines to deliver features” would be difficult to meet for a person who works on a team which consists of only engineers.
In cases where an engineer’s current role prevents them from meeting a competency, the engineer’s line manager should try to find opportunities for the engineer to do so.
Promotion forms ask for evidence of an engineer’s readiness for promotion. The competencies are a framework for use by an engineer and their line manager to inform discussions on areas for improvement, the evidence that they compile is likely to be useful in a promotions case.
This provided evidence is not the only thing considered in a promotion case, for example feedback from stakeholders and peers is factored in.
The progression framework is not a check-list: providing evidence for all of the competencies does not guarantee promotion. Similarly if you’re unable to provide evidence for some of the competencies then this does not rule out a successful promotion case (see Do I need to meet all of the competencies?).
No. Examples are illustrative, and it’s possible to meet a competency in a different way. This is covered in the “how to use the competencies” guide.
People that report in to the CTO should use this framework. There are some people in the CTO organisation who are exempt at present as their jobs were sufficiently different to the rest of the CTO team that we felt they should not be included.
Excluded teams are:
Engineers at the FT that do not report in the the CTO may also find this framework useful and are free to use it.
No, competencies are not weighted. No competency is more important than any other for an engineer’s progression.
No engineer is expected to work outside of their contracted hours to meet any of the competencies. There may well be activities (e.g. support rota calls, tech talks) that provide evidence, but all of the competencies can be evidenced within working hours.
A group of engineers from across Product & Technology. See The Engineering Progression Working Group docs, or check the GitHub team for individual members.
There is a helpful guide written by HR that contains a framework that you can use when planning and delivering feedback on yourself or a colleague. See How do I give great feedback? for details about the AID model.