Salary Benchmarking & Pay Bands: India SMB Guide

Why salary benchmarking and pay bands stop being optional at 30 people

Most Indian startups pay by negotiation until the day it breaks. Salary benchmarking and pay bands feel like big-company machinery when you're twelve people and every offer is a conversation between the founder and the candidate. Then you cross fifty heads, someone forwards a screenshot, and you discover two backend engineers doing indistinguishable work are 42% apart on fixed pay — not because one is better, but because one joined during a funding round and negotiated harder.

This is written for that moment and the eighteen months after it: philosophy, job architecture, market data in India, band construction, compa-ratio maths, the increment cycle, and how to phase toward pay transparency.

Every rupee figure below is an ILLUSTRATIVE EXAMPLE to demonstrate arithmetic. None of it is market data. Copy the method, not the numbers.

Symptoms that you need bands now

• Offer approval takes three days and two escalations. Nobody knows what "right" looks like, so only the founder can decide.
• Counter-offers work. A 35% raise on resignation tells everyone that a resignation letter is your fastest compensation review process.
• Complaints shift from "I want more" to "why does she make more than me?" That's an internal-equity problem, and it's the dangerous kind.
• New joiners out-earn tenured performers in the same role. Market moved 20% in eighteen months; your increments moved 9%. This is the most common cause of regretted attrition in growing Indian SMBs.
• You can't answer "what does 40 hires next year cost?" in ten minutes.
• Managers make promises. "I'll get you to 25 lakhs next cycle" — no authority, no budget, remembered perfectly.
• Title inflation. Five "Senior Managers" doing wildly different jobs, because a title was the cheapest thing you had to give.

Three or more of these and the cost of not having bands already exceeds the cost of building them. A first version is four to six focused weeks for one competent person, not a year-long programme.

Compensation philosophy: decide this before the spreadsheet

A compensation philosophy is one or two written pages that answer questions you'd otherwise answer inconsistently forty times a year under pressure.

Which market are you competing in? Not "India." Most companies need two or three peer sets: product/engineering roles compete with funded product companies at similar stage and city; go-to-market roles with sector competitors; G&A roles against a much broader market including non-tech mid-market employers. One peer set for the whole company is the most common mistake and it reliably overpays G&A while underpaying engineering.

Lead, match, or lag?

Mixing is fine: "We match the market on fixed pay generally, lead for senior engineering and data, and lag slightly on entry-level G&A." What you may not do is leave it unstated — then every hiring manager assumes lead and every finance person assumes lag.

Also state: the total rewards mix (if you lag on cash and lead on equity, say so, so recruiters pitch it consistently); whether position-in-band is driven by capability or tenure; and how much a manager can move within band before needing approval. The workable default is position in band reflects sustained capability and scope; annual increase percentage reflects recent performance.

Ship it as a signed, dated document. When someone challenges an offer in nine months you want to point at a decision, not re-litigate one.

Job architecture and levelling come before pricing

You cannot price a job you haven't defined. If you have sixty unique titles for seventy people — "Growth Ninja," "Lead Engineer II" — you don't have an architecture, you have accumulated history. Benchmarking that produces sixty fragile data points instead of a system.

Job families group work type (Engineering, Product, Sales, Finance, People…). Keep to 8–12. Job levels describe scope, autonomy and impact independent of function. Job profiles are the intersection — "Engineering / P3 / Backend" — and that's your benchmarking unit.

An illustrative level framework

ILLUSTRATIVE. Adapt the number of levels to your actual size.

Three rules that save pain:

1. Levels are scope, not years. Treat the experience column as a signal or you'll end up debating birthdays.
2. Keep a parallel IC track to at least P5. If management is the only way up, you'll promote your best engineers into jobs they don't want and lose them.
3. Write one paragraph per level per track — not a 40-row competency matrix. A paragraph a manager can read aloud and an employee will recognise as true.

Levelling existing people

Do it with the comp owner and function heads, one function at a time. Place three to five obvious anchors per function, then level everyone else relative to those anchors — deliberately blind to current salary. Level people by their pay and you'll re-encode your existing inequities into a framework and call it rigour. Expect 10–20% contentious cases; park them, finish the easy 80%, return. Where someone is levelled above their real scope, note it and let the next promotion cycle handle it — don't demote in launch week.

Job matching: price the work, not the title

Benchmark by matching job content, not names. Titles in Indian startups are noise: "Product Manager" spans someone writing tickets from a founder's spec and someone owning a P&L line.

1. Write a 3–4 line benchmark summary per profile: primary outputs, decision scope, who they influence.
2. Find the market benchmark job whose content is closest.
3. Record a match quality flag — Good, Approximate, or Weak.
4. Where Approximate, adjust deliberately and write the logic down ("matched to Senior Backend Engineer but our scope is narrower, so we price to the lower part of that range").
5. Where Weak, triangulate across two or three sources rather than trusting one number.

Hybrid roles are hardest. A "Founder's Office" person doing BD, analytics and ops has no match. Either price to the dominant component (>50% of time) or to the level, using the median of the two closest families. Document which you chose.

Where to get market data in India — and how each source misleads you

There is no single trustworthy source. Knowing the direction of each source's bias matters more than its number.

Combining sources without fooling yourself. Anchor on the most structured source you can afford, then adjust with live intel — not the reverse, or you'll cherry-pick. Age your data with one consistent, documented assumption across all roles rather than ageing hot roles more because it feels right. Weight by match quality: a Good match from a mediocre source usually beats a Weak match from an excellent one. Record source, benchmark job, match flag, raw figures, adjustments and resulting midpoint for every profile — when someone asks "where did 32 lakhs come from?" eight months later, "we discussed it" isn't an answer.

The percentile trap. Percentiles describe a specific dataset, not "the market" — the 75th percentile of forty companies in one city is not the 75th percentile of India. And don't chase percentiles across cycles: if everyone targets the upper quartile, the upper quartile moves every year and you've built an escalator into your cost base.

Building the band: midpoint, spread, overlap

A pay band is four numbers — minimum, midpoint, maximum, and the width between them. Everything else is commentary.

Set the midpoint to what you intend to pay a fully proficient person performing well, positioned per your philosophy. Common error: setting midpoint at the market middle then paying almost everyone below it because they're "still developing." If your average sits at 0.85 compa-ratio, your effective posture is lag no matter what the document says.

Choose the spread — the min-to-max distance as a percentage of the minimum. Narrower at junior levels, wider at senior, because performance variance and time-in-level both grow with seniority.

Set midpoint progression between levels — the jump that decides whether promotions feel real. Under ~12% and promotions feel hollow; over ~50% at mid-levels and every promotion is a budget crisis, so managers stop promoting. Practical range: 15–25% at junior/mid, 25–40% at senior.

Accept overlap. A strong P3 near band max can legitimately out-earn a newly promoted P4 — that's correct, and it means promotion isn't the only route to a raise. Target roughly 30–50% overlap between adjacent bands. Zero overlap makes every promotion expensive; over ~60% means your levels aren't really distinct.

An illustrative band table

ILLUSTRATIVE EXAMPLE ONLY — not market figures. Annual fixed pay, INR lakhs, single location.

Note the P4 minimum deliberately sits below the P3 maximum. Set P4's floor above P3's ceiling and you get a discontinuous ladder where a top-of-band P3 must be promoted to get any increase at all. Plot your bands before publishing them — this kind of flaw is invisible in a table and obvious in a chart.

Decide what the band covers. The common Indian convention: bands are annual fixed pay, with target variable and equity stated separately by level. Rolling everything into one "total CTC band" makes benchmarking harder because variable structures differ so much between employers, and it inflates the number relative to cash the employee actually banks.

CTC, fixed and variable: getting the denominator right

"CTC" is a uniquely Indian construct and is not standardised. Two companies quoting "18 LPA" can differ by two lakhs in what reaches the employee, depending on what's stuffed in: employer PF, gratuity provision, insurance premiums, meal allowances, an amortised joining bonus, or the maximum rather than target variable.

Three rules: benchmark on fixed pay wherever possible; define your terms in writing and use them identically in offer letters, band tables, budget models and your HRMS; and when you receive external data, ask what's included — a recruiter saying "she's at 28" may mean fixed, may mean loaded CTC, may include a variable that never fully paid out.

Never use joining or retention bonuses to solve structural band problems. They defer the issue twelve months and it returns larger.

Location differentials: metro, tier-2, remote-first

India is not one labour market, but differentials are narrowing for remote-capable roles. Three viable approaches:

Single national band. Radically simple, a big advantage when hiring outside metros, no painful relocation conversations, easy to make transparent. Costs more per head. Best for remote-first companies and roles where talent is nationally scarce.

Location tiers with a multiplier.

ILLUSTRATIVE. Derive your own, and note multipliers vary by function — differentials for scarce senior tech roles are usually much smaller than for entry-level operations, because the senior market is national while the entry market is genuinely local.

Hybrid, which is where most pragmatic Indian SMBs land: single national bands for engineering, product, design and senior roles; location tiers for support, field sales, operations and entry-level roles whose markets really are local.

Whichever you choose: decide the relocation policy before someone relocates. The two clean options are "pay follows location, adjusted at the next cycle with notice" and "pay doesn't change on relocation." Both are defensible; "case by case" is not. Don't cut pay when someone moves to a cheaper city unless the policy said so in advance — the reputational damage exceeds the saving. And if you're remote-first, say which location your bands are anchored to; "Tier A rates applied nationally" is a hiring advantage worth advertising.

Mapping people in: green-circle and red-circle cases

Place every employee using their assigned level and current fixed pay. You'll find three groups.

In-band (most people). Fine. Position in band becomes an input to the next cycle.

Below minimum — green-circled. Underpaid against your own structure. Usually long-tenured people whose pay grew 8% a year while the market ran faster, or people hired junior who grew into a bigger job without a correction.

1. Count and cost them first. That rupee number is your credibility budget with the founder and CFO.
2. Fix in one move if affordable — it's the highest-ROI money you'll spend, because these people are your flight risk and your fairness liability.
3. If not affordable, phase over two or three cycles with a written plan, and tell the person: "Your pay is below the band for your level; here's the plan to close it by [date]." A disclosed phased plan beats a silent one every time.
4. Never phase beyond three cycles. If it takes longer, either the band is wrong or the business can't afford the structure you designed.

Above maximum — red-circled. First check the level, not the pay: often the person is doing bigger work than their level says, and the fix is a levelling correction. If they're genuinely over-banded, do not cut pay — that's a fast route to losing them and to a team that watched it happen. Freeze or slow base increases instead, optionally paying recognition as a one-time lump sum so they're rewarded without pushing base further out of range. Communicate it plainly and privately. Then track them: bands move up each year, and many red-circle cases resolve themselves within two cycles.

More than about 15% green-circled and either your bands are set too high for your business or you have a real, expensive under-payment problem. Find out which before publishing anything.

Compa-ratio and range penetration, with a worked example

Compa-ratio = fixed pay ÷ band midpoint. It answers: how does this person compare to what we intend to pay a fully proficient performer?

Two aggregate uses matter more than the individual number. Average compa-ratio by function: if Engineering sits at 1.06 and Customer Success at 0.88, you have a systemic problem no individual conversation will fix. Compa-ratio by demographic cut within level and function is the most practical pay-equity diagnostic available to an SMB, because it controls for level and role in a way that raw average-pay comparisons don't.

Range penetration = (pay − min) ÷ (max − min) × 100. More intuitive than compa-ratio when bands have different widths: 0 is the floor, 100 the ceiling, regardless of spread.

Worked example — ILLUSTRATIVE

Using the P3 band above: min 15.0, midpoint 18.4, max 21.8 (INR lakhs, annual fixed).

Priya — 16.2. Compa-ratio 16.2 ÷ 18.4 = 0.88. Range penetration (16.2 − 15.0) ÷ 6.8 × 100 = 17.6%. Promoted into P3 eight months ago and performing well; low in band is correct for now. Give an above-average increase to move her toward midpoint over two cycles.

Rohit — 20.9. Compa-ratio 1.14; range penetration 86.8%. Four years at P3, consistently strong. He's near the ceiling of what this level is worth to the business — a 12% increase pushes him past max. The honest conversation is about P4 readiness, not a bigger raise. If he isn't ready, the right answer is a modest increase plus a clear development plan, said plainly rather than discovered through three years of shrinking increments.

Anjali — 14.1. Compa-ratio 0.77; range penetration −13.2%, below minimum. She joined four years ago as a P2, grew into a P3 job, and took standard 9% increments while P3 market rates ran ahead. Gap to minimum: 0.9 lakhs — the cheapest retention money in the company.

Increase % needed to reach midpoint = (midpoint ÷ current pay − 1) × 100. For Anjali: (18.4 ÷ 14.1 − 1) × 100 = 30.5%. That is not a merit increase, it's a structural correction, and it should be budgeted and labelled as one. Hiding a 30% correction inside a merit cycle destroys the credibility of the merit cycle for everyone else.

Budgeting the increment cycle and the merit matrix

Split the budget into buckets. Never run one undifferentiated pot — these four have different logic and different approvers.

Year one of a banding exercise usually needs 2–3% for structural correction because you're paying for years of drift at once. Tell the CFO up front and frame it as one-time.

Build a merit matrix using two inputs — performance rating and position in band. Someone performing well but paid low in band should move faster than an equal performer already near the top.

Illustrative matrix sized to a ~7.5% average budget:

ILLUSTRATIVE ONLY. Build yours from your budget and rating distribution, then check the arithmetic: multiply each cell by expected headcount and confirm the weighted average lands on budget. Most first drafts overspend by 1.5–2 points because everyone quietly assumes their team is above average.

Give managers a total pot rather than a set of cells — the matrix is guidance, the pot is the constraint. Cap outliers ("any increase above 20% needs comp-owner approval"). Model the cost against your actual population before release; it takes an hour and prevents a mid-cycle crisis.

Handle promotions separately. Move the person at least to the new band minimum and target roughly the 25th–40th percentile of the new range — typically 12–25%. Decide the level first and price it second; decide money first and you'll promote to justify a raise, which is how title inflation starts. If someone was already high in their old band the increase will look small in percentage terms, so explain it as position in the new band.

Distinguish market corrections from merit. Conflating them causes two failures: employees read a market correction as a performance reward and expect it annually, and in a year you can't fund corrections they read a small merit increase as a performance verdict. A two-line breakdown on the letter — "merit 7%, market adjustment 5%, total 12%" — transforms the conversation.

Communicating bands: managers first, always

The usual rollout failure isn't the maths. It's announcing the framework company-wide on a Tuesday that managers also find out about on Tuesday. They get asked questions they can't answer, they improvise, and the improvisation becomes policy.

Phase 0 — founders and function heads, weeks ahead: sign off philosophy, levels, correction cost, and what gets published. Surface disagreement here.

Phase 1 — managers, two to four weeks before employees. A working session, not a deck. Each manager should leave able to explain what a level is and why their reports sit where they do, explain that band max isn't a punishment, interpret a compa-ratio, say "I don't set the band, and here's how it was built," and handle the three hard questions: Am I underpaid? Why is my increase smaller than last year? When do I get to the next level? Give them a written FAQ and a one-page script, and role-play two conversations.

Phase 2 — employees: the framework, the philosophy, level definitions, and how increases are decided.

Phase 3 — individual conversations: each person's level, and their position relative to band if you're at that transparency stage.

Language that works: "Everyone at this level in this function is paid within the same range; where you sit reflects scope and sustained performance." Language that backfires: "Trust us, you're paid fairly" (unverifiable claims invite the suspicion you're trying to remove), "we can't discuss compensation" (employees discuss it anyway — you're only opting out; and restricting employees from discussing their own pay is legally fraught in many jurisdictions, so check your position with counsel), and "the market says so" (which market, whose data — it sounds like a dodge because it usually is).

Pay transparency: what to publish and how to phase it

Transparency isn't binary. It's a ladder, and most Indian SMBs should climb it deliberately.

Target Stage 3 within a year and Stage 4 within two; treat 5 and 6 as strategic choices, not inevitable destinations.

Four sequencing rules. Fix before you publish — transparency doesn't create fairness problems, it reveals them, and revealing without a fix is worse than silence. Publish structure before numbers, so people have the vocabulary. One step per cycle, letting each settle. Never go backwards; retracting transparency reads as concealment.

Be honest with leadership about the trade. It helps by cutting the information asymmetry that lets aggressive negotiators outpace quiet high performers, giving managers a defensible position, reducing the "is there a secret better deal?" anxiety that sends people to interviews, making pay gaps visible and therefore fixable, and speeding up hiring. It costs you the ability to quietly overpay for one hire, surfaces every levelling inconsistency at once, compresses negotiating room, and demands genuinely more rigorous maintenance — you can't publish bands and then stop updating them.

On equity obligations: India has long-standing legal requirements around equal remuneration for the same or similar work regardless of gender, and pay-equity expectations continue to develop under evolving labour legislation. Treat this as a real compliance area and verify the current applicable requirements with qualified counsel for your establishment type, state and headcount, since obligations and their commencement have changed over time. Operationally the discipline is the same either way: compare average compa-ratio within level and function across groups, investigate gaps for legitimate explanations (tenure in level, sustained performance, scope), and correct what isn't explained. Run it before you publish, and consider doing it under legal privilege where a material correction is possible.

Governance and refresh cadence

Bands rot. A structure built on good data is wrong within twelve to eighteen months in a moving market — and a wrong band is worse than no band, because it carries authority.

Ownership at SMB scale: the comp owner builds and maintains bands, runs the refresh, approves exceptions and runs the equity analysis; function heads own levelling within their function and allocate merit within their pot; finance owns the budget envelope; the founder approves the philosophy, the annual envelope and executive pay. A small comp committee reviewing exceptions monthly prevents both failure modes — nobody approving exceptions, and everybody approving them.

You will make exceptions; the goal is visible and finite, not zero. Log who, what fell outside policy, why, who approved, and the plan to bring it back in range. When one role or manager appears repeatedly, the band is wrong — not the manager. A useful benchmark: under 5% of offers should need an exception. Above 10%, your bands don't reflect the market you're hiring in.

Common mistakes

• Building bands from your current salaries. Averaging what you pay today enshrines your existing distortions. Build from external data, then compare to internal reality.
• Too many levels. Twelve levels across eighty people means six people per level and meaningless promotions. Start with five or six.
• Confusing levels with titles. Levels are internal architecture; titles can be more generous externally. Keep them linked but distinct, and never let a title negotiation move a level.
• Treating bands as a hiring ceiling. If you consistently can't hire at the band, the band is wrong. Fix it rather than granting twenty exceptions and pretending the structure holds.
• Ignoring compression. New hires enter at current market rates; existing people move at your increment percentage. Compare the compa-ratio of people hired in the last twelve months against those with three-plus years at the same level. If new joiners are systematically higher, budget a correction.
• Letting managers negotiate levels. "Can we make him a P5 so we can pay him more?" is how the framework dies. Route it through the exception process: pay at the top of P4 with a documented exception and revisit the level in six months against actual scope.
• Leaving it in a spreadsheet. A structure living in one person's file, disconnected from payroll, isn't operational — and doesn't survive that person's departure.
• Over-engineering v1. Six levels, one national band per role, three functions priced properly and a written philosophy beats a beautiful nine-level, four-geography framework that ships eight months late.

A six-week plan to v1

Roughly 40–60% of one person's time for six weeks. What isn't achievable is doing it in parallel with a live increment cycle — build before the cycle, not during it.

FAQ

How big do we need to be before salary benchmarking and pay bands are worth it?

The practical trigger is when one person can no longer hold every compensation decision in their head — usually between 25 and 50 people, earlier if you're hiring fast. Below that, a lightweight version suffices: a written philosophy, three or four levels, and rough ranges for your five most-hired roles. The full architecture can wait; the philosophy shouldn't, since writing down your market posture at fifteen people costs an afternoon and prevents years of drift.

Should bands be set on fixed pay or total CTC?

Fixed pay, almost always. CTC isn't standardised across Indian employers, so benchmarking against it compares numbers built on different definitions. Set the band on annual fixed pay and state target variable, equity and benefits separately by level. You can still quote CTC in offer letters if that's your convention — but your structure and your benchmarking should run on the clean number.

What's a healthy average compa-ratio?

Around 0.95 to 1.00 for a stable population, but the distribution matters far more than the average. A company average of 0.95 could mean a well-spread population or half your people at 0.80 and half at 1.10 — a serious equity problem hiding behind a reassuring number. Fast-growing companies with many recent hires sit naturally lower; companies with long tenure and few promotions drift higher. Read it by level and function.

How do we price a role with no good market comparator?

Three fallbacks in order. Price to the level rather than the role, using the closest family's midpoint and adjusting. Or build a composite: identify the two or three roles the job blends, weight by time spent, and blend the midpoints. Or use peer intel — ask two or three HR leads at comparable companies. Whichever you use, flag the match as Weak and re-check at the next refresh; these roles usually acquire clearer benchmarks quickly.

Do we have to publish salary ranges in job postings?

That's strategic and increasingly jurisdiction-specific — several markets outside India have introduced mandatory range disclosure, and requirements evolve, so verify what applies to your establishment and any international hiring. Commercially, publishing ranges cuts time wasted on candidates far outside your band and signals confidence in your structure; the costs are competitive visibility and anchoring to the top of the range. If you publish, publish the real band — "8 to 40 lakhs" is worse than nothing, because it broadcasts that you have no structure.

Someone is above the band maximum. Can we cut their pay?

Practically no, and you shouldn't. Cutting pay to fit a framework you just built costs you that person and damages trust with everyone watching, and there are employment-law considerations around unilateral changes to agreed terms worth checking with counsel. Red-circle instead: hold base flat or grant reduced increases, optionally paying recognition as a one-time lump sum, until the band rises to meet them or their scope grows into the next level. First, though, re-examine the level — a surprising share of red-circle cases are levelling errors, not pay errors.

How often should bands be refreshed, and by how much?

Annually, ahead of the increment cycle, with quarterly spot-checks on roles you hire heavily or where you're losing offers. The size of the move should come from your data, not a rule of thumb, and it will vary by function — scarce technical roles typically move faster than G&A. Resist moving every band by the same percentage for administrative convenience; that's how you structurally overpay some functions and lose candidates in others. And remember that moving bands isn't the same as giving increases: band movement changes where people sit, the increment budget decides who moves with it.

How do we roll bands out without triggering a wave of complaints?

Sequence it and fund the fixes. Complaints spike when people learn a structure exists, find they're below it, and hear no plan. So: build the bands, cost the green-circle corrections, get budget for at least a phased fix, train managers, then communicate — in that order. Lead with process transparency before number transparency. Give every manager a script and a written FAQ. And be honest about what the framework can't do: it won't make everyone happy with their pay, it will make the basis for their pay legible. Smaller promise, keepable.

Bringing it together

Salary benchmarking and pay bands are, at bottom, a way of making a promise you can keep. Not "we pay fairly" — an unfalsifiable claim nobody believes — but something narrower and far more useful: here is how we decide, here is where you sit, here is what changes it.

The sequence is boringly consistent across companies. Write the philosophy first. Build job architecture and levels before pricing anything. Level people blind to salary. Source data from more than one place and know how each is biased. Build bands with sensible midpoints, spreads that widen with seniority, and deliberate overlap. Map everyone in, count the green-circles, and cost the fix before communicating. Train managers weeks ahead. Run the cycle with separate merit, correction, promotion and market buckets. Climb the transparency ladder one rung per cycle. Refresh annually and check compression and equity every year.

Version one will be imperfect — a fuzzy level boundary, one function's band visibly wrong, three people whose levelling starts an argument. That's fine. A structure you can debate and correct beats a pile of one-off negotiations nobody can explain and everybody suspects.

The last piece is operational. Levels, bands, compa-ratios and increment history need to sit alongside employee records, or they drift out of date and contradict what's in payroll. That's what CozyHR is built for — keeping levels, salary structures, CTC composition, increment cycles and employee data in one place, so your compensation framework is something your team operates rather than something you rebuild every March. If you're starting your first banding exercise, or maintaining one across a spreadsheet, a payroll tool and a shared drive, it's worth a look before your next increment cycle begins.