"Efficiency" here defined as "achieving the same appearance of being objective and spitting out a similar pseudo-meaningful result, but with less time/effort invested overall by the people involved".


I work for a small-to-medium sized technology company in London. They're growing incrementally and they're pretty decent people to work for/with on the whole.

I'm a "software engineer" and the company employs about 25 of those these days, with another ~100 technical people who do other things (like QA, design, operations, data science, Salesforce wrangling, etc.)

The software engineer career progression decisions are made yearly, in general. In October/November the company decides who's going to be promoted, and who (if anyone) is going to get payrises or bonuses, based on yearly performance. These are doled out in December.

Previously (pre-COVID and pre-organisational growth) management would decide on my performance through a methodology I had no visibility over. There may not have been a formal method, management knew everybody and I suspect they may have just used their guts. They'd meet with me in December and say "you're doing great, focus on these things for next year broadly, you're a B+ or something, you get a payrise" and I'd say "great, thanks". The hierarchy was pretty flat.

The ~100 other technical people still do things this way as far as I understand, potentially without the slightly patronising grade system.

Nowadays the software engineers are organised into a more hierarchical team structure, we've got 8ish teams with a "tech lead" on each team (generally these are experienced and/or skilled software engineers).

Career progression decisions have changed too. Management published a set of "competencies" last year and told all software engineers to begin "evidencing" them.

The competencies are vague rubric for a "good" engineer, and to be fair they're not awful, none of them are really obviously counterproductive. They're things like "Leads and encourages initiatives to simplify complex systems or processes".

Evidencing a competency involves gathering examples of your doing the thing throughout the year, taking screenshots of chat messages, linking to code you've written, tickets you've done, explanations you've given on tickets, etc..

There's also a feedback software application that provides the ability to comment about things other people did well. We're encouraged to use this to gather evidence too. In practice this often amounts to "trading" feedback with people that we like, we're all playing the game.

What's the problem?

I have no real issue with any of the above, I think that management have made logical decisions to arrive at this methodology.

My problem is that I'm evidencing 24 different competencies with several (more like 10 than 1) cogent evidence items required for each one.


  1. Takes ages
  2. Takes even more time for my tech lead who has to work on their own competencies, but also enable their reports to fulfil theirs
  3. I imagine takes even longer for the people in management who have to actually read the things and pretend that they're comparing them objectively
  4. Has me constantly thinking about evidence, rather than my actual job

Surely there's a better way to do this.

What have you tried?

I've had a look online for "open source" career ladders, and similar. Found the Monzo one and a couple of others. They seem to be vaguer in their description of their competencies (or equivalent), and require less targeted evidence. Generally the people at these companies seem to be able to get away with alluding to projects that they've done, or things that they've contributed meaningfully to, and leveraging the organisation's shared understanding of those things.

There seems to be less of a focus on screenshotting specific chat conversations and feedback items, and more of a focus on larger and more general work items.

As diplomatically as possible I plan to make this case to management at the end of the year. I probably won't evidence it as my attempt to "simplify a complex process" because, while funny, that's a bit smug. I'll gather a few more examples, talk about the Monzo methodology for this, and suggest that we move in that direction for everyone's benefit.

Is there any obvious problem with this?

To be clear, I think that it's great that we've got a public framework for career development, I just think that it's a bit much.

Something that I can immediately see being an issue is that we've set a baseline for the amount of evidence required for a promotion by defining granular competencies. If we move from that to having 2-3 broader competencies then we've created a prisoner's dilemma type scenario, where everyone would like to provide less evidence items for their competencies, but nobody can be the first one to do so because they'd look bad.

There are reputational ramifications of management changing their minds every year about how they're going to assess us as well, I'd imagine, but that should be something that it's possible to spin positively. "Look how agile we're being by iterating based on client feedback".

I'm sure I'm being blinkered here, I've never worked at an organisation that did things in a structured way before.

  • I'm a mid-level Software Engineer. I'm not in a position to decide, I don't have that kind of power. I'm aiming to be constructive. I don't think it'd be a good move to turn up and say "this took ages, thing bad." I think it'd be better if if I said "this could be better, here's a proposal that's not obviously stupid." Let me know if you reckon that's naive though!
    – SBaker
    Commented Oct 12, 2021 at 10:15
  • You make a very good point. I guess the missing detail here is that I know for a fact that about half of the people using the new framework agree with me off the record, and I suspect that the other half do too. I'm just trying to get that on the record constructively. (WRT Monzo specifically, I don't really think their purported financial crimes are in scope, I admit that there's an interesting chat to be had here about Volkswagon emissions tests and whether engineers are culpable for that sort of thing in general. Regardless, I've got more examples from better-respected organisations)
    – SBaker
    Commented Oct 12, 2021 at 11:04

1 Answer 1


Organizational Improvements are fine, but you need a Charter for it

You are probably not the only person to notice this issue, but organizational change is hard. It's a lot harder than coding. Showing up with a solution might be good, or might be seen as you putting your nose where it doesn't belong. So, my suggestion:

  1. Talk this with your boss. Get introduced to the owner of the process currently
  2. Talk with the process owner about your desire to improve the process
  3. Get a charter for this project. This makes it official, so you aren't just some yahoo telling other people how to do their job. It also gives it power so when you call meetings with stakeholders there's a reason behind it.
  4. Approach it like a project. You need stakeholders, requirements, etc., before you work on solutions.
  5. Improve the process and gain visibility throughout the organization as someone who can improve the organization.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .