Founders love clean growth stories.
Revenue is up. Headcount is up. Customers are coming in. The office feels busier. The team chart looks more “real.” From the outside, that sounds like progress. From the inside, it can hide a mess.
A company can be growing and still getting weaker. A bigger team can make a business look stronger while actually making it slower, heavier, and less efficient. That is why revenue per employee is such a brutally useful number. It asks one uncomfortable question: for every person on payroll, how much business are we actually producing?
The formula
Revenue Per Employee = Total Annual Revenue ÷ Total Full-Time Equivalent Employees
That “FTE” part matters. If your company uses part-time staff, contractors, offshore vendors, or agencies, you need a consistent rule for what counts. Otherwise, the metric becomes flattering fiction.
2
What makes this metric powerful is that it forces honesty. You cannot hide behind a great story, a polished org chart, or a busy office. If revenue is not keeping up with headcount, the number exposes it. If the team is too lean and a few people are holding the whole company together with caffeine and panic, the number can expose that too.
text
A startup is not efficient because it feels stretched. It is efficient when the team and the revenue move in proportion.
What “good” looks like by stage
This is where founders go wrong fast: they compare themselves to the wrong company. A seed-stage SaaS startup should not benchmark itself against a public software giant. And a company with a heavy services layer should not use the same target as a self-serve product-led business.
Still, benchmarks are useful if you use them as direction, not religion.
Older OpenView software benchmarks showed median ARR per full-time employee rising from about $47K below $1M ARR to $60K at $1M–$2.5M, $87K at $2.5M–$10M, $119K at $10M–$20M, $145K at $20M–$50M, and $200K above $50M. More recent 2025 data points in the same direction: Subscript puts the median below $1M ARR at about $57K, Benchmarkit puts the $5M–$20M ARR median at $144K, and says companies at $100M+ ARR reach about $300K. ICONIQ says top-quartile software companies scaling toward $20M ARR reach roughly $140K–$150K ARR per FTE. Using the April 21, 2026 USD/INR rate of about ₹93.08 per dollar, those numbers are roughly ₹53 lakh at the low end, ₹1.34 crore around the $5M–$20M stage, and ₹2.79 crore at $100M+ scale.
That last part is exactly why Indian founders need judgment here. If you convert global benchmarks directly into rupees, the targets can look shockingly high. That does not mean they are useless. It means you should treat them as efficiency direction, not as blind hiring quotas. Your business model, your pricing, your vendor mix, and how much work is done outside payroll all affect the number. Benchmarkit and Subscript both warn that contractor-heavy or vendor-heavy companies can look “lean” on paper while simply hiding labor elsewhere.
The India-specific RPE problem
Indian founders do not just face a cost problem here. They face a structural one.
Dev Khare from Lightspeed India, writing for SaaSBoomi, argues that many Indian SaaS companies run lower ARR/FTE than US peers for a few repeat reasons: too many entry-level hires, too much customer support because the product still needs hand-holding, too much professional services retained in-house, and a habit of over-hiring that becomes hard to reverse later. He also points out something uncomfortable: among the top five Indian IT firms, the highest revenue per employee was around $56K, and the average was about $48K—yet many Indian SaaS companies sit below even that, despite selling a supposedly more scalable product.
That is the real warning. Cheap hiring is not the same thing as efficient hiring. A bloated team made of lower-cost employees is still a bloated team.
And the trap gets worse because bigger teams can feel emotionally reassuring. More people make the company look serious. Specialized job titles make founders feel like they are “building the organization.” But if revenue is not rising fast enough with headcount, you are not building leverage. You are building weight.
How to tell if you have over-hired
Over-hiring rarely announces itself dramatically. It shows up as drag.
- Revenue is growing, but headcount is growing much faster.
- More and more people are in support roles that do not build, sell, or retain the product.
- New hires do not seem clearly tied to a revenue bottleneck.
- Meetings increase, but output does not.
- You keep adding managers before you have enough real work for teams to manage.
- RPE declines for multiple quarters and nobody can clearly explain why.
One of the easiest ways to spot this is to map your team into four simple buckets: Build, Sell, Support, Admin. If you are still relatively early and too much of the company sits in Admin and internal coordination, you probably hired for comfort before hiring for leverage.
Another tell is when founders begin hiring “structure” before there is enough scale to justify it. HR managers, strategy layers, operations layers, and multiple internal coordinators can all make sense later. But early on, these functions often grow faster than revenue because nobody stopped to ask the hard question: what problem is this hire solving that clearly affects revenue?
How to tell if you have under-hired
This side is less discussed, but it matters too.
A very high revenue-per-employee number is not automatically a flex. Sometimes it is proof of a great business model. Sometimes it is proof that your team is exhausted.
- The founder is still doing sales, support, hiring, and operations at the same time.
- Customer response times are slipping.
- Product releases slow down because the same people are fighting fires every day.
- High performers are quietly burning out.
- Revenue looks strong, but a few people are carrying too much of it personally.
If your number is far above benchmark, do not celebrate too quickly. First ask whether the company is truly efficient or just underbuilt. A lean team is great. A fragile team is not.
Good efficiency creates breathing room. Fake efficiency creates exhaustion.
How to fix the problem without layoffs
Founders often jump from “we hired too much” straight to layoffs. That is usually lazy management disguised as decisiveness.
There are smarter moves first.
1. Freeze hiring before you cut people
A 60- or 90-day hiring freeze forces clarity. It gives you time to see where real gaps exist and where the business can rebalance through natural attrition.
2. Redeploy people toward revenue
Some roles are not bad roles. They are just sitting in the wrong part of the company. A person doing loose support coordination may become a great onboarding specialist. Someone in a vague operations role may be better used in implementation or customer retention.
3. Kill repetitive support work at the source
If your product still needs too many humans explaining basic things, fix the product and the onboarding. Build better self-serve help, cleaner setup, and fewer support-triggering moments. That is often a better answer than hiring more support forever. Lightspeed’s critique of Indian SaaS is blunt on this point: when the product does not do enough work by itself, founders keep adding people to compensate.
4. Audit duplicate roles
Write down who owns what. You will often discover two or three people are doing slightly different versions of the same job because the company grew without clear role lines.
5. Use contractors for truly variable work
Project-based design, one-off recruiting help, seasonal content, or specific technical work does not always need full-time headcount. Just be honest in how you count it when you review efficiency.
6. Set a two-year RPE target
Do not use this number just to judge the past. Use it to shape hiring discipline. Ask before every hire: will this person help us raise revenue per employee over the next 6–12 months, protect it, or are we adding weight?
The one rule founders should use before the next hire
Before you approve the next person, ask one very simple question:
Will this hire help us generate revenue, protect revenue, or build the product that generates revenue?
If the answer is yes, the role deserves serious consideration.
If the answer is fuzzy—if it is about “helping us get organized,” “freeing up some bandwidth,” or “professionalizing the company” in a vague way—you may be hiring overhead before your revenue can carry it.
That does not mean overhead roles are bad. It means they should arrive later than founders usually want them to.
Your RPE diagnostic this week
Take the last 12 months of revenue. Divide it by your real FTE count. Then map every employee into Build, Sell, Support, or Admin. You will learn more from that one exercise than from most headcount discussions.
Revenue per employee is not a perfect metric. It is a revealing one. It will not tell you everything. But it will tell you where to look.
Your team is not too big or too small in the abstract. It is either aligned to revenue — or it isn’t.