It's a nice idea to things like this _in theory_. Medium has something similar they called Snowflake - https://github.com/Medium/snowflake ... but note the disclaimer...
> Heads up: Medium isn’t using this tool anymore, but you’re welcome to!
The problem with things like this is the typical engineering mindset, when shown a graphical or numerical analysis of their performance will zoom into analyse every detail and in the end it's just backed by the managers impressions and judgement.
For similar reasons I have a strong opinion that engineers shouldn't be paid performance related bonuses, because no matter what happens, it's just going to upset them - the best case - maximum bonus - just equates to a "meh". Better to pay a good base salary upfront ...
Bonuses that are variable with company performance are a common way to manage the reality for many businesses of “some years we have more money than others”. It seems better to pay bonuses that vary than to set high base salaries and lay people off in cyclical lean years.
That can work, if the scheme is (a) fair, and (b) transparent. I.e. something like "this is the formula we apply to the quarterly report to get everyone's bonuses".
Anything else just ends up being a lottery that helps no-one.
> Anything else just ends up being a lottery that helps no-one.
I've seen several occasions when corporate bureaucracy has prevented or delayed raises and promotions because of policy or budget wrangling, but not bonuses or stock grants. Bonuses are a tool for managers to reward and retain their high performers when those other options are not available during that fiscal year.
Oh it's not usually "fair" per se, but it's not like some people would get more than others (if done well), it's more like you don't always control all of the factors that get used to determine your bonus.
Like a QA engineer probably isn't directly tied to overall revenue, but it is a topline number that can be applied to everyone generally, so it can get used (in a general sense, I'm sure there are lots of specifics and nuances here).
> The problem with things like this is the typical engineering mindset, when shown a graphical or numerical analysis of their performance will zoom into analyse every detail and in the end it's just backed by the managers impressions and judgement.
The point of leveling frameworks is not to magically make everything objective and quantifiable—though I agree that is what many smart young people want and expect (after a decade+ in our Victorian education system)—it's to channel and provide a rubric that many different engineering leaders' (both EMs and ICs) impressions can be compared and contrasted in a structured and relatively fair way. The last thing you want to do is remove expert judgement from the equation, but in a medium to large org it shouldn't be one person.
> the best case - maximum bonus - just equates to a "meh"
Can you elaborate on this? I find it surprising since bonus pays are very commonly used in many industries (and, in fact, relied on very heavily in e.g. finance)
Performance bonuses the way they are commonly done doesn't work in finance and sales either -- they're just so in-grained in the culture that it's impossible to hire a finance or sales person without offering bonuses the common way.
The problem is that individual performance is a much smaller factor of outcome than commonly believed. Organisational structure, luck, social standing in the organisation, etc play a much bigger role. So in the end, performance bonuses usually reward random variation more than individual prowess (as much as the recipients would like to think otherwise.)
This one-armed bandit type compensation, when disguised as a performance bonus, creates confusion, weird incentives, limits creativity and experimentation, and breeds bad blood.
I remember going through performnace-related bonuses. If somebody tried super-hard and got a "level 5", they got a £5K bonus. Somebody ticking along without being outstanding got £3K. Most people realised the extra £2K wasn't worth the extra effort required to get it.
A raise of even a small amount makes a big difference over time because raises continue and even compound a little. Consequently, a cheap company will try to make the near certain portion of a bonus feel like part of your negotiated salary and extract effort with bonuses as ephemeral raises.
* They are happy to pay above market rates and keep giving you raises even if you are paid over market rates.
This would be the exception, and probably for some real specialist stuff.
If I get a 10% raise today, it will have no impact on my 2030 salary. Getting more stock might be a different thing if you are very lucky and the ducks line up.
in what industry does your previous salary not matter? (Not a snarky ask btw.) I have never entertained an offer blow my current salary, so personally find them highly correlated (sw eng).
Higher salaries will get disclosed more, because if I get an offer below my current salary, then I can disclose and at the very least get a match or refuse the offer. At a lower salary, there is a higher probability that the offer is higher, and my current salary does not matter.
I believe that people more rarely accept a downgrade in salary, so the probably of acceptance is also conditioned on the current salary. What this means is that the effect is biased and probably non-linear, but I wouldn't qualify it as non effect.
The bonuses where I am now are a % of the employee's base salary. A mid-level "meets" engineer can expect something like $20-25k during an average year for the company. Up to twice that for a strong year.
It's different in finance because a finance guy can go to his boss with hard proof and say "I made your company 10 million last year" and ask for 500k bonus.
But developers do not have hard proof and they will be getting 10k bonus instead.
Except it's not hard proof at all - no one person in a company can ever be even the primary reason for that 10 million profit. Further what happens in the years that by the same metric they lose a company 10 million...
Btw my current company offers bonus vacation days instead of financial incentives, and they go to every one in the team responsible for achieving product goals. I feel a little guilty as I'm enjoying that benefit today despite not having been at the company at the point the goals were met! I like the idea though...
I think your point is a good one. Though I'd say, that's why it's good to describe these as frameworks. They set the rough bounds of expectations, but much like API frameworks, the business logic is specific to your company and its culture.
Anyway - agreed that you cannot just blindly follow one of these. Also, this level of complexity in leveling is something that is best left to bigger organizations. It's almost limiting to impose it on smaller orgs.
I really like this, the Dropbox career framework, and the Monzo career framework. I synthesized all three recently into one that I keep for our company, and the work pays such dividends. We do quarterly performance reviews and not only does having a consistent standard make these fair, but it reduced my time to write them from 1 hour per report to about 30 min.
This attempts to recreate https://sfia-online.org/en , but it is way harder than one imagines and then is in danger of being too prescriptive and inapplicable.
It's better to go the other way and work out the principals behind progression... that the further in their career the more ownership, agency, and scope they have. Most things can be guided by merely understanding the principals of it.
It speaks to the spirit, the principals, behind progression... and that makes it extremely applicable to lots of fields, personal paths, and environments.
Your point of "Ownership, agency, and scope" resonated with me but it hasn't been my case. I have almost 30yrs experience and still struggle to earn agency and ownership on subject-matter topics/projects. Not sure what's my problem but my point is that none of these frameworks are prescriptive, only descriptive. Thanks for sharing your ideas.
This is really well done, but I feel like it (and other such frameworks I've seen) all start to fall apart at high levels of seniority.
What makes someone D7 in this framework? The real answer is not in the charts, it's that they're very business critical. Maybe they're some ultra-niche specialist or just the only one who's been at the company since the beginning and knows where the bodies are buried.
Things change in very interesting ways once the power dynamics between employer/employee shifts so the company asking the employee what it will take to make them stay.
My take on management (and really on life) is that every theory/framework is a setting stone and not instructions. The framework helps you think better, but reality is always more complex than what is described and covered in the framework. Best managers IMO are aware of many different strategies, frameworks etc and adapt it to suit their organization needs (based on the culture, people, goals, etc).
I think there is a cut off point where influence is entirely down to hierarchical position.
Yeah there are some people who cross cut and have personal influence (every org has celebrities) but in the main a person who has 1000 people reporting to him has more influence than someone with 2 people.
How they got to that position will have very little to do with the skills sets mentioned here.
It's kid of like the French aristocracy before the guillotine was invented writing a book on how to rise through the ranks to become an influence at court.
It's missing most of the important stuff
PS - I am getting overly cynical but I do favour democracy in organisations
These frameworks are behavioral competency frameworks. When used for assessing competencies, it is useful to define what the behavioral competency is unambiguously and include positive and negative examples of the behavior.
People have questions like, "What should I do to move up the next level?"
A competency framework helps answer that question. For eg: say one is currently a manager of people (a.k.a. First level manager) and is looking to move to a manager of managers role (eg: a department leader). A well-defined competency framework would clearly elucidate what kinds of behaviors are expected from each level so that it is clear when having a 1:1 discussion on career progression on where the behaviors are already demonstrated and where there are gaps that need to be worked on.
Raises, bonuses and promotion are generally a "past performance + future potential" decision. The competency framework can feed into past performance as well as future potential. Eg: a line manager who is performing poorly on certain competencies may not get his full bonus compared to a line manager who is demonstrating satisfactory levels in all required competencies.
Also, year-on-year trends of behavioral competency measurements can also inform on future potential/promotion decisions. Gaps can identify training / development needs.
Like all of these types of things, I believe that an heuristic approach is best, and this would work well for that.
I could see a training curriculum being developed from it.
However, it’s also likely that an HR policy document would be developed, with compensation and review targets. That could have … interesting … ramifications.
BTW: the image does not do so well in GitHub’s new dark mode.
On the first glance i really like that approach, but i have the feeling that something is missing. They address the issue, that different people can be on different stages in different axes, but there is no real explanation of how to handle the differences. Someone can come in with little knowledge about the technology, hence not using it before but is very well suited to "lead" discussions about architecture or processes.
Interesting read. I’m not sure I agree that an EM defining processes is operating at a more mature level than one merely challenging them. I try to challenge processes but coach the team to find the right processes themselves. I define processes myself only as a last resort.
The way I see it - you defined that the way to create further definitions is by collaboration, so it's still a way of defining process. I assume it's not just a "democratic" process to create a process ;)
btw, totally agree on the point though!
It’s a pretty comprehensive framework and I think it’s great. It would have been better if it also has a table of salary range for each level in different regions so that companies aren’t misinterpreting these job levels or, at worse, misuse the guide to manipulate their employees.
There are companies which make their employees senior or tech lead but pay $50k and use the same framework as expectation. It cannot be based entirely only on job titles because they are “free” to issue. You can easily mint new titles out of thin air. To back these job levels or titles with real value, their corresponding pays need to be relatable.
If we could print money without backing it with something scarce like gold, guess what will happen? Haven’t we seen some companies where there are so many senior, lead or even principal engineers but yet they getting paid lower than a mid engineer at another company? Job level/title inflation.
On the other hand, at companies that don’t inflate their job levels, they could still be underpaying their “seniors” and “leads” with junior or mid level pay while expecting them to operate along with the guide.
> If we could print money without backing it with something scarce like gold, guess what will happen?
We do. We adjust monetary supply for markets to be stable - money has been not backed by anything tangible for quite a while. Like with any proposed framework(also applies to monetary stuff) you find out how it affects outcomes and you adjust usage.
I feel like 50 years (since end of Bretton woods) really is not that long, plus we do still rely on petrodollar demand vibes to provide some sort of link to a commodity. We have yet to see the dollar truly unlinked from anything physical.
Yes, I’m aware that we do. I’m just trying to give an analogy of what I’m trying to convey.
In the case of job levels, employees really shouldn’t be shortchanged into believing the job titles given to them. The remuneration is a better indicator when in doubt.
Thanks for this, I didn't even see the labels and was re-reading the text trying to see if they had specified which chart directions represented which measurements!
Unfortunately GH doesn't have a way to alternate images in a readme based on light mode vs dark mode afaik.
Interesting idea. Tech lead at our company is mostly a TPM role mixed with the TL responsibilities listed here. In fact every senior engineer is expected to act in the TL capacity at our company. No commentary as to whether that is good or bad just relating that is how our (fairly large, well-known) org works
Thanks, very useful. I'm just finding it hard do adapt and find a place for the role of a Software/System Architect (which is very common in my industry) in the framework since it conflicts a bit with the other roles, mainly, Tech Lead. I`m thinking of Software/System Architect to be a TL7.
TPM & Prod managers are separate disciplines nowadays in most large companies. a PM continues to be user and product focused, while a TPM focuses more on the tech architecture & project management.
> Heads up: Medium isn’t using this tool anymore, but you’re welcome to!
The problem with things like this is the typical engineering mindset, when shown a graphical or numerical analysis of their performance will zoom into analyse every detail and in the end it's just backed by the managers impressions and judgement.
For similar reasons I have a strong opinion that engineers shouldn't be paid performance related bonuses, because no matter what happens, it's just going to upset them - the best case - maximum bonus - just equates to a "meh". Better to pay a good base salary upfront ...
Anyway use tools like this with caution IMO.