Speaking frankly, I have been through the different roles and levels and I don't see the point of it all.
There's really only 3 non-exec roles in a software company, only 2 of them cut code, and one is just a placeholder for the junior devs.
Want to know how to keep people? Give them a little pay rise every 6 months and let them own a part of the product instead of having a no-responsibility JIRA burn and churn roster.
Those techniques assume that everybody’s motivations are the same, and that’s not true. Some people don’t want ownership. Others are already satisfied by their pay.
My answer to that question would be three parts:
1. Make sure that you agree on what success looks like, at the micro and macro levels.
2. Discuss what that person needs to achieve success for both of you - mentoring, training, tooling, access, time, money, whatever.
3. Frequently make sure they actually have what they need.
When people are regularly missing out on what you call success, you’ll probably get rid of them. When they’re missing out on what they call success, they’ll get rid of you by leaving. Don’t assume you’ve understood what they think success looks like until you’ve really discussed it with them individually.
Everyone gets the same raise as long as they aren't obviously failing? A lot of people who have a more competitive personality would be completely demotivated by something like that.
I've never worked at a big company and my immediate reaction is that I don't like this. It feels like most HN commentators share this kind of sentiment.
I'm genuinely wondering what people on the other side of this debate think about this. If you like having systems like this in your organization, what is it that you like about it?
I feel like in my case it would totally discourage me from actually trying to make the company do better and instead would make me focus too much on trying to please people who rate me on these criteria. But I guess maybe that happens in a large organization anyways. And I guess in that case it's nice to have at least some (albeit not perfect) set of rules. Is that kind of the idea for having these?
> I'm genuinely wondering what people on the other side of this debate think about this. If you like having systems like this in your organization, what is it that you like about it?
I like it. There are limitations and the frameworks can be misaligned with the ideal goals, but in general it provides the following benefits.
1. You aren't completely at the whim of your manager. Managers need to actually document what you did and why that aligns with whatever level on these frameworks. Other managers can provide oversight on this. The alternative is that career success is 100% opaque and based on the feelings of one person.
2. It helps me as a manager do performance evaluations. I'm glad to have a framework than to just go based on my feelings, because my feelings are often wrong.
3. It can help shift priorities for an organization that is working on the wrong stuff. This is hard and requires careful language and training, but in an ideal world these sorts of frameworks allow people to align their personal career goals with the goals of the company.
If you can make the company do better without pleasing the framework, then the framework may be wrong or perhaps your priorities are wrong. I've seen the latter plenty of times. Somebody insists that their work is just obviously impactful and therefore they don't need to measure anything but they are forced to measure it due to framework requirements and, surprise surprise, what they did wasn't that important after all.
Big companies have to put these kinds of frameworks in place to ensure they’re treating everyone equally. Otherwise you end up with the absurd situations of two different people being rewarded differently despite performing the same job equally well merely because they have a different manager.
The downside is everyone becomes a cog in the machine, with nobody being treated like an individual with their own strengths, weaknesses, needs, fears, and aspirations.
The alternative is to have a set of managers write prose about how good or not their people are, make vague proposal for raises, to have them approved or not depending on how liked they are by their own managers.
It more or less works, but getting a raise/bonus or not just feels like playing blind bingo most of the time. I once had a manager explain that regardless of the actual project results, because the product people felt stressed and unsure of delivery he wouldn’t give good ratings to the team members. Fighting it back we were just told that he was the one in charge of the criteria.
Career frameworks are vague and there’s still tons of politics in applying it, but at least you have a fighting chance to argue about what you were expected to do, what you did, and about how much you should receive accordingly (these levels are usually associated with salary/bonus scales)
PS: to address the obvious point, if one is constantly fighting, leaving for a better place is the best option, but in a large enough company you could instead change manager. Having a grid setting where you stand in the org also help these horizontal moves.
I have things I like and things I don't like about it.
I like it because I see it as a guide that helps people understand how to grow and also a framework for fair compensation.
Without guidance many people, especially early in their career, will not grow as fast as they want to grow. They will need to find other ways to get this guidance, such as a good mentor. Some people learn better with a mentor, some people learn better with a framework.
Without a compensation framework, it's hard to reason about whether people are fairly compensated across the board. So what happens is that people start to develop these anyways. If not done explicitly that means that everyone has to independently do the work of coming up with their own framework and then everyone ends up with different frameworks, resulting in things being less fair. A shared understanding and a shared language can be really helpful.
I don't like it because I feel like it will inevitably change from guidance to a checklist. And then it gets political and competitive. Just like you said, people definitely start focusing on the rating. A lot. I think there could be ways to combat this, but I think it's a difficult problem.
I think no matter what you implement, there's a tradeoff. For example, my current thought is that I want it to be more about guidance and less about compensation. So it's guidance on where to grow (if you aren't sure) and de-emphasize the compensation part. How do you do that? I think you basically need to make the guidance more general and then tailor it to a person. Therefore the guidance will be more hand wavy so you sacrifice some fairness. By de-emphasizing compensation, you'd probably also be making people who thrive on promotions and leveling up less happy.
I would honestly love to hear people's thoughts on this as I'm thinking about defining levels in the next few months.
I was at a unicorn that didn't have any career level/framework and was growing fast. _Many_ engineers and ICs were asking management to add such a framework. In other cases, other employees were complaining that "titles actually do matter", claiming that the lack of rank or title was hurting their future prospects (which wasn't wrong, for better or worse). A good amount of hires refused offers because their title didn't match their prior roles. And then when a title was made for them, the title became an informal career ladder within the org. And then comparisons were made and requests to be ranked similarly made.
So strangely, it was the employees that requested and pushed for this. Personally, back then I was not interested in the whole thing. Still not that into it, but I'd be more on the fence.
I work at a big'ish company with a system like this. They also started doing Scaled Agile for Enterprise (SaFe) after I started here, which is just straight up waterfall disguised in agile speak. I feel like a cog and I feel my soul draining away. I've given myself a deadline until August to quit.
You’re absolutely right. The most likely thing to happen is that a clueless middle manager will look at these criteria and ask their reports to justify, point by point how they’re achieving or not achieving the different things listed in these criteria and if they’re not how they can “improve”. It’s a supremely shitty way to chart out ones career growth. It’s going to lead to sooo many copycat “we do our career ladder like Dropbox so we must be just as good” clones.
On the other hand, I’m also somewhat glad that this shit is in published form and not some secondhand version pieced together by ex Dropboxers. I personally liked that it lays out what kind of a developer they expect at different levels.
I guess what I’m saying is that I like this as a guide rather than as a rule.
The people on the other side of the debate are the ones creating these sort of frameworks.
I can understand this is a reasonable response when you're given the task of evaluating people and pay them accordingly.
Still, this is exactly the reason I hate being an employee. I don't think the employee model is really good, in general.
In the end the role title is meaningless and if a contributor doing good work threatens to leave, it's usually cheaper to bump his pay than to pay for a recruiter's fee, interviewing, onboarding and risk of bad hires.
This doesn't work with weird hiring rules in crazy places (Eg. Amazon's expectation of firing a certain number of people).
I’ve worked on building these systems for our company. I don’t think they’re perfect by any means, but once you have more than about 20 people their presence is better than their absence, especially at the first three levels in the hierarchy (where there is broad commonality in contributions and expectations at the first two levels, with individual variation of course).
When people (often terrible leaders) try to distill the framework into a checklist of activities, things tend to go quite badly.
Does anyone at Dropbox past or present want to weigh in on the usefulness of this framework and its application with more context? The original post falls a bit short knowing where and how this is being applied inside the org.
I'm a former Dropbox employee, current Amazon employee. I find these frameworks very useful, especially as I've gotten more senior and been involved in hiring, performance reviews, and promotion assessments. Without this kind of framework, it's really up to individual whims about whether someone is performing well. And yes, these frameworks aren't perfect, but the act of creating and maintaining them is healthy for the organization to understand what it values.
IC7 => I transcend organizational boundaries by taking a holistic view of the company’s goals and taking responsibility across EPD, not just within my immediate scope of ownership.
I laughed when I read this description. The religious undertone tells me everything that I need to know about the company. Almost cult like?
HN comments are reaching new levels of bad, there's literally nothing fishy about that professional goal and it's what you should be aiming for as a principal dev.
My personal experience of almost all such frameworks is that their very existence drives competition for promotions. In turn, that can lead to (unspoken) resentment of one’s peers.
But once such frameworks are introduced, they are difficult to get rid of.
Consequently, I see the introduction of these frameworks as a committal culture step which should not be taken lightly.
One thing that I think many are missing in their understanding, is that this gives Junior to Mid-level engineers a path forward and direction to improve. Often it's the case an engineer will ask their manager "How can I improve or get to the next level?" and having reference documentation for how to impact an organization at a larger level is extremely handy. It also helps engineers relate their efforts to the bigger picture and help them formulate a vision for why we have a competency hierarchy and how to view it in terms of career frame-working.
At my company we also have a very similar engineering career framework, but the goal isn't to push everyone into boxes, but rather to help engineers understand what it means to have a large impact on an organization. This usually translates to more cross-team responsibilities and deliverables over longer periods of time.
Meanwhile interns and junior developers apparently have to handle the bulk of hiring and job interview work. No wonder people complain about the quality of job interviews.
This is getting a lot of hate here, but having a well defined career track is useful. So many people want to know what they need to do to advance in their career, yet for some reason think all they need to do is be good at closing tickets. Well, that’s not job at the upper levels. Yes, you do need an opportunity to demonstrate the skills, but it’s surprising how many people in my experience don’t understand that the job changes.
“Oh! But we have a flat organization”, you (cough Netflix cough) say. No you don’t. You have a shadow hierarchy. It’s there. The rubrics still exist. The “politics” and hurt feelings still exist. It’s just that the reasons are kept hidden, perhaps to make promotions more arbitrary and capricious. Does having an actual career make promotions and performance reviews objective? Of course not. Does it make promotions and performance reviews more aligned across the company? Yeah it does.
This is as much a tool for management, as it is for ICs.
At what point do we hit “peak emoji”? This document isn't describing summer jobs at the local park. It’s adults’ livelihoods. I can’t imagine referring to section trophy subsection rainbow in a serious discussion about my family’s source of income.
This is extremely close to the leveling rubric we use at the tech company I work at. The level names and language are slightly different, but it's the same matrices of scope and impact, and more or less the same qualifications.
I assume at this point there's so much cross-pollination going on between tech companies that many companies resemble one another operationally.
This must be a new local maxima that everybody is trending towards.
It is nothing new. It is similar since way back to MSFT times in the 90s and then google changed things a bit in the early 2000s.
Heck, I worked at a stogy financial company way back in 2003, (Fidelity), and had similar grades for engineering (4 grades), then Director, or VP for the highest level.
The Dropbox post would have been much more interesting if it had salary ranges attached to it. Otherwise it is just kinda fluff.
My own institution, a government lab, uses the same naming system (IC1 through IC6) with management also done similarly to what is shown here (M3-M6 at least, not sure about M7). And ICs are slotted into certain disciplines just as here (e.g., for us, Mechanical vs. Optical engineers).
And also with the same matrices. The framework is just the same, with the same griping about the language being slippery among those who use it ;-).
It was converted into the number/matrix setup from the earlier system with Senior, etc., some years ago.
Whilst I applaud this effort in transparency, I can't help feeling like there is a lot of weirdly specific prescriptive expectations and jargon in place here, with questionable practicality.
I wonder if a looser, more broadly-defined set of definitions might work better, recognising that people can add value in different ways.
Is there an alternative to heavy bureaucracy like this once a company reaches a certain size?
What other mechanisms exist for combatting nepotism, feeling too abstracted from the mission etc in a larger company?
Does a company like SpaceX with lots of people working towards big clear goals and where comp isn’t in the set of top reasons for choosing to work there use a levelling framework like this?
I work in a company of 10 where we all have strong drive towards the company goals. I’m worried that we will lose this as we grow but I can’t see any clear alternatives. I wonder whether you could build a company that operates like a loosely-coupled network of smaller teams with internal accounting so that teams are compensated based on some kind of internal team valuation (similar to how startup valuations are set by the ‘market’). Probably a terrible idea!
One alternative is an opaque hierarchy where it is difficult to find the goals or team missions documented anywhere.
It lets senior management avoid uncomfortable conversations about power relations while also creating a lack of clarity for individual contributors about what their subteam’s mission even is.
There are a lot of comments being against frameworks like this, as a manager, after having a quick glance, it's a pretty decent one compared to other things I have seen. It's important to note a couple of things, before we even look at the framework itself.
Different people want different things. A lot of people want to code and to be left alone. A lot of other people don't. They want to feel they are progressing towards something. Good frameworks usually state: we consider you as a senior if you are doing X & Y consistently. This helps people aligning their actions/work with a level. The group of people that usually don't care about this things, might start doing so, when their title (e.g. "Software Engineer") lacks the "senior" keyword and they are applying for a senior role elsewhere. This might seem nitpicking, but you would be surprised how many people don't even pass the first screening because they don't have the "senior" prefix. In bigger companies monetary compensation is assigned according to the person's level. In smaller companies, not so much. Everyone has the same title, and people can have significantly different salaries. A good career framework makes it very clear to everyone that if you want to earn between X and Y you need to be at a particular level.
As for the framework itself, I am big fan of giving examples. Say for instance on IC3: "I’m able to navigate ambiguity and remain resilient through ups and downs". I would love if they assigned a somewhat real example: "I am able to complete tasks, even when the acceptance criteria is not 100% clear.". They did well with the separation of the different functions: QA, Software Eng, Security Eng & Reliability Eng. A lot of places bundle some of these together and leave people scratching their head.
It seems like IC1 = Intern, IC2 = Junior, IC3 = Developer, IC4 = Senior. No idea why they're not named closer to that.
Also, do people think that these role descriptions are actually helpful? I find them extremely vague and generally unhelpful in determining if I'm performing at a particular level.
>> This framework is not a promotion checklist for your role
I hope this is true. There were too many times where things started out as a general guideline but gradually turned into a rigid checklist where one must tick all the boxes to get a promotion/raise.
[+] [-] aetherspawn|4 years ago|reply
There's really only 3 non-exec roles in a software company, only 2 of them cut code, and one is just a placeholder for the junior devs.
Want to know how to keep people? Give them a little pay rise every 6 months and let them own a part of the product instead of having a no-responsibility JIRA burn and churn roster.
[+] [-] blowski|4 years ago|reply
My answer to that question would be three parts:
1. Make sure that you agree on what success looks like, at the micro and macro levels.
2. Discuss what that person needs to achieve success for both of you - mentoring, training, tooling, access, time, money, whatever.
3. Frequently make sure they actually have what they need.
When people are regularly missing out on what you call success, you’ll probably get rid of them. When they’re missing out on what they call success, they’ll get rid of you by leaving. Don’t assume you’ve understood what they think success looks like until you’ve really discussed it with them individually.
[+] [-] golergka|4 years ago|reply
Everyone gets the same raise as long as they aren't obviously failing? A lot of people who have a more competitive personality would be completely demotivated by something like that.
[+] [-] aeternum|4 years ago|reply
This works for most people, but some are hyper-focused on comp and will ask every few weeks about why they're not leveling up and making more.
[+] [-] nthngtshr|4 years ago|reply
I'm genuinely wondering what people on the other side of this debate think about this. If you like having systems like this in your organization, what is it that you like about it?
I feel like in my case it would totally discourage me from actually trying to make the company do better and instead would make me focus too much on trying to please people who rate me on these criteria. But I guess maybe that happens in a large organization anyways. And I guess in that case it's nice to have at least some (albeit not perfect) set of rules. Is that kind of the idea for having these?
[+] [-] UncleMeat|4 years ago|reply
I like it. There are limitations and the frameworks can be misaligned with the ideal goals, but in general it provides the following benefits.
1. You aren't completely at the whim of your manager. Managers need to actually document what you did and why that aligns with whatever level on these frameworks. Other managers can provide oversight on this. The alternative is that career success is 100% opaque and based on the feelings of one person.
2. It helps me as a manager do performance evaluations. I'm glad to have a framework than to just go based on my feelings, because my feelings are often wrong.
3. It can help shift priorities for an organization that is working on the wrong stuff. This is hard and requires careful language and training, but in an ideal world these sorts of frameworks allow people to align their personal career goals with the goals of the company.
If you can make the company do better without pleasing the framework, then the framework may be wrong or perhaps your priorities are wrong. I've seen the latter plenty of times. Somebody insists that their work is just obviously impactful and therefore they don't need to measure anything but they are forced to measure it due to framework requirements and, surprise surprise, what they did wasn't that important after all.
[+] [-] blowski|4 years ago|reply
The downside is everyone becomes a cog in the machine, with nobody being treated like an individual with their own strengths, weaknesses, needs, fears, and aspirations.
[+] [-] makeitdouble|4 years ago|reply
It more or less works, but getting a raise/bonus or not just feels like playing blind bingo most of the time. I once had a manager explain that regardless of the actual project results, because the product people felt stressed and unsure of delivery he wouldn’t give good ratings to the team members. Fighting it back we were just told that he was the one in charge of the criteria.
Career frameworks are vague and there’s still tons of politics in applying it, but at least you have a fighting chance to argue about what you were expected to do, what you did, and about how much you should receive accordingly (these levels are usually associated with salary/bonus scales)
PS: to address the obvious point, if one is constantly fighting, leaving for a better place is the best option, but in a large enough company you could instead change manager. Having a grid setting where you stand in the org also help these horizontal moves.
[+] [-] jeffyang|4 years ago|reply
I like it because I see it as a guide that helps people understand how to grow and also a framework for fair compensation.
Without guidance many people, especially early in their career, will not grow as fast as they want to grow. They will need to find other ways to get this guidance, such as a good mentor. Some people learn better with a mentor, some people learn better with a framework.
Without a compensation framework, it's hard to reason about whether people are fairly compensated across the board. So what happens is that people start to develop these anyways. If not done explicitly that means that everyone has to independently do the work of coming up with their own framework and then everyone ends up with different frameworks, resulting in things being less fair. A shared understanding and a shared language can be really helpful.
I don't like it because I feel like it will inevitably change from guidance to a checklist. And then it gets political and competitive. Just like you said, people definitely start focusing on the rating. A lot. I think there could be ways to combat this, but I think it's a difficult problem.
I think no matter what you implement, there's a tradeoff. For example, my current thought is that I want it to be more about guidance and less about compensation. So it's guidance on where to grow (if you aren't sure) and de-emphasize the compensation part. How do you do that? I think you basically need to make the guidance more general and then tailor it to a person. Therefore the guidance will be more hand wavy so you sacrifice some fairness. By de-emphasizing compensation, you'd probably also be making people who thrive on promotions and leveling up less happy.
I would honestly love to hear people's thoughts on this as I'm thinking about defining levels in the next few months.
[+] [-] AYBABTME|4 years ago|reply
So strangely, it was the employees that requested and pushed for this. Personally, back then I was not interested in the whole thing. Still not that into it, but I'd be more on the fence.
[+] [-] notmeatall|4 years ago|reply
[+] [-] pm90|4 years ago|reply
On the other hand, I’m also somewhat glad that this shit is in published form and not some secondhand version pieced together by ex Dropboxers. I personally liked that it lays out what kind of a developer they expect at different levels.
I guess what I’m saying is that I like this as a guide rather than as a rule.
[+] [-] jokethrowaway|4 years ago|reply
I can understand this is a reasonable response when you're given the task of evaluating people and pay them accordingly.
Still, this is exactly the reason I hate being an employee. I don't think the employee model is really good, in general.
In the end the role title is meaningless and if a contributor doing good work threatens to leave, it's usually cheaper to bump his pay than to pay for a recruiter's fee, interviewing, onboarding and risk of bad hires.
This doesn't work with weird hiring rules in crazy places (Eg. Amazon's expectation of firing a certain number of people).
[+] [-] sokoloff|4 years ago|reply
When people (often terrible leaders) try to distill the framework into a checklist of activities, things tend to go quite badly.
[+] [-] Graffur|4 years ago|reply
What is it like working at a smaller company? I would love to except I imagine the pay would be worse (in my country - non USA)
[+] [-] rancar2|4 years ago|reply
[+] [-] nickm12|4 years ago|reply
[+] [-] rdm_blackhole|4 years ago|reply
I laughed when I read this description. The religious undertone tells me everything that I need to know about the company. Almost cult like?
Just my impression.
[+] [-] anamazingday|4 years ago|reply
> holistic (adj.) from holism ... 1926... from Greek holos "whole" (from PIE root *sol- "whole, well-kept") + -ism.
https://www.etymonline.com/word/holism
HN comments are reaching new levels of bad, there's literally nothing fishy about that professional goal and it's what you should be aiming for as a principal dev.
[+] [-] phonebucket|4 years ago|reply
But once such frameworks are introduced, they are difficult to get rid of.
Consequently, I see the introduction of these frameworks as a committal culture step which should not be taken lightly.
[+] [-] c4wrd|4 years ago|reply
At my company we also have a very similar engineering career framework, but the goal isn't to push everyone into boxes, but rather to help engineers understand what it means to have a large impact on an organization. This usually translates to more cross-team responsibilities and deliverables over longer periods of time.
[+] [-] tuckfrump666|4 years ago|reply
[+] [-] yellow_lead|4 years ago|reply
[+] [-] qbasic_forever|4 years ago|reply
[+] [-] systemvoltage|4 years ago|reply
[+] [-] murderfs|4 years ago|reply
[+] [-] quickthrower2|4 years ago|reply
[+] [-] creshal|4 years ago|reply
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] jonathankoren|4 years ago|reply
“Oh! But we have a flat organization”, you (cough Netflix cough) say. No you don’t. You have a shadow hierarchy. It’s there. The rubrics still exist. The “politics” and hurt feelings still exist. It’s just that the reasons are kept hidden, perhaps to make promotions more arbitrary and capricious. Does having an actual career make promotions and performance reviews objective? Of course not. Does it make promotions and performance reviews more aligned across the company? Yeah it does.
This is as much a tool for management, as it is for ICs.
[+] [-] tylerrobinson|4 years ago|reply
[+] [-] nickm12|4 years ago|reply
[+] [-] echelon|4 years ago|reply
I assume at this point there's so much cross-pollination going on between tech companies that many companies resemble one another operationally.
This must be a new local maxima that everybody is trending towards.
[+] [-] ardit33|4 years ago|reply
Heck, I worked at a stogy financial company way back in 2003, (Fidelity), and had similar grades for engineering (4 grades), then Director, or VP for the highest level.
The Dropbox post would have been much more interesting if it had salary ranges attached to it. Otherwise it is just kinda fluff.
[+] [-] mturmon|4 years ago|reply
And also with the same matrices. The framework is just the same, with the same griping about the language being slippery among those who use it ;-).
It was converted into the number/matrix setup from the earlier system with Senior, etc., some years ago.
[+] [-] draw_down|4 years ago|reply
[deleted]
[+] [-] my_usernam3|4 years ago|reply
Also this looks pretty on par with the companies I've worked for.
[+] [-] aeternum|4 years ago|reply
[+] [-] dang|4 years ago|reply
[+] [-] trilinearnz|4 years ago|reply
I wonder if a looser, more broadly-defined set of definitions might work better, recognising that people can add value in different ways.
[+] [-] cperciva|4 years ago|reply
[+] [-] whymauri|4 years ago|reply
[+] [-] davidhunter|4 years ago|reply
What other mechanisms exist for combatting nepotism, feeling too abstracted from the mission etc in a larger company?
Does a company like SpaceX with lots of people working towards big clear goals and where comp isn’t in the set of top reasons for choosing to work there use a levelling framework like this?
I work in a company of 10 where we all have strong drive towards the company goals. I’m worried that we will lose this as we grow but I can’t see any clear alternatives. I wonder whether you could build a company that operates like a loosely-coupled network of smaller teams with internal accounting so that teams are compensated based on some kind of internal team valuation (similar to how startup valuations are set by the ‘market’). Probably a terrible idea!
[+] [-] afarrell|4 years ago|reply
It lets senior management avoid uncomfortable conversations about power relations while also creating a lack of clarity for individual contributors about what their subteam’s mission even is.
https://www.jofreeman.com/joreen/tyranny.htm
[+] [-] RPeres|4 years ago|reply
Different people want different things. A lot of people want to code and to be left alone. A lot of other people don't. They want to feel they are progressing towards something. Good frameworks usually state: we consider you as a senior if you are doing X & Y consistently. This helps people aligning their actions/work with a level. The group of people that usually don't care about this things, might start doing so, when their title (e.g. "Software Engineer") lacks the "senior" keyword and they are applying for a senior role elsewhere. This might seem nitpicking, but you would be surprised how many people don't even pass the first screening because they don't have the "senior" prefix. In bigger companies monetary compensation is assigned according to the person's level. In smaller companies, not so much. Everyone has the same title, and people can have significantly different salaries. A good career framework makes it very clear to everyone that if you want to earn between X and Y you need to be at a particular level.
As for the framework itself, I am big fan of giving examples. Say for instance on IC3: "I’m able to navigate ambiguity and remain resilient through ups and downs". I would love if they assigned a somewhat real example: "I am able to complete tasks, even when the acceptance criteria is not 100% clear.". They did well with the separation of the different functions: QA, Software Eng, Security Eng & Reliability Eng. A lot of places bundle some of these together and leave people scratching their head.
[+] [-] ZephyrBlu|4 years ago|reply
- Why do they have 4 SWE levels?
- Why is there no Senior SWE level?
- Why is there no Junior SWE level?
It seems like IC1 = Intern, IC2 = Junior, IC3 = Developer, IC4 = Senior. No idea why they're not named closer to that.
Also, do people think that these role descriptions are actually helpful? I find them extremely vague and generally unhelpful in determining if I'm performing at a particular level.
[+] [-] dikei|4 years ago|reply
I hope this is true. There were too many times where things started out as a general guideline but gradually turned into a rigid checklist where one must tick all the boxes to get a promotion/raise.
[+] [-] pm90|4 years ago|reply
[+] [-] heisenbit|4 years ago|reply
[+] [-] pm90|4 years ago|reply