Two engineers sit in the same sprint review. One joined in April on a counter-offer pay, the other has been the quiet owner of the billing module for three years. The newer one earns more. Everyone in the team knows, because the offer letter leaked through a WhatsApp group. The manager asks HR for a pay structure that does not look arbitrary. That is the job of grades.
Below is a workable grade ladder for a software house with thirty to two hundred people, and a calm way to run increments. It applies across the software development companies segment, whether you build custom projects, mobile apps or enterprise platforms. Market numbers should come from your own research; the compensation benchmarking service explains how that is usually done.
Design the ladder by scope of work, not years of service
Tenure says little about what an engineer can own. A person with six years on a maintenance-only WordPress estate and a person with two years running a payments microservice are not alike. Define grades by scope: what the person can design alone, who they can unblock, how far a mistake of theirs travels. A common shape has an individual track and a lead track that split after the middle grades.
G1 Associate engineer: finishes scoped tickets with review on every pull request
G2 Software engineer: owns a feature end to end, writes tests, supports releases
G3 Senior engineer: designs a module, reviews others' pull requests, joins the on-call rota
G4 Tech lead or staff engineer: owns a service or a client delivery, sets patterns, mentors G1 to G3
G5 Principal or engineering manager: shapes platform direction or runs two teams
Parallel roles: QA engineer, DevOps or SRE, business analyst, UI designer, each with their own G1 to G4 descriptionsWrite a paragraph for each grade, then pay bands
A grade without a paragraph invites arguments. For each level write what the person does on an ordinary release, what they decide alone, and one example of a typical task. Only after that attach a band: a minimum, a middle and a maximum. The middle is where a fully proficient person should sit within two or three years in that grade.
What the grade paragraph should mention
Engineering quality hides in small, specific habits. A G2 engineer opens a pull request with a description, a rollback note and a screenshot of the staging run. A G3 engineer asks about feature flags before a Friday deployment window, keeps the runbook current and answers the pager without drama. A G4 tech lead untangles a flaky regression suite, grooms the backlog with the product owner and says no to a hotfix that skips code review. Quote such behaviours in the grade text. They are visible in Jira, in Git history and in post-incident notes, so ratings rest on evidence rather than mood.
Beware of inversion and compression
- Inversion: a new hire joins above a teammate in the same grade. Check this with a simple sheet before each offer.
- Compression: the gap between G2 and G3 shrinks until promotion brings no visible change.
- Skill premiums for scarce areas such as cloud security or mobile performance work: handle them as a separate allowance with a review date, not by inflating the grade.
- Counter-offers: decide a rule in advance. Doing it ad hoc teaches the whole team that resignation is the way to a raise.
Run the increment cycle as a calendar
- 1
Four weeks out: data
Pull grade, band position, last increment, performance rating and the manager's note for every engineer into one sheet.
- 2
Three weeks out: calibration
Managers meet to compare ratings across teams. A QA engineer rated high should be set beside a developer rated high, not against them.
- 3
Two weeks out: budget and bands
Fix the total increment pool, then the range of increments per rating and per band position. Those below the band midpoint get a bigger slice.
- 4
One week out: letters
Managers hold a short conversation before the letter arrives. No one learns their number from payroll.
- 5
After: review
Check inversion again, record promotions separately from increments and note who left within three months.
Promotions are not increments
Treat a promotion as a decision about scope. A panel of the lead, the manager and one peer from another team reviews evidence: design documents, release notes, mentoring examples. Decide at fixed windows, say after the April and October reviews, so that the whole team can see a rhythm. See how this runs in the custom software performance process and the mobile app benchmarking page.
To draft a first grade sheet together, describe your teams on the requirements wizard.
