Career progression framework update

Alice Bartlett
Jul 5 · 4 min read

Back in April I introduced the work we had been doing on our career map for engineers. It was two things: A list of competencies, and a framework for using them.

I signed off with the promise that in June I’d be back with an update about what we learnt through getting from alpha to beta.

Since April we have focussed on getting feedback

When we shipped the alpha we had been working as a closed group. The most important part of getting to the beta was to ask our peers to work through the competencies and give us feedback.

To make sure we had a good spread of feedback from engineers across seniorities, we convened workshops for people at each engineering level. Though some people approached us to attend the workshops, we also made a point of inviting others to make sure we weren’t only getting feedback from the usual suspects.

At these workshops we asked attendees to read through the level they are currently at and the level above and tell us what they thought. Did they understand what was meant by each competency, was it too stretchy? Too vague? Not something they would usually do as part of their job?

We also asked everyone to give us feedback via GitHub issues.

We learnt some valuable lessons

Juniors engineers value specificity

For example — the mid level technical competency

uses programming language to make something

Was meant to mean literally anything — a bash script, a test, an API, an HTML page. But at the workshop it generated some discussion — did this mean build a full application? Was using third party software allowed?

Fixing these problems was straightforward because we had created a field in the schema for examples of what activities would fulfil this competency. It meant we didn’t have to spend too much time agonising over and perfecting precise wording of the competency, we could use various illustrative examples instead.

This finding is fairly obvious — people new to tech or new to having a career generally are going to have less experience to lean on as to what a reasonable expectation of their abilities is.

Linking competencies across boundaries is complicated

Initially we had a way to represent chains of competencies, however this became a tangly spaghetti mess as some competencies spawned multiple follow on competencies when they moved from eg Mid-level to Senior 1. However, being able to trace some themes through the stages of growth is very valuable so this is something we should maybe revisit.

People in remote locations need more comms

This was not a particularly fun lesson to learn. We have two remote engineering locations, Sofia and Manila. When we came to run workshops with them, unlike the London engineers, the Sofia and Manila teams were under-prepared. Though we had sent the same comms to everybody, the Sofia and Manila teams seemed to think this hadn’t applied to them. Presumably that’s because they get a lot of emails that don’t apply to them.

Their feedback is absolutely essential for this work, so though this has caused us a bit of a delay, we’re still going to set-up workshops for those teams.

Working in the open is great for this type of thing

Using GitHub to track our issues, and discuss improvements has many benefits:

  • Anyone can take a look at what we’re up to and pitch in if they feel like it
  • We can work asynchronously on stuff alongside our other work
  • Despite still being in alpha, the competencies were still useful to help people applying to the FT

We’ve worked through all the feedback so far

Since April we have had 62 issues and 67 pull requests on our competencies. We have released 7 versions of the alpha. On Friday 28th, we cut a beta release.

Now we’re going to use this beta framework in the next promotions round

One of the key functions of this framework is helping people understand when they’re ready to be promoted and justify it to the promotions board. These competencies aren’t finished (and might never be!), but we have shown them to enough engineers that we’re confident they won’t change substantially. The next big test for our work is going to be the promotions cases being readied for the board in September. We hope to learn what is missing in terms of helping people write their promotions cases and gather evidence for them. I hope we’ll also get feedback from the promotions board as to whether this has made their lives easier.

Team work makes the dream work

I didn’t do this work alone, thank you to everyone that participated in a workshop, raised an issue, emailed, slacked and championed us at the executive level. Thank you especially to my pals in the working group — Rowan Manning, Rhys Evans, Laura Carvajal, Tom Kennedy and Mark Barnes — who have ground through issues, pulled apart our work to make it better, organised and facilitated workshops, and remained cheerful and present through out this project.

See you in September

It’s been great to get people’s feedback in workshops but I want to see what happens when they have to this framework in anger. I’ll be back in September for another update. ✌️

FT Product & Technology

A blog by the Financial Times Product & Technology department.

Alice Bartlett

Written by

FT Product & Technology

A blog by the Financial Times Product & Technology department.