This repo is trying to assist R&D organizations with building a career path for their software, product, QA engineers (I refer to all as engineers :).
As organizations grow, it is expected to provide the engineers with:
- A clear and continues feedbacks and expectations.
- A transparent career path.
Ladders assist in both. We use the ladders during our 360 reviews (you might know it as performance review) and 1 on 1s. The ladders describes an expected behaviors from the teams, as they grow. They do not list all the different behaviors and they might vary between some roles, yet it provides a guidance.
As leaders, we want each of the engineers to grow and when one does, it is a cause for celerbration :)
We are looking into 4 different areas of growth:
How well is the engineer executes his tasks.
As the engineer grows, it is expected that the execution level will increase. Handle issues faster, move with ease, monitor his work, etc.
How does the engineer progress with technology skills and knowledge.
What impact does the engineer has on the team, R&D and the organization. As the engineer grows, it is expected to see an increasing impact.
Some examples: review PRs, Mentoring, Assisting solving escalation, knowledge sharing etc.
Does the engineer share same culture attributes and values with us.
Independent Contributors and Engineering Managers are on two distinct career paths. This ensures that an engineer can grow in their career and take on more responsibility without having to become a manager. While there are some overlapping responsibilities between the roles, the skills and motivations necessary to be effective vary. We want engineers to consider becoming managers if they are interested in the core responsibilities of people management; if they aren’t, we provide a path to take on larger scope and demonstrate leadership as an individual contributor.
This helps ensure we don’t create an incentive to change roles for the wrong reasons. Engineers and managers at the same level will have comparable scope and impact on the business.
Becoming a manager is not a promotion, we define a promotion as moving up a level.
IC is independent contributor
EM is engineering manager
IC and EM can exist at the same level with different job criteria. Becoming an EM is not a promotion—it's a different role. Some criteria are shared between ICs and EMs at the same level.
Again, we don’t want to incentivize becoming a manager solely for career advancement.
Every employee has a level, which describes the scope, complexity, and impact of their role and factors into compensation. When a new employee joins, we evaluate his abilities and try to classify him based on the interview process and his experience. We understand this may not reflect the actual capabilities, so on his first months we will evaluate him and adapt as needed.
Each level builds on the criteria from the preceding level. So for example, an L4 must also meet all the criteria for an L3.
Any organization may define its own levels, ranging from L0 to L9 (if it make sense).
Levels has only some correlation to the market terminologies. Usually you will find salary tables and openings, based on Junior, Mid or Senior classifications.
What classify one to become a senior engineer?
One common way to classify a developer is based on "years of experience". If an an engineer has 8+ years of experience, he would probably be a senior. right ?!?
Wrong
Years of experience has a contribution to the classification, but do not guaranty a correlation. You may be very experience developer, with 8 years experience which will be L4, BUT you can also be 4 years experience developer which is L5.
We do not have strict minimum requirements for years of experience at any given level. We evaluate scope of responsibility and impact, and we never want to fail to recognize high performance due to a test like years of experience.
The rules that guide us are impact and value:
"are you able to perform the level responsibilities"?!?