What Is "Level Worthy"?
Over the weekend Gergely Orosz tweeted about “Promotion Driven Development”, which is a problem in many large tech companies, and is tightly coupled with one of my least favourite concepts from my time in large tech; Whether everything you do is “Level Worthy”, and how that shapes your work even if you’re not looking to be promoted.
What are levels?
For those of you who haven’t experienced large companies, they tend to grade people based on specified skill levels (the various levels are sometimes called a “Career Ladder”). You get promoted (go up the ladder) by doing work that maps to the level above where you’re currently considered to be, and you usually get shown the door if you’re not performing at the level you’re being paid for. Most companies want to see a couple of performance cycles worth of “above level” performance before promoting you; Slipping down a level is rarely an option, so they’d rather make sure you can handle the promotion as opposed to losing someone valuable because they couldn’t sustain their “above level” performance.
A lot of companies have very similar leveling names as you can see on the website levels.fyi, but the definitions are different between companies. I’ve been “Staff Engineer” at four multi-billion dollar companies, and while there were a number of similarities, there were also a number of differences, so don’t assume a Staff Engineer at any company is a 1:1 mapping with a Staff Engineer at another company.
The theory behind levels has a lot of positive benefits; Theoretically, they provide an impartial set of tick boxes that allows your work to be judged as either below, at, or above your level. Unfortunately, in practice, there are a lot of problems.
Where theory meets reality
The biggest problem I’ve seen in multiple companies is that pure level-based performance judgements don’t take into account one of the biggest issues in software development today; A chronic shortage of software engineers.
I’ve been on teams in different companies where there were a number of open junior positions waiting to be filled, and had my direct manager flag in a weekly 1:1 that some recent work I’d done was too simplistic, or as it’s commonly phrased; It wasn’t “Level Worthy”. Doing work that’s not “Level Worthy” affects your performance rating, which in turn affects pay rises, bonus payments, stock options, and ultimately your continued employment at that company.
Claiming work is not “Level Worthy” is the managers sledge-hammer for getting engineers to do what they want; If you tell an engineer their work isn’t “Level Worthy” you can justify giving them a low-performance rating because they’d been warned about it, and that’s something they should be very concerned about.
If a manager can’t convince an engineer to take on a different project then claiming the current project isn’t “Level Worthy” is likely to change their mind. If the conversation is with a senior enough engineer the manager may also say “You should be able to work out yourself why that’s the case”, which means the manager doesn’t even have to justify, to the engineer, why they’ve made that claim. This isn’t a theoretical “might happen”, I know this happens because I’ve been in one of those conversations and talked to others who’ve been in the same situation.
While it’s absolutely true that writing code in a familiar language to an already defined specification isn’t what you’d expect a Senior/Staff level engineer to do for months, there are times when that is absolutely the most valuable thing they can do for a team. A Staff/Senior engineer is usually familiar with problems that can and do occur, and having someone like that avoid those problems can drastically reduce the uncertainty in the delivery time, which, in turn, can make a whole team, or an even larger part of the company, work more smoothly.
One of the most extreme examples of this I encountered was at one company that had a custom ~10,000 line python script wrapping a similarly large gradle build, which had a number of in-house gradle plug-ins, and the developers were complaining about build performance particularly in the IDE. I was told by my skip-level manager that the performance issues were, in some cases, in their view, a direct contributor to folk leaving.
Although I was led to believe we were hiring several more-junior engineers, at that time the team consisted of one person; Me. My long-term ideal goal was to simplify the build system and, if possible, get rid of the python/groovy/kotlin mix and replace it with a unified build system which focused on one thing; Building Code. As a first step I spent a number of weeks profiling builds, looking at build profiles across various machines, understanding where the performance issues were, writing up common causes of sporadic slow builds, pushing back against performance regressions, and making small changes to address the low-hanging fruit. For some users, it had little to no effect, for others the improvement was minor, but, the worst-case IDE build times (p95) overall reduced by ~30%. Was this all my work? It’s impossible to tell, but I could show how the trend down started shortly after I started work on the project, some bigger drops correlated with code I’d delivered, overall developer complaints about build performance seemed to have decreased during that time, and other engineers were responding positively to the work I was doing.
Then I was told that the code I was writing wasn’t complex enough to be “Level Worthy”, and that the effect on the average (p50) was so small it wasn’t worth the effort. Think about it; You’re trying to address a problem that has been flagged as a potential cause of employee attrition, but your work is considered too simple and so you shouldn’t do it. This is the kind of situation which drives the development of overly complex systems.
A month later my direct manager told me my top priority was to produce a set of dashboards to show the metrics for some projects; To me, it didn’t seem to fit my skills or experience, but I started working on it. A short time later I found that one of the teams involved had already highlighted issues with being measured by the specified metric, and that getting their agreement was considered the “Level Worthy” part based on that companies career ladder.
That was the moment when I realised the career ladder of that particular company wasn’t aligned with what I felt a senior engineer should be contributing to a company, and so I wasn’t around for very long after that.
In another company, I was working on a solution to a problem where it was technically feasible for individuals to be targeted and data extracted from their devices without their knowledge. It would require a non-trivial amount of work to get someone’s data, and most likely involve some state-level legal action, but, it was still possible and could cause damage to the reputation of the company in an area considered important. The first step was to refactor some code to move it between repositories.
It wasn’t a complex refactor; It mainly involved identifying and resolving the differences in available dependencies between the two repositories, being aware of the potential for licensing issues when moving code between two repositories that were used by different audiences, and switching between the different build systems used in each repository. There were ~20,000 lines of Java in total which wasn’t large when compared with projects I’d worked on in the past. The work had been started before by someone who was a couple of levels below my current grade, but their priorities had changed and so it hadn’t been completed.
That work was later called out as an example of work I was doing that wasn’t “Level Worthy” due to the lack of complexity in my changes to code.
That claim ignored that there was a partially finished piece of work embedded in my teams code-base waiting to be completed (so we were carrying tech-debt), it ignored the potential to avoid damage to the companies' reputation, ignored that other parts of the company supported completion of the work, ignored that “appropriate level” folk were already heads-down on projects for the quarter, but instead focused on the fact that, in isolation, the code I’d worked on in those few weeks wasn’t considered, by my manager, to be ticking enough appropriate level boxes.
A few months after that I was, in my view, being pressured into taking on a project where the end benefit wouldn’t be delivered to users for a number of years, involved less complexity than the refactoring, and the project only existed due to a problem with commitments the company had made without doing accurate cost modelling. The “Level Worthy” part was that the hole the company had got into was big enough to be on the radar of senior management.
Once again I felt the divergence in values between myself and the companies career ladder, and shortly afterward I left.
In both these cases, and others I’ve encountered, the fact that there is no-one else available to do the work seemed to not enter into consideration. The level I was at had a tick-box list of skills. The work I was doing for a period of time didn’t tick many of them. Therefore, the work wasn’t “Level Worthy”.
User benefits didn’t enter into the discussion, I just wasn’t ticking the boxes for my level, and therefore wasn’t completely delivering what the company expected.
Levels and power dynamics
Tick-box “Levels” create an unequal power dynamic; They create the impression that performance can be accurately measured by a summary of the employees work which focuses on a limited number of high-level aspects. The employee performance evaluations I’ve been involved with inside big tech companies involved engineers writing their view of my work and then relying on their manager representing me in performance reviews. The written sections tended to be limited in length and any additional information has to come from the manager.
I have never, at any large tech company, been given a voice in the performance review process beyond writing a short summary and hoping for the best. If someone in the performance review committee doesn’t feel that I’ve gone into enough depth on one of the tick-box points I don’t get the opportunity to expand on my answer, I just hope that my manager remembers enough about me and my work to address any concerns.
I have, at one company, had three managers in one performance cycle; Two of which disagreed about whether my work was “Level Worthy”. To me this highlights that Levels don’t create an impartial measure of someones' skills, but, instead, leave you in the hands of your managers' opinion of you, which can be skewed based on your personal relationship as well as their abilities as a manager.
I have been in a situation where one manager I reported into knew I had a lot of concerns about how they were managing the team. My view was based on my experience, team feedback, and, in a 1:1, that manager asked me for direct examples of issues, which I provided. Several people on the team knew that the relationship between the manager and I was strained. Now imagine that person being a strong influencing factor in what level your work is considered meeting when you’re not in the room. We’re all human, I doubt they were singing my praises.
I’ve also been at a company where my managers' written performance review was shared with me, and I was able to show that there was a factual inaccuracy in what had been written. Unfortunately, it wasn’t shared with me until after the performance cycle had been completed, and so any corrections weren’t going to change anything. Do I think it was malicious? No. Do I think they had a lot on their plate and mis-remembered something? Yes. Still, as someone whose career depends on a yearly or twice yearly review, knowing inaccurate information is being used to make a judgement is pretty disheartening.
So what am I doing now?
I co-founded a start-up where we absolutely do not do levelling.
We ask “What benefit is this to the business?”, and then ask the engineer if it’s something they want to do. When we’re evaluating someone’s work they’re in the discussion, they’re not waiting for us to make a decision based on a short bit of text and whatever their managers view is based on what they can remember.
Does this mean I do “simple” work? Yes, Absolutely! Two weeks ago I was designing, developing, and delivering a pipeline to push releases from GitHub into our automotive app distribution system. Last week I was re-implementing a hack to create a voice assistant using a different API. This week I’ll be re-writing some existing code to use Jetpack Compose instead of Android XML Layouts.
Would all that be considered “Level Worthy” at a big tech company? Probably not. Am I happier? Yes! Knowing I can see a problem and go fix it without worrying about whether there’ll be a hard conversation with a manager further down the line has been one of the most liberating feelings I’ve had at work in a looong time.
Feedback
If you have feedback on things that could be improved, added, or should be removed you can find me on Mastodon, GitHub, and Twitter.