|
|
[[_TOC_]]
|
|
|
|
|
|
# Introduction
|
|
|
|
|
|
In order to achieve as fair distribution of salaries as possible,
|
|
|
we use the ladder system which ranks employees according to three parameters:
|
|
|
scope of their contribution, their skills and their work experience.
|
|
|
|
|
|
We use the same ladder for different profiles of engineers as much as possible.
|
|
|
These include back-end, front-end and database developers,
|
|
|
business analysts, data scientists etc.
|
|
|
|
|
|
|
|
|
# Skills
|
|
|
|
|
|
Skills are evaluated on a scale of 1 to 7 as follows:
|
|
|
|
|
|
|
|
|
## Skills Level 1
|
|
|
|
|
|
**An engineer focused on learning principles, practices and tools required in production.
|
|
|
Works towards mastering those principles with a goal to become more self-sufficient.
|
|
|
Helps where they can, may work independently on assigned technical tasks or user support.**
|
|
|
|
|
|
* Works under close supervision
|
|
|
|
|
|
* Not expected to deliver production-ready results independently
|
|
|
|
|
|
* **Anti-patterns:**
|
|
|
Not self-motivated; needs someone to tell them what to do next.
|
|
|
|
|
|
## Skills Level 2
|
|
|
|
|
|
**An engineer that is not yet fully independent and often needs support and validation of results by more skilled coworkers.
|
|
|
Expanding their understanding of principles, practices and tools;
|
|
|
focused on improving the quality of their output and effectiveness of their work.
|
|
|
Will be expected to complete small technical tasks independently, or larger tasks with well-defined specifications.**
|
|
|
|
|
|
Has some background in software engineering.
|
|
|
Will be expected to learn more about conventions, standards and best practices of the industry,
|
|
|
and development techniques such as testing, source control, task planning etc.
|
|
|
|
|
|
* Delivers production-quality outputs without much supervision
|
|
|
|
|
|
- demonstrates basic understanding of industry best practices
|
|
|
(formatting, modularity, source control usage)
|
|
|
|
|
|
- able to write clear and readable artifacts (code, documentation etc.)
|
|
|
|
|
|
- reads and understands existing artifacts on their products
|
|
|
and in the common codebase with some guidance
|
|
|
|
|
|
* Participates in technical design of features with guidance
|
|
|
|
|
|
* Rarely does the same mistake twice
|
|
|
|
|
|
* Familiar with concepts outside their immediate expertise
|
|
|
(SQL, Application Development, System Infrastructure, Business Analysis)
|
|
|
|
|
|
* Debugging
|
|
|
- Able to troubleshoot issues in development environment with some direction
|
|
|
|
|
|
* **Anti-patterns:**
|
|
|
Poor output quality.
|
|
|
More inclined to blame-complain than roll up sleeves.
|
|
|
General helplessness.
|
|
|
Disregards team process.
|
|
|
|
|
|
|
|
|
## Skills Level 3
|
|
|
|
|
|
**Solid engineer, capable of owning and successfully completing mid-size modules with little supervision.
|
|
|
Understands and is well-versed in using the principles, practices and tools.
|
|
|
Focused on growing as an engineer by designing and implementing increasingly complex tasks.
|
|
|
Capable of producing quality results without detailed up-front specifications.
|
|
|
Contributes to the team's growth by mentoring junior team members
|
|
|
and actively participating in efforts aimed at improving team processes.**
|
|
|
|
|
|
* Can work independently as necessary
|
|
|
with quality comparable to the company-level.
|
|
|
|
|
|
- Artifacts are well maintained and
|
|
|
easily maintainable by other members of the team
|
|
|
|
|
|
- Routinely performs testing / QA of their product
|
|
|
and takes appropriate steps when issues are encountered
|
|
|
|
|
|
- Writes tests for new functionality that they're responsible for
|
|
|
|
|
|
* Owns small-to-medium features from technical design through completion
|
|
|
(at least those aspects that apply to their expertise)
|
|
|
|
|
|
* Proposes design approaches for review and agreement
|
|
|
from peers and their supervisor.
|
|
|
|
|
|
* Is able to understand existing artifacts and avoids reinventing the wheel.
|
|
|
|
|
|
* Capable of prioritizing tasks;
|
|
|
avoids getting caught up in unimportant details and endless "bikeshedding"
|
|
|
|
|
|
* Comfortable with concepts outside their immediate expertise
|
|
|
(SQL, Application Development, System Infrastructure, Business Analysis)
|
|
|
|
|
|
* Debugging
|
|
|
- Takes an analytical approach to testing and debugging
|
|
|
and does not flail around blindly.
|
|
|
|
|
|
- Understands how logging, error handling and
|
|
|
related aspects of the system work and
|
|
|
takes initiative to improve those aspects when necessary.
|
|
|
|
|
|
- Able to troubleshoot and solve issues in development environment
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* **Anti-patterns:**
|
|
|
Disappears into products that don’t matter to the business.
|
|
|
Fails to identify or communicate big roadblocks.
|
|
|
Us-vs-them attitude.
|
|
|
Continually underestimates timelines.
|
|
|
Constantly overwhelmed with details and complexity.
|
|
|
Doesn’t take operational excellence seriously.
|
|
|
Solutions are more complicated than necessary.
|
|
|
|
|
|
|
|
|
## Skills Level 4
|
|
|
**Wholesome engineer, capable of solving difficult issues and completing large modules or mid-sized projects by effectively leading a team of more junior members.
|
|
|
Shows high proficiency in using the principles, practices and tools.
|
|
|
Does not need guidance and can be trusted to do quality work effectively.
|
|
|
Focused on gaining experience with larger and more demanding projects and improving their collaboration skills to maximize their contribution to the quality of the whole team.**
|
|
|
|
|
|
*This level does not include detailed requirements as there are different paths an employee might take from level 3 to level 5. Employees at skills level 4 will fulfil all requirements for level 3 and a significant share of requirements for level 5.*
|
|
|
|
|
|
|
|
|
## Skills Level 5
|
|
|
**Experienced engineer, capable of taking end-to-end responsibility for a team's work on large projects and products.
|
|
|
Masters the industry practices and tools: effective in practice (how to get things done), but also possessing a deeper understanding of theoretical and conceptual foundations (why are we doing things this way), as well as the contexts in which they are useful (the right tool for the job, no one-size-fits-all).
|
|
|
Focused on continuous improvement of the team through guidance, mentorship and sponsorship; improving the company through education, cross-team consulting and active participation in strategic decision-making.**
|
|
|
|
|
|
|
|
|
* Technical skills
|
|
|
|
|
|
- Understands and is able to make well-reasoned
|
|
|
design decisions and trade-offs in specific area.
|
|
|
Able to work in other areas of the codebase with guidance.
|
|
|
|
|
|
- Designs ground-up architecture on medium sized products
|
|
|
(from the point-of-view of their expertise -
|
|
|
SQL, Application Development, System Infrastructure, Business Analysis etc.)
|
|
|
|
|
|
- Multi-disciplinary
|
|
|
(business analysis, programming, db design,
|
|
|
IT infrastructure, special skills etc.).
|
|
|
|
|
|
- Recommends patterns and best practices
|
|
|
on applying concepts and principles
|
|
|
from their own expertise in other disciplines
|
|
|
(app programmer to DB developer, business analyst to app programmer etc.)
|
|
|
|
|
|
* Field expertise (e.g. land administration, CAP, etc.)
|
|
|
|
|
|
- Understands the policies and processes well enough
|
|
|
to pro-actively consult the client.
|
|
|
|
|
|
- Can estimate the complexity of particular requirements
|
|
|
and guides the client towards reasonable solutions.
|
|
|
|
|
|
* Debugging
|
|
|
- Able to diagnose and solve issues that occur in production environments.
|
|
|
When solutions require skills outside their expertise,
|
|
|
seeks appropriate help and provides them
|
|
|
with clear instructions for solving the issue.
|
|
|
|
|
|
* Writing
|
|
|
- refactors existing artifacts, making them more readable and maintainable.
|
|
|
|
|
|
* Quality of deliverables is sufficient
|
|
|
to contribute to the re-usability and efficiency improvement
|
|
|
of the development company wide
|
|
|
|
|
|
* Skilled at working in a team, teaches others how to work in a team.
|
|
|
|
|
|
|
|
|
* **Anti-patterns:**
|
|
|
Arrogance.
|
|
|
Doesn’t delegate.
|
|
|
Always says “yes” and suffers burn-out.
|
|
|
Jumps into execution without careful consideration.
|
|
|
Spends too much time chasing the newest “shiny” technology.
|
|
|
Lets details slip through the cracks.
|
|
|
Fails to raise awareness of products at risk or people-problems.
|
|
|
|
|
|
## Skills Level 6
|
|
|
**Mature engineer, capable of leading delivery of the most complex projects and products that span multiple teams.
|
|
|
Focused on excellence of the teams they work with and the long-term technical excellence of the company as a whole.**
|
|
|
|
|
|
* Has worked (and lead) on more production products
|
|
|
|
|
|
* Very competent in several production-related areas and
|
|
|
demonstrates additional competencies in other software lifecycle areas.
|
|
|
|
|
|
* Technical skills
|
|
|
|
|
|
- Has some experience in each of the basic software development lifecycle
|
|
|
steps needed to ship a product.
|
|
|
|
|
|
- A go-to expert in one large area of the codebase;
|
|
|
understands the broad architecture of the entire system.
|
|
|
|
|
|
- Designs ground-up architecture on large products.
|
|
|
|
|
|
* Writing
|
|
|
|
|
|
- Leveraging best practices and writing artifacts
|
|
|
that serve as examples for other employees.
|
|
|
|
|
|
- Actively participates in establishing and following best practices team-wide.
|
|
|
|
|
|
* Field expertise (e.g. land administration, CAP, etc.)
|
|
|
|
|
|
- Could act as a paid consultant for the specific field if needed.
|
|
|
|
|
|
* **Anti-patterns:**
|
|
|
Over-emphasis on scaling or high availability far beyond business needs.
|
|
|
Doesn’t collaborate or ask questions.
|
|
|
Condescending.
|
|
|
|
|
|
## Skills Level 7
|
|
|
|
|
|
* Can solve critical problems.
|
|
|
|
|
|
* Results are first-rate compared with state of the art.
|
|
|
|
|
|
|
|
|
## Notes on Skills
|
|
|
|
|
|
* Each of the levels includes all previous levels.
|
|
|
|
|
|
* There is an intentional jump between 3 and 5 as in practice it divides
|
|
|
an employee who has to be instructed for most of their work,
|
|
|
from one who can take responsibility for a large part of a products. 5 is "take care of it" level. Errors will be done, but person will take care that there is no need for other to clean the mess.
|
|
|
|
|
|
* There are some fields which have a very limited pool of experts
|
|
|
and significant demand, resulting in higher salaries.
|
|
|
People working in these fields can (not must) be bumped up the skills ladder
|
|
|
based on the field and their experience in this field:
|
|
|
|
|
|
- DB-PL/SQL - up to 1 point
|
|
|
|
|
|
- IT - up to 0.5 points
|
|
|
|
|
|
- DevOps - up to 1 point
|
|
|
|
|
|
- Machine learning - up to 1 point
|
|
|
|
|
|
* There can be other individual's skills taken into account (e.g. math, marketing, etc.), which can be measured in s similar manner as "development skills" - subjective and approximate. Such skills needs to be pro-actively applied at least at the level of the base skill score and should be scaled (increasing the 'impact factor') according to the base skill level (broader context, mentoring, etc). I.e. someone at level 5 cannot get additional points for just learning a new skill, but is expected to mentor in that skill, etc.. If an employee does not meet this, they could lose the extra point when advancing in basic skill level.
|
|
|
|
|
|
* We should take into account any skill that helps us produce quality output on producion products or that helps the company develop and improve. When trying to assess the value of a skill, we could consider the following:
|
|
|
|
|
|
- the level at which a person masters a skill can differ: in the ladder, 1-3 is learning to be proficient, and 5-7 is about ability to mentor others in the skill, obtaining a deeper understanding, applying it in a broader context and elevating the company towards excellence in the particular area;
|
|
|
- the weights of different skills are obviously subjective, but could be guided by comparing the skill against the needs that the company has, and the impact a skill has on the output of the company (or internal improvement);
|
|
|
- some skills are rare on the job market;
|
|
|
- some skills are inherently more difficult to learn than others;
|
|
|
- some skills are inherently broader / more complex / deeper than others.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# Scope
|
|
|
|
|
|
By scope we evaluate what kind of responsibility a person is capable
|
|
|
(e.g. has demonstrated it)
|
|
|
and willing to take in the company.
|
|
|
This is not necessarily aligned with current responsibilities -
|
|
|
if there are no current activities that need such an engagement from the individual,
|
|
|
they should not be "penalised".
|
|
|
It is the management's responsibility to use available resources efficiently.
|
|
|
|
|
|
With introductions of teams,
|
|
|
the responsibility of products management will hopefully be spread amongst the group.
|
|
|
However,
|
|
|
it is still expected that some people will carry more responsibility,
|
|
|
coordinating technical/organisational details with other colleagues.
|
|
|
|
|
|
|
|
|
## Scope Level 1
|
|
|
|
|
|
* Does production work but does not own any specific area of the product.
|
|
|
|
|
|
* Works on non-shipping products / deliverables or on other people's areas -
|
|
|
for example, fixing errors or bugs, making small modifications,
|
|
|
and implementing very small features.
|
|
|
|
|
|
* Accepts feedback graciously and learns from it –
|
|
|
rarely repeats the same mistake.
|
|
|
|
|
|
* Responsibility area is less than 1 person-year (PY) per year.
|
|
|
|
|
|
|
|
|
|
|
|
## Scope Level 2
|
|
|
|
|
|
* Works with more senior members of the team.
|
|
|
They ensure a steady progress on tasks.
|
|
|
|
|
|
* Capable of taking well-defined sub-tasks
|
|
|
and completing these tasks in a reasonable time
|
|
|
(with mentoring and assistance from more senior engineers when needed).
|
|
|
|
|
|
* Active in team participation and interaction with product owners.
|
|
|
|
|
|
* Responsibility area is 1 to 1.5 PY
|
|
|
|
|
|
|
|
|
|
|
|
## Scope Level 3
|
|
|
|
|
|
* Owns small to medium-sized product or product part.
|
|
|
|
|
|
* Leads the development.
|
|
|
|
|
|
* Product-minded; asks first if and why should we build this, before how should we build it. Solves problems not only on the technical level, but also on the product level.
|
|
|
|
|
|
* Oversees other people’s work on a few of their products
|
|
|
|
|
|
* Being able to communicate a message to the recipient
|
|
|
(and make sure one gets it).
|
|
|
|
|
|
* Learning about and mastering at least one large area of the codebase
|
|
|
with a high-level understanding of other components.
|
|
|
|
|
|
* Actively participates in artifact reviews within the team, product or area of expertise.
|
|
|
|
|
|
* Responsibility area is 1.5 to 3 PY
|
|
|
|
|
|
|
|
|
|
|
|
## Scope Level 4
|
|
|
|
|
|
This part is on purpose not specified in detail —
|
|
|
it should be used for employees that
|
|
|
fulfil all requirements for level 3
|
|
|
and a significant share of requirements for level 5.
|
|
|
|
|
|
* Responsibility area is 3 to 4 PY.
|
|
|
|
|
|
|
|
|
|
|
|
## Scope Level 5
|
|
|
|
|
|
* Owns larger production products
|
|
|
|
|
|
* Oversees other people’s work on wider array of products.
|
|
|
|
|
|
* Ensuring that results produced by other employees
|
|
|
are acceptable to stakeholders.
|
|
|
|
|
|
* Taking initiative to identify and solve important problems,
|
|
|
coordinating with others on crosscutting technical issues.
|
|
|
|
|
|
* Owns cross-team initiatives addressing quality and improvement of artifacts on the company level.
|
|
|
|
|
|
* Responsibility area is 4 to 5 PY.
|
|
|
|
|
|
|
|
|
|
|
|
## Scope Level 6
|
|
|
|
|
|
* Owns an area or major products
|
|
|
|
|
|
* Identifies and proactively tackles technical debt
|
|
|
(before it grows into debt
|
|
|
that requires significant up-front work to resolve).
|
|
|
|
|
|
* Making others better through artifact reviews,
|
|
|
thorough documentation, technical guidance, and mentoring,
|
|
|
often serving as a lead on a product.
|
|
|
|
|
|
* Involved in other aspects of the business, not just operations. Such as marketing, HR, internal organization, etc.
|
|
|
|
|
|
* Owns strategic company-wide initiatives, advancing the company as a whole.
|
|
|
|
|
|
* Responsibility area is larger than 5 PY
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Notes on Scope
|
|
|
|
|
|
There is an intentional jump between 3 and 5 as in practice it divides an employee who has to be coordinated for most of their work,
|
|
|
from one who makes sure that the work is done, more or less "no matter what".
|
|
|
|
|
|
Responsibility area is measured in person-years (PY) and represents how many people's work one owns (is responsible for) within a year on average.
|
|
|
It is common that one is partly working on deliverables (e.g. code, business analysis, etc.) and partly managing others working on deliverables.
|
|
|
|
|
|
For example, let's take someone whose year is "spread" among:
|
|
|
- writing business analysis and testing the software (50% of the time) = `0.5 PY`
|
|
|
- coordinating test findings with 5 software developers, who spend 30% of their time on that = `5 x 0.3 = 1.5 PY` *(coordinating does not mean solely *“sending e-mail and creating tickets”* but proactively taking care that things are done)*.
|
|
|
- leading a small product taking 30% of their time and one full-time developer = `0.3 + 1 PY`
|
|
|
- total = `3.3 PY`
|
|
|
|
|
|
*Note that such elaborate calculation is not executed in practice,
|
|
|
but the responsibly area is rather estimated approximately.
|
|
|
Also note that the above might change a bit once teams are fully operational
|
|
|
as some part of the responsibility should be spread amongst the team in a wider aspect.*
|
|
|
|
|
|
**Q: What does "own" mean in the context of scope evaluation?**
|
|
|
|
|
|
A: “Owns” means that one accepts the responsibility for the work and handles it responsibly.
|
|
|
Results of such “owning” are of appropriate quality, tested and achieved on the employee's own initiative.
|
|
|
|
|
|
**Q: How are person-years counted when evaluating scope?**
|
|
|
|
|
|
A: One's own workload typically amounts to 1 PY, with exceptional deviations of up to 0.5 PY when a person works more or less than full-time or carries extraordinary responsibilities.
|
|
|
Additional responsibility area represents how many people's work one is responsible for ("owns") within a year on average.
|
|
|
|
|
|
**Q: Does one need to be a PO or have other 'formal' responsibility to get additional scope?**
|
|
|
|
|
|
A: Not necessarily - responsibility can sometimes be assigned to scope even when the ownership of a product or product area is informal;
|
|
|
conversely, the formal PO is not automatically assigned all the person-years on the product
|
|
|
(e.g. when they lacked initiative or didn't actively handle the work of others).
|
|
|
However, having a clear record of which employee is responsible for which part of the work does make the scope evaluation easier and more objective,
|
|
|
and official PO roles usually make up a large part of one's scope evaluation.
|
|
|
|
|
|
**Q: Are the evaluations using estimated or actual effort of a product/project?**
|
|
|
|
|
|
A: The evaluations try to approximate the actual effort on a product/project,
|
|
|
|
|
|
**Q: How is scope evaluated when a person owns a part of the system that would normally require the work of several persons, but due to other circumstances they work on that part alone.**
|
|
|
|
|
|
A: The evaluation may take such extra workload into account, but usually this amount will not exceed 0.5 PY. Responsibly owning the work also means dealing with any scoping, scheduling and organizational difficulties that arise and that make it difficult to complete the work. In exceptional situations, management can review and adjust an individual scope evaluation after taking a closer look at the circumstances of each separate case.
|
|
|
|
|
|
**Q: Is there a cap on cumulative responsibility area of a team?**
|
|
|
|
|
|
A: No. In a simplified setup with only one level of owning others' work, the total responsibility area would be capped at 2x the number of team members. However, responsibility often spans more than one level (e.g. PO is responsible for an employee who has a mentee) and ownership often crosses team boundaries. Scope can also be awarded for coordinating project partners or clients, or for owning large system operational responsibility.
|
|
|
|
|
|
# Work Experience
|
|
|
|
|
|
Definition:
|
|
|
Years of full-time production experience in software development
|
|
|
or administering IT systems.
|
|
|
|
|
|
This includes things like:
|
|
|
|
|
|
* software development / programming
|
|
|
|
|
|
* software or business requirements analysis
|
|
|
|
|
|
* user interface design
|
|
|
|
|
|
* managing software teams
|
|
|
|
|
|
* software testing
|
|
|
|
|
|
* marketing software
|
|
|
|
|
|
* selling software
|
|
|
|
|
|
* system administration
|
|
|
|
|
|
It does not include technical positions that are not software development.
|
|
|
|
|
|
Involvement in software development during studies
|
|
|
is weighted according to the time spent in production products.
|
|
|
|
|
|
Low level / highly repetitive tasks
|
|
|
(rote tech support, manual black box testing)
|
|
|
are collapsed into one year.
|
|
|
(You don't have three years of experience,
|
|
|
you have the same year experience three times over).
|
|
|
|
|
|
# Promotion
|
|
|
|
|
|
Promotion is based on merit.
|
|
|
We expect an employee to perform on the next level,
|
|
|
while not exhibiting many anti-patterns (from the next and all previous levels),
|
|
|
for a sustained period of time (at least six months)
|
|
|
before they can get promoted.
|
|
|
Employees should pro-actively take, ask for, or create
|
|
|
opportunities to work at the next level.
|
|
|
|
|
|
----
|
|
|
|
|
|
# Document History
|
|
|
|
|
|
|
|
|
| Date | Author | Change Description |
|
|
|
|------|--------|--------------------|
|
|
|
|2021-05-13| mkadunc | - revised section 'Notes on Scope' based on #17 <br/> - revised text about details for skills level 4 (tcerovski's note on #16) |
|
|
|
|2021-04-30| mkadunc & tcerovski | - added general description of levels (#16 & 1st bullet of #6)<br/>- changed 'review across teams' clause of scope levels 5 and 6 (#8)|
|
|
|
|2021-01-14| mkadunc | issue #7: responsibility area defined more clearly for scopes 4 and 5 | |
|
|
\ No newline at end of file |