Revenue per Employee

Live from Schenectady, New York, it's the Metrics Brothers, Growth and CAC.

And I'm Growth, better known as Ray Reich, founder and CEO of Benchmarket.

And I'm CAC, better known as Dave Kellogg, EIR at Balderton Capital, independent consultant, and the author of Kelblog.

And together we are the Metrics Brothers.

And we go together like revenue and headcount.

I don't think they go together quite like they used to there, Dave.

Yeah, well, that's kind of the point, Ray. For, for years and years in enterprise software, there was a relatively stable relationship between number— between revenue and employees, and it went something like $200,000 to $400,000 revenue per employee. But, but all that's changing, you know.

But It's not discussed that often in board meetings, or at least not the board meetings I've been part of. The only time I saw revenue per employee discussed was more of, hey, how much new revenue can we close with this many AEs?

Yeah, well, certainly sales productivity, i.e., ARR, new ARR per AE, is definitely a popular metric. But I do see the people I work with, Ray, do track ARR per employee as a, I'd say, as a gross productivity measure.

So, the question here is, do you think we should be talking about ARR per employee or revenue per employee in this episode?

Well, I think we should talk about both, Ray. But before we do that, let's hear a word from our sponsor.

The Metrics Brothers is proudly sponsored by BenchmarkIt!, the B2B AI and software industry's largest, broadest, and most contextualized benchmarking index. Dave CapKellogg and Ray Grothe-Reidt Have put the Metrics Brothers podcast on hiatus for remainder of 2026. All episodes we have ever recorded are still available on your favorite podcasting app. You can reach Dave at Kellogg and Ray on LinkedIn at Ray Reich. Thank you so much for listening to the Metrics Brothers podcast. And if you'd like to sponsor the Metrics Brothers and be part of these conversations about revenue per employee and AR per employee, send Send us an email at metricsbros@benchmarkit.ai and we'll make sure we talk to you about that. Okay, Dave, revenue per employee history. You ready to start there?

Yep.

Okay, so the metric goes back to actually the late 1800s, early 1900s, and the first place that I heard about it was from Frederick Taylor, who was the father of scientific management, and he used it to really try to examine output per worker as a primary manufacturing productivity measurement. It gained traction, especially when the Fortune 500 was launched, because it provided investment analysts with the data to compare revenue per employee or productivity between companies— GM, Ford, Chrysler, etc. And then we saw an increasing use of it even more in the '80s and '90s, where we saw a lot of Wall Street analysts were adopting it as a quick efficiency screen and M&A due diligence, and it often became a pretty standard signal of is the business model of high quality and do they have scalable unit economics. So that's how I've seen the history evolve, and it's a pretty simple equation on the surface. You take the annual revenue, you divide it by the number of employees, and you get— voilà— revenue per employee. But Dave, a couple of cautions here, right?

We are the Metrics Brothers, Ray. So our job is to make the simple complicated. So revenue per employee, it sounds simple. And there's a numerator and a denominator, right? We divide one by the other. The numerator these days is typically either revenue or in recent times ARR. We'll come back to the numerator in a minute. But let's go to the denominator because Ray is saying revenue per employee, and that's not how I often see it used. Where I see it, it'll be ARR. Or revenue per FTE. And this begs a bunch of questions. First, what does the E stand for? So, Ray, when I say FTE, what's the E mean?

Full-time equivalent.

Bingo! So, some people think it means full-time employee, and I think that's just kind of a misunderstanding. So, FTE means full-time equivalent. Let's talk about that notion. So first, What's a full-time equivalent? Let's just say you run a fast food franchise and you have shift workers who work 20 hours a week. So, full-time equivalent would be 2 20-hour shift workers are 1 full-time equivalent, right? Because between them, they work 40 hours. That's a pretty easy one. Now, in the software business, it gets tricky because what about, hey, there's an SEO person who's really good. You don't have an open headcount. You want them on their team. You hire them as a contractor. So, it's a different legal basis. You pay them on a 1099. They don't get benefits. Are they— if you were doing revenue per employee, well, they're clearly not. But if it's revenue per FTE, in my opinion, they clearly are. So, any other ones, Ray? Because there's one big one. I'll let you intro.

Well, the one that I think we've used in the software industry forever is a lot of offshore development. And whether you actually hire your own people, they may be at 1/3 to, you know, 1/2 of the cost. So, is an offshore developer 1 employee or are they a half employee? I've worked with companies that will say, hey, it was half the price, so it's only 0.5 FTE. And then you've got, I'm using an outsourcing company where they're not my employee, but I've got 20 developers with an offshore outsourcing company, how do I allocate them? And typically, it's some ratio. X number of offshore consultants equals 1 FTE.

Yeah, there's 2 different issues there. One is, are they employees or not? Because sometimes people work with an offshoring company. Sometimes people open a subsidiary. So, if you're going to count employees, then, then if they're employees, it seems like you shouldn't leave them out. The question is then, do you do some sort of transformation to say, hey, this is a low-cost location? I've seen ratios of 3 to 1 to 4 to 1 used, frankly, depending on what the function is. Is it test Is it development? Is it a call center? The ratios vary there depending on what the activity is. But if they're employees, in my mind, it's hard to leave them out. If they are through an offshoring company, well, they're not employees. But remember, the E doesn't stand for employee, it stands for equivalent. So should they count in? And I think the answer is, as all good questions, it varies. If you're running an offshoring company, Right? And you do offshore call center work. And you've got 5,000. I once worked with a customer who had like 200 people in the U.S. and 5,000 people in Manila. And those 5,000 people, they were an offshore call center service. And it's all the numbers would break if you took their revenue and divided it by, you know, what was it, the 5,200 as opposed to 200. It throws all the metrics off. I do think in that particular case, the employees are actually COGS, which kind of changes things too. They're going to show up but not an operating expense. But in any case, I think the big question is for the people interested in metrics in our audience, Ray, which hopefully is everybody, that we need to make sure we've defined E clearly. And we have to deal with contractors. We have to deal sometimes with consultants. We have to deal with offshoring either when they're legally our employees or they're not. The standard answer to the question is either you exclude them entirely or you do some transformation. I know very few people who count offshored people as, uh, on a 1-to-1 basis.

Exactly right. So for the audience, hey, look at— if you're looking at a benchmark or doing your own calculations, whether it's revenue per employee or revenue per FTE. Hey, let's go down history and a little bit down the road. I would call it the rearview mirror here. Is that okay, Dave?

You can, Ray. You'd love to be in the rearview mirror, Ray. I'm not gonna—

I'm gonna spend like 45 seconds here. This is going back to the 1990s. Where I want to talk about historic benchmarks for revenue per employee in enterprise software days. And companies like Microsoft, they were the big— big and the best. They were like $334,000 per employee in 1995, where Oracle was $172,000, Siebel was $220,000, SAP was $278,000. That's much lower than the benchmarks you're going to see today. But I want to highlight something there. Enterprise software companies often had a much higher percent of their revenue coming from professional services, not 90 or 100% being software only. So that impacted its revenue per employee metric. I don't know if there's anything more you want to say about that.

Yeah, this one, I mean, to me, you know, grosso modo, it's still the same range. It was the lower end of it, but, but we're now back in time 30 years, and these companies are running between, like I said at the start, $200 and $400, in this case $200 and $300. But, but revenue per employee that was kind of the typical figure. Now, it's gone up a little bit with SaaS. And as we'll talk about at the end, it's gone up radically with AI. But yeah, so to me, Ray, you look at this and go, oh, they used to be lower then. I look at this and go, wow, they're still roughly in the same range. And by the way, certainly SaaS startups today, while they're growing, will have $200K, $100K, like you'll even see $100K per employee. So, these numbers are not low. They're low for the public company benchmarks that you'll probably pull later. But for a growth-stage SaaS company or an early-stage SaaS company, $100,000, $200,000 is typical. $300,000 is great. Yeah.

Well, let's look at public SaaS companies and look at 2025. Using the Benchmarkit kind of SaaS 100, the top 100, there's about 134 public SaaS companies. The median in 2025 was $395,000 of revenue per employee. So that is up pretty dramatically from what we saw in 1995. Hell, Dave, let's just compare that to what we saw in 2022 in the SaaS industry. The median for public SaaS companies was $327,000. It's now $395,000. So it's up almost 21% over the last 3 years. So there is a trend towards higher revenue per FTE for public SaaS companies.

What's the median, Ray? Tell me again. Is it—

The median is $395,000 today.

Yeah, okay. And again, public companies today are a lot bigger and better than public companies were 35 years ago. Never forget that, right? You could go public at $30 million 35 years ago or 30 years ago. Um, so now, now today you need to be nearly a billion or somewhere between half a billion and a billion to go public. So a lot has changed. These numbers look good to me. And I never knew that Benchmarket had a SaaS index, Ray. I didn't know you had a public company index. Is this new?

Yeah, we launched it about 3 months ago.

Ah, okay. Good PR on that.

Great PR. Now, what's interesting, and this is going to open up a next question. You heard me, I said revenue per FTE. We also do it, and as Meritech does and other public SaaS company databases, look at implied ARR per FTE. And just a reminder, implied ARR Take the latest quarter revenue times 4. That's the standard formula. And ARR per FTE in the same timeframe, Dave, the median was 413. So about 5 to 7% higher. But that's why it's so important to know whether you're looking at implied ARR or ARR per FTE versus revenue per FTE. And didn't know if you wanted to comment on that a little bit.

Yeah, I mean, to me it's a 5% difference. So to me it's roughly the same. It all depends how you want to, how closely you want to look at these benchmarks. But your point is well taken. There's a difference between revenue and ARR, and it is important to know which one you're looking at. But I don't think that 5% delta is massive. I do think the other thing I would say, Ray, is that only big companies do implied ARR, right? When you're doing benchmarks in small company SaaS, they are certainly telling you ARR. No one calculates implied ARR. It's not to say they couldn't. It's not hard to calculate. But usually, the metric is ARR. And if you look at private company ARR per employee, it is very much a function of size. And I want to just cite the 2025 data that Ray provided here. And in the bottom bucket, which is $5 to $20 million, you're seeing $144K ARR per employee. So, this is common at this size range. That's the median, I would suppose.

It is.

At $20 to $50, it's up to $200,000. What you see basically is the SaaS companies grow, in my opinion, you're getting the benefit of the recurring revenue. So, like when you're little, you have no revenue. So, you need to sell. So, everything is new. But by the time you get to $100 million, a $100 million company growing at 20%, right, will start the year with $100 million renewing. So, you kind of have this free tailwind, not free for the customer success team, but certainly free for the sales team that allows you to increase your ARR per employee over time. So, this benchmark in 2025 for little companies is $150,000. For $100 million plus, it was $300 million, and it rose fairly linearly across those buckets. Yeah.

And the other thing, just like public SaaS companies, and this is kind of, you know, when growth at any cost became efficient revenue growth, those $20 million to $50 million, $50 million to $100 million, $100 million above, they all increased their revenue per employee over those 3 years by about 20%. So you can see where efficiency became more of a focus there, Dave.

Yeah, well, we really are live from New York here today, as you can hear from the sirens in the background, Ray. So I'm going to mute myself from time to time. Um, but why don't you take us on to our next topic?

Okay, and this is a little bit of a pit stop before we get to the AI— native AI software companies' revenue per employee. And, you know, we've talked about revenue per employee versus ARR per employee, you know, with the evolution of usage-based pricing, and it's becoming so popular across not only legacy SaaS, but of course, AI-native software companies that even big companies who do usage-based pricing like Snowflake, Datadog, Mongo, they don't even report ARR. We mentioned how you calculate implied ARR. So my prognostication is we are going to see more and more companies reporting revenue per FTE. versus ARR the same way a lot of other metrics will probably start using revenue instead of ARR. Dave, what do you say?

Yeah, that one I agree. It's non-controversial. If ARR dies, all the ARR metrics die with it. If revenue replaces ARR as a result of ARR's death, that's true as well. And to me, it's as soon as you go hybrid in your pricing, Right? I don't need you to be 100% outcome or 100% usage. As soon as you go hybrid, ARR starts to lose meaning, right? And so, you could still be 80% subscription plus 20% usage or outcome, and that's going to start to break all the ARR metrics because ARR starts to lose meaning. So, I think this transition is going to happen very quickly because it doesn't take you crossing, right? It just takes a little bit to contaminate it. And then, oh, ARR is contaminated. Now let's use revenue. So I think, frankly, this year and next year, everyone's going to move from ARR to revenue.

Well, and let's move to what everyone's talking about now. And that's the hypergrowth of these AI-native software companies. So we're going to give some examples here and just talk about how it's changed the entire kind of comparisons. And by the way, just as a small data point, when Salesforce went public just a little over 20 years ago, 22 years to be exact, They went public at around $200,000 per FTE. That's when they went public. Let's look at Cursor. Cursor, just a little over a year ago in January of '25, they had $100 million of revenue, 60 employees. That's $1.67 million per employee, Dave. The latest data I found was just in November, just a few months ago. They're now over $1 billion in revenue. So amazing growth, 10x growth. They have 300 employees, so 5x employee growth. So they're up to $3.3 million per employee.

Wow.

Midjourney, they're at $504 million in annualized revenue with 107 employees. So that's 4.7. And my gosh, let's look at Anthropic. I know that they're the, maybe the outlier, but late last year it was reported they had about $9 billion in run rate and 2,300 employees. That was $4 million per employee. Going into January, they said they were at $14 billion run rate. And with about 3,000 to 5,000 employees, so that got them to $2.8 million to $4.7 million. And by the way, Dave, I don't know if you heard the rumor just a couple days ago, they're now supposed to be at a $30 billion run rate by— at the end of Q1. So their revenue per employee is in that $3, $4, $5 million per range.

Yeah, so, so look, there's 2 things I want to say on here, right? One is The story is that for a long time, for 30 years, this metric ran between $200K and $400K, grosso modo, and now it's 10x with native AI. And this is one of the reasons I feel like if you want to pitch yourself to venture capitalists as a native AI company, if you're showing up at $200K in revenue per employee, it's going to badly undermine your message, right? And in the old days, you could bluff with slideware, like you could bluff cloud, but now I just feel like VCs will look at you and say, great, what's your revenue employee? And go, oh, you're not native AI. I mean, first they'll look at a demo and make a decision, but second they'll just say, oh, like, you may be native AI and I don't care because you don't have the growth rate and you don't have the productivity. So this is almost a screening metric in my mind to see if, like, are you traditional SaaS dressed up as native AI or are you native AI? Because if you're native AI, you're not 1 or 2 times better, you're 10 times better. So, so it's a big, big change. Um, so that's the story. This metric just got 10x'd. The part— now, Ray got trapped here a little bit. I'm gonna— I just noticed this, Ray, but you're talking about revenue, and what these figures are that these companies are releasing is a form of implied ARR, right? Because what they're doing is taking last month's revenue and multiplying by 12. You could call it run rate revenue or monthly annualized revenue or monthly run rate annualized revenue. But what they're doing, I know this, this part I'm quite sure about, is they're taking last month's revenue, multiplying by 12, and then putting that out there for the productivity feature. And that is not revenue, right? The revenue is going to be badly lacking.

Dave, you identified something really important because sometimes they will call it ARR, but I saw more times they were calling it run rate revenue. Yeah, to your point, it's the same thing.

Run rate revenue on a quarterly Let's just be clear, it's the same metric, right? So, but these guys are doing it on a more aggressive basis. I'm virtually positive they're doing it monthly, right? They're not even taking a quarter. When you're growing very quickly, 12 times the last month is a lot more than 4 times the quarter, right? So if you want the biggest number, right? See Succession, congratulations, just had the biggest number. If you want the biggest number, You're going to take the most recent month and multiply by 12. So, we got to be careful because we're saying these revenue per employee figures and they aren't trailing revenues, right? When we talk about these other companies, we're not playing that game. We're using revenue, i.e., definitionally trailing 12-month revenue, if you're talking about Salesforce or something else. So, right, because Salesforce isn't going to release 12 times last month's revenue, right? That figure is not available and they're not going to show it.

Right.

Even the Metrics Brothers can get headfaked by this hype, right? Yeah, I don't know if you got fully headfaked, but you were partially headfaked, I think.

Yeah, well, I didn't clarify here, so that is very correct. And by the way, I also, I want to share this and see what you think. As I was doing all this research, I'm talking to a lot of AI-native software companies right now, right? They're getting, they're taking advantage of a lot of experimentation budgets. Every company is like, I got to get more AI in here. I let my employees buy more AI, et cetera. So the friction of customer acquisition is a little bit reduced for all these AI-native software companies. And over time, as we see more rigor in the budgeting process and we see more kind of IT involvement— and by the way, I just did some AI software purchasing benchmarks, and 74% of the time in enterprise-class companies, it's IT buying, not departmental. I believe we're going to see more investment in traditional GTM. And I think this revenue per employee could stabilize or even go down in the future. And I think it's something to watch for over the next 12 to 24 months.

Well, first, I think some of these 10x productivity statistics, as per the last discussion, are actually just bad math. I'm now thinking the answer might be more like 5x, just to ballpark the effects of that math. I think what Ray is saying here is important, which is some of this revenue is kind of easy come, easy go. I mean, I think there's 2 things that are going to happen. One, there's a coming wave of churn like, you know, we've never imagined. Because if everybody bought in a given category 3 tools to play with all 3 and then pick one, then you're going to churn 2 of them, right? Or even if you just bought 2, like I use Claude and ChatGPT all day, every day. If I worked at a company, I'm assuming one day maybe they'd standardize on one or the other, right? So, when that happens, that's going to generate churn for one vendor. It's going to continue a revenue stream for the other. So, I think there's a wave of churn coming. I think there'll be a growth slowdown. And as growth slows down, this trick of annualizing the last month will— some of the productivity that was never really there will leak out of that as things stabilize. So, I'm now thinking, Ray, that on paper right now, when you talk to a VC, they're going to go, hey, it's 10x the productivity. And it's like, yeah, steady state is probably more like 3x. But that's where we're at.

It's going to be really interesting when Anthropic and OpenAI go public to be able to actually look at this data when it's GAAP-based, right?

Yeah. And you'll see quarters too, which will help. You won't see months. So some of those claims won't be verifiable, but you will see quarters and that will be enough to do a lot of work.

Now, I had a lot of fun doing this episode and, you know, I don't like to end episodes with a question or it's an it depends, but One of the things I've been working on with 2 different companies right now is revenue per agent. What they're trying to understand is when they invest in an SDR agent or a sales agent, how they're measuring that productivity compared to human productivity. So my question is, when we look at revenue per employee 2, 3, 5 years from now, how do we factor in agents?

Yeah, I mean, there's no good answer to that. And, you know, if you have I don't even know how to granularize or count agents. Like, if you have an SDR agent that runs 24/7, that's equivalent to 3 human SDRs, right? So you have all these counting issues. What actually counts as one instance of an agent versus another instance? I have no idea. So I think, I don't think revenue per agent is going to end up being a metric, is the long and short of it. The other thing I would argue is that Vendors in general should shy away from selling anthropomorphic agents, i.e., oh, meet Piper, our pipeline agent, right? And you could say, do you have to buy 10 Pipers if you're a big company and you only buy 1 Piper if you're a little one, right? Or is Piper in fact just a product that's priced on a volume basis? So, there's 2 reasons to do it. One, people tend to want to map it to people and you don't want to do that. 2, the more important reason why you shouldn't sell an anthropomorphized agent is you should decompose what it does and sell those as separate products. Hey, it does lead qualification. Hey, it does outbound. Hey, it does this, right? And you want to sell those capabilities. When you're building a price list, I think you want to build a capabilities-based price list, not kind of an agent instance-based price list, which means you're going to want to decompose it, not aggregate it. And the kind of human anthropomorphic agents actually aggregate all kinds of things that a person does into one agent. Yeah.

Well, I found this episode a lot of fun and it begs a lot of questions for me on the future. But Dave, you want to wrap up with any final thoughts?

Nope. This is an oldie but goodie as a metric goes. Historically, it runs $200K to $400K. We saw how the super high-growth native AI companies are really kind of 10xing that. We think some of those are kind of transient effects, but it is going up. There is no question. I think it's a good gross productivity measure. And I think the hardest part of calculating it is figuring out what to do with offshoring. Because some of the little trade-offs about a contractor here, a consultant there don't move the needle. But, you know, 4,000 people in India do.

Yeah, love it. And I'll just re-emphasize, know if you're looking at benchmarks where you're getting revenue per employee, revenue per FTE, or ARR per employee, or ARR per FTE.

Yeah, make sure the person who calculated FTE knows how it's defined because half the time, I think if you ask them what it stands for, they'll say full-time employee. Not full-time equivalent.

Okay.

See you, Ray.

See you everyone later.

The Metrics Brothers AI, SaaS, and More is a production of the Metrics Brothers Growth and CAC and a member of the Benchmarkit Podcast Network. By accessing this podcast, you acknowledge that the Metrics Brothers make no warranty, guarantee, or representation as to the accuracy or sufficiency of the information provided or the humor content of the jokes told. Ray, information, opinions, and recommendations presented are, according to our spouses, probably wrong. and provided for information purposes only. This podcast should not be considered professional or, for that matter, unprofessional advice. We disclaim any and all liability for any direct, indirect, indirect, misdirect, incidental, special, ordinary, consequential, inconsequential, or other damages arising out of any use of, or God help you, reliance upon the information presented here. Ray Grothreich is based in New York City and available on X @rayreich. Dave Kellogg is based in Silicon Valley and available on X @davekellogg. Kellogg. Schedectity, which is French for unspellable, is not our actual production location. Thanks for listening.