Limited-time introductory pricing — save up to 50%. Start free →
PointFactors
Sign in

Job Evaluation for Tech Companies: How to Score Engineering, Product, and GTM Roles

Date Published

Point-factor degree levels with geometric point values (25, 50, 100, 200) compared with linear points

Job Evaluation for Tech Companies: How to Score Engineering, Product, and GTM Roles

Tech companies grow fast, and their pay structures usually grow in a hurry too. A founder promises a senior engineer a "Staff" title to close a hire. A sales team invents "Principal AE" to keep a rainmaker. Two years later you have 14 engineering titles, three levels that mean the same thing, and no way to explain why a Staff Engineer in one team earns more than a Director in another.

Point-factor job evaluation gives you a way out. It scores the work itself, not the title, the team, or the person's negotiating skill. This guide shows how to adapt the method for engineering, product, design, data, and go-to-market roles, where scope and impact matter more than headcount and tenure.

TL;DR

  • Score the job's requirements, not the incumbent's résumé or the title on the offer letter.
  • Replace "number of direct reports" with scope and impact factors so individual contributors (ICs) can score as high as managers.
  • Keep one factor set for every function, then use job families to price each one against its own market.
  • Define degrees with observable outcomes, such as the size of the system or customer base a role owns.
  • Use points to set internal relationships, then use market data to set pay. Never let hot-market pay rewrite your scores.

Why classic factor sets struggle in tech

Traditional factor systems were built for hierarchical organizations. They reward supervision, budget size, and reporting lines. In a tech company, a Principal Engineer may manage nobody and still shape the architecture of a product used by millions. If your plan gives heavy points for "supervision of others," that engineer lands several grades below an engineering manager with five reports. That result feels wrong, and it drives your best ICs to chase management jobs they do not want.

The opposite problem shows up too. Without clear factor definitions, "Senior," "Staff," and "Principal" turn into prestige labels. Each team lead defines them differently, and pay drifts apart. Our guide on dual career ladders explains why you need an IC track that pays on par with management. Job evaluation is what makes that parity measurable.

Build a factor set that fits tech work

You do not need a custom method. Keep the classic categories and tune the sub-factors. A workable structure looks like this:

Factor

Sub-factors

What it measures

Skill

Technical depth, breadth across domains, problem complexity

What the job requires to perform well

Responsibility

Scope of ownership, business impact, decision authority

The size of what the role owns and the cost of a bad call

Influence

Cross-team leadership, technical direction, external reach

How far the role shapes work beyond its own tasks

Effort and conditions

Pace and pressure, on-call and incident duty

Demands that are part of the job design

A note on skill. The U.S. Department of Labor's Equal Pay Act regulation says skill is measured by the performance requirements of the job. It adds that possession of a skill the job does not need cannot be considered. That is a useful discipline in tech, where people often hold deep skills outside their current role. If a data analyst is also a strong back-end developer but the job does not call for it, the extra skill does not raise the job's score. It may justify a move to a different job.

Our overview of compensable factors covers how to choose and define factors for any organization. For tech, the key move is to let scope and influence carry points that used to belong to supervision.

Write degrees around outcomes, not adjectives

Degree definitions do the real work. Avoid words like "complex" or "senior." Describe what the role owns and what happens if it fails. Here are example scales you can adapt.

Scope of ownership, example scale:

  • Degree 1: Completes assigned tasks within a defined project; work is reviewed by others.
  • Degree 2: Owns a feature or component end to end; sets own priorities within a team plan.
  • Degree 3: Owns a service, product area, or customer segment; decisions affect several teams.
  • Degree 4: Owns a platform, product line, or region; decisions affect the company's roadmap or revenue plan.
  • Degree 5: Owns a company-wide system or function; decisions set direction for multiple organizations.

Business impact, example scale:

  • Degree 1: Errors are caught in review and have little customer effect.
  • Degree 2: Errors cause rework or minor customer friction.
  • Degree 3: Errors cause visible outages, churn risk, or missed team targets.
  • Degree 4: Errors cause material revenue loss, security exposure, or contractual penalties.

Notice that neither scale mentions headcount. A Staff Engineer who owns the payments platform and a Director who runs three product teams can both score at Degree 4 on scope. Write your scales so raters cite evidence from the job description, not impressions. For more help, see factor degree definitions.

Set weights that reflect how you create value

Weights express what you pay for. A software company might emphasize skill and impact, while a services-heavy company might emphasize responsibility. Here is a starting point for a 1,000-point system:

Factor

Weight

Points

Skill

30%

300

Responsibility

35%

350

Influence

25%

250

Effort and conditions

10%

100

Test the weights on a handful of jobs you understand well. If the results contradict a clear internal view, adjust the weights before you adjust any scores. Our post on how to weight compensable factors walks through the process.

A worked example across functions

Here are five jobs scored on the weights above. The points are illustrative.

Job

Skill (300)

Responsibility (350)

Influence (250)

Effort and conditions (100)

Total

Software Engineer II

150

120

60

30

360

Staff Engineer

240

230

170

40

680

Engineering Manager

210

240

150

40

640

Senior Account Executive

140

190

100

50

480

Director of Product

230

280

190

40

740

Look at the Staff Engineer and the Engineering Manager. They land within 40 points of each other, which supports a shared pay grade or adjacent grades. That is the point of the exercise. The model rewards the Staff Engineer for skill and influence, and the manager for team-level responsibility, without forcing the engineer into management to earn more.

Now suppose a hiring manager says, "We need to pay this Staff Engineer like a Director because the market is hot." The framework gives you a clear response. The job scores 680, so its grade stays put. Handle the market premium with a documented market adjustment, not by inflating the score. That keeps your structure honest and your equity analysis clean.

Score the job, then price it by family

Points tell you how jobs relate to each other inside your company. They do not tell you what the market pays. A Staff Engineer and a Senior Account Executive may sit in similar grades, yet the markets for those jobs differ sharply, and sales roles often carry variable pay on top of base.

Group jobs into job families such as Engineering, Product, Design, Data, Sales, and Customer Success. Use points to set grade relationships, then price each family against its own survey data. Our guide on market pricing versus job evaluation explains how to use both together.

Many tech employers also benchmark levels against published leveling frameworks. Aon's Radford describes global job leveling as building on job architecture, with a management track and an individual contributor track placed in the same grade when market pay suggests equivalence. Treat frameworks like that as a reference for your own level definitions, then validate them with your own factor scoring.

Want to see your engineering and GTM roles scored side by side? Run a PointFactors demo with ten of your own jobs and compare the results to your current levels.

Common mistakes in tech job evaluation

  • Scoring the person. A brilliant engineer does not raise the grade of the job. If the job needs to change, update the description and re-score.
  • Using titles as inputs. "Senior" and "Principal" mean different things on different teams. Score duties and scope.
  • Counting team size as the only form of scope. This pushes ICs below managers by default.
  • Double counting. If a platform outage risk earns points under responsibility, do not award the same risk again under influence.
  • Letting equity and bonus drive the grade. Total compensation mix is policy. Points describe the work.
  • Skipping calibration. Engineering leaders and sales leaders rate jobs differently. Hold a session so raters apply degrees consistently. See job evaluation calibration.

A rollout plan for a fast-growing company

  1. Pick a project team with HR, finance, and one leader each from engineering, product, and GTM.
  2. Select 15 to 25 benchmark jobs across functions and levels.
  3. Rewrite those job descriptions around scope, impact, and decisions, not tasks and tools.
  4. Define degree scales and test them on three or four jobs you know well.
  5. Score all benchmarks, then calibrate as a group.
  6. Slot the remaining jobs against the benchmarks using job slotting.
  7. Convert points to grades, add market data by family, and review budget impact before you announce anything.

If your company is still small, start with a lighter version. See job evaluation for small companies for a streamlined approach, and our comparison of job evaluation versus job leveling if you already have levels and want to test them.

Frequently asked questions

Do tech companies need job evaluation if they already have job levels?

Levels describe progression. Job evaluation tests whether those levels are consistent and defensible. If two jobs share a level but score 150 points apart, your levels are hiding a pay problem.

How should we treat IC and management tracks?

Score both tracks with the same factors. Parity in points supports parity in pay at the same grade, which is the whole point of a dual ladder.

Should equity count as a factor?

No. Equity is part of the reward package, not a description of the work. Set equity guidelines by grade after you score and grade the jobs.

How do we handle new roles like AI engineer or prompt designer?

Score the job as designed today. Describe the scope, decisions, and impact in the description, then place it in the grade its points support. Revisit when duties change. Our guide to job re-evaluation covers timing.

How many compensable factors do we need?

Most tech companies do well with three to five main factors and a handful of sub-factors. More detail rarely improves accuracy and often slows raters down.

Can we use the same plan for sales and engineering?

Yes. One factor set keeps the structure consistent. Use family-specific market data and pay mix to reflect how each function is paid.

Build a structure your engineers will trust

If your titles have outrun your pay structure, start with a small scoring pass on real jobs. Start free with PointFactors and we will score a sample of your roles with you. You can also review pricing or see how job evaluations work in the platform.

By Justin Hampton, founder and CEO of PointFactors.

Join the PointFactors newsletter

One email a month on job evaluation, pay equity and pay transparency. No spam; unsubscribe anytime.

Work email required. By joining you agree to receive our monthly newsletter; see our Privacy Policy.