The problem is that compensation is normally tied to a title within your organisations. I agree with your sentiment however in reality its nice to have a ladder you can see / climb. It's especially helpful if your organisation has a pretty clear definition of what's expected in order to climb that ladder.
Also as mentioned in the forth link
it's great when your job ladder based on spheres of ownership and responsibility, rather than defined skill levels.
This means that your skills can be mapped to the core problems within the organisation that need to be solved by your skill set; as opposed to just being the generalist that gets assigned adhoc work but doesn't move up the hierarchy.
You make two points that I'm interested in hearing more about from DEV.
They seem to be the most common points I hear folks emphasize when talking about their idea of career progression:
increased compensation
"climbing the ladder" (which nearly always seems to translate into "job title progression", but perhaps that's not always accurate and imprecise language is to blame)
What are the People of DEV's reasons for valuing these things to such a degree that they prioritize them over others, like increased responsibility or complexity of challenge?
👋 Hey there, I am Waylon Walker
I am a Husband, Father of two beautiful children, Senior Python Developer currently working in the Data Engineering platform space. I am a continuous learner, and sha
In a way I fear "climbing the ladder". I want to be in a place that I can teach and mentor others. I want to be in a place with increased compensation. I want to progress in my career. These things fit the "climbing the ladder" model. What I dont want is to be pulled away from being able to solve really tough technical problems. I think we have a problem in the workforce with this model that as you climb the ladder you start doing less technical. Just because you are great at writing code and building stuff, doesn't mean that you will be great at management, or want to do management. But in todays model that is the most common path to career progression.
It's especially helpful if your organisation has a pretty clear definition of what's expected in order to climb that ladder.
Absolutely ❤️ A year or so ago at my company, a few of the engineering leads got together and created a progression map that feels like something you'd see in the rulebook for a table-top RPG 😆 but it's amazing, and has been incorporated into the engineer hiring process at this point as a reference for evaluating candidates applying for certain roles.
Basically, they broke down what they think it means to be a "good engineer" at every level on the company's "individual contributor" career track, and organized the resulting skill sets, abilities, attitudes and behaviors into a logical progression matrix. Then, they color-coded cells in the matrix according to whether expectations of competency changed between levels for that particular skill: green for "first expected at this level", orange for "growth expected from previous level", and no color for "no change".
Here is an example of the progression for a trait they termed "Growth Minded":
I love it. It served me well in one-on-one's with my manager and peer reviews.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The problem is that compensation is normally tied to a title within your organisations. I agree with your sentiment however in reality its nice to have a ladder you can see / climb. It's especially helpful if your organisation has a pretty clear definition of what's expected in order to climb that ladder.
Also as mentioned in the forth link
This means that your skills can be mapped to the core problems within the organisation that need to be solved by your skill set; as opposed to just being the generalist that gets assigned adhoc work but doesn't move up the hierarchy.
You make two points that I'm interested in hearing more about from DEV.
They seem to be the most common points I hear folks emphasize when talking about their idea of career progression:
What are the People of DEV's reasons for valuing these things to such a degree that they prioritize them over others, like increased responsibility or complexity of challenge?
In a way I fear "climbing the ladder". I want to be in a place that I can teach and mentor others. I want to be in a place with increased compensation. I want to progress in my career. These things fit the "climbing the ladder" model. What I dont want is to be pulled away from being able to solve really tough technical problems. I think we have a problem in the workforce with this model that as you climb the ladder you start doing less technical. Just because you are great at writing code and building stuff, doesn't mean that you will be great at management, or want to do management. But in todays model that is the most common path to career progression.
Absolutely ❤️ A year or so ago at my company, a few of the engineering leads got together and created a progression map that feels like something you'd see in the rulebook for a table-top RPG 😆 but it's amazing, and has been incorporated into the engineer hiring process at this point as a reference for evaluating candidates applying for certain roles.
Basically, they broke down what they think it means to be a "good engineer" at every level on the company's "individual contributor" career track, and organized the resulting skill sets, abilities, attitudes and behaviors into a logical progression matrix. Then, they color-coded cells in the matrix according to whether expectations of competency changed between levels for that particular skill: green for "first expected at this level", orange for "growth expected from previous level", and no color for "no change".
Here is an example of the progression for a trait they termed "Growth Minded":
I love it. It served me well in one-on-one's with my manager and peer reviews.