Quantifying the cost of RTO

In which we put our data to one of the most important questions in hiring.

Quantifying the cost of RTO

In which we put our data to one of the most important questions in hiring.

Amazon's announcement that they’d be requiring in-office work for most employees predictably drew a lot of ire from engineers:

[A union] is the only way for these workers to have more agency and not be treated as disposal [sic] feedstock.

Amazon found the best way to reduce their workforce. Make them switch from a perfectly fine work environment to a horrible one and wait for them to leave. You don't even have to make them come, threaten to do it.

Who are you to tell neurodivergent employees to suffer? People who had an organ transplant to expose themselves to death? How petty are the tyrants.

Are these reactions a bit hyperbolic? Eh, probably. Whatever you think of collective action, “disposable feedstock” and “you’re literally murdering the immunocompromised” seem like a little much for what was the norm just a few years ago. I worked in-office in Silicon Valley pre-COVID, and I don't think the average engineer was exactly facing sweatshop conditions (although there's nothing wrong with advocating for better ones).

But that’s not what this article’s about.

Instead, we think it might be more useful to try to quantify exactly what return-to-office (hereafter RTO) actually costs in a cold accounting sense - not to say whether you should or shouldn’t RTO, but to say what you’ll be giving up if you do.

And it turns out that, between our data and conservative assumptions, we estimate that RTO adds $75,778 in effective cost to each engineering hire made at a typical tech startup. Or if you prefer the value on a per-year basis, we estimate an additional cost of $38,669 per engineering role per year.

if you feel like those numbers sound high: yeah, they do! But the full details are below, and the largest component of this cost comes from raw data. If you don’t like the assumptions we’re making here, there will be a spreadsheet where you can play with all the calculations yourself at the end of this post.


Salary costs

We’ll start with the most obvious, easiest-to-quantify, and most important cost: higher salaries.

Engineers who are open to in-office work typically ask for higher salaries than remote candidates do. The gap varies depending on how elite of an engineer you’re trying to hire, and tends to grow towards the higher end of the distribution.

For our purposes, we'll use the 80th percentile comp ask among engineers with 5+ years of experience, which is a rough estimate for a competitive but not extreme comp offer. And we’ll look only at US-based engineers who are not dependent on a work visa (=citizens or permanent residents) to avoid distortion from the need to maintain a visa or from large salary differences between countries. For the remainder of this post, if we say "senior US engineers", this is the group we're referring to.

Under those assumptions, remote-only candidates (yellow, straight-dotted line) are asking $33k less per year than their open-to-office (pink, rounded-dotted line) counterparts. The general population is shown in solid green for comparison:

Okay, so remote candidates are cheaper. But maybe remote candidates are worse? Are all the good ones in San Francisco, while the remote candidates are weaker engineers from Nebraska?

Short answer: no.

Long answer: controlling for remote preference, engineers in major tech hubs do seem to be slightly better on average (although if our data is to be believed the effect is pretty small). Indeed, the first candidate we placed (at a quite technical Y Combinator startup) lives in a mid-sized town in the Midwest, and the second worked for a consulting firm in a large but non-tech-hub city.

But whatever the gap between hubs and non-hubs when you control for remote work preference, remote candidates are definitely not worse. If anything, they're better than their in-office counterparts:

(These numbers are adjusted somewhat to compensate for the effect of different candidate sources. But even without those adjustments, the gap is comparably wide.)

You could try to explain this gap away if you wanted to. There are, no-doubt, a lot of selection-bias effects in play here, like which roles candidates are interviewing for. But if you want to be data driven in recruiting, you’re always dealing with selection effects. It’s easy to special-plead your way out of the obvious conclusion, which is that there is no empirical reason to believe remote candidates are worse (and some reason to believe that they are better).

In short: salary difference alone means RTO costs $33k/year more per candidate, and probably also reduces average candidate quality. Assuming an average tenure of approximately two years (typical enough for the startups we work with) that’s $66k more per hire right out of the gate, plus whatever opportunity cost comes from hiring less-skilled engineers.


The cost of a smaller pool

But we’re not done, because there’s another major effect of RTO: a much smaller candidate pool.

When engineers sign up to find a job through Otherbranch, we give them a lot of granular settings to specify their employment preferences, and remote work is far and away the strongest one. 41% of engineers are seeking remote work only, almost twice as many as the next-strongest preference:

This number stays almost the same (40%) if we limit ourselves to US senior engineers.

Even that isn’t the whole story, because you don’t just need a candidate open to working in-office somewhere - you need a candidate open to working in-office who either lives, or is willing to relocate to, the specific location of your offices. Accounting for that factor reduces the size of the pool much further, because only about half of open-to-in-office candidates are willing to relocate, and most of those are only willing to relocate to a limited list of locations.

The net effect of remote-only candidates and incompatible locations means that even in the most favorable location in our data set - the SF Bay Area - the in-office pool is 5.4x smaller than the remote pool. (This data set is restricted to senior candidates in the US, so this has nothing to do with hiring internationally.)

For our estimate of the cost of RTO, we’ll use the SF Bay Area value, or a 5.4x reduction in candidate pool.


Putting a dollar value to candidate pool

So, how do we convert that 5.4x into a dollar amount?

Well, sourcing is fundamentally a game of finding - and exhausting - sourcing channels. You start with excellent channels (e.g. personal connections, people who come in via your blog posts) and work your way down to weaker channels (e.g. job postings). The smaller your candidate pool, the faster you exhaust good channels and are forced to resort to weaker ones.

Framed this way, the benefit of a 5.4x larger candidate pool is that you get 5.4x more referrals, then 5.4x more organic inbound, etc. before you have to resort to job postings. That means fewer sources need to be developed, and that you get more candidates from high-quality, low-effort sources. So, as a first-order estimate, we’ll say that sourcing costs are roughly inversely proportional to candidate pool. That is, 2x the pool -> half the costs; 3x the pool -> one-third the costs, and so on.

That means that if we can determine the approximate cost of sourcing, we can estimate how much an increased candidate pool saves. And while the exact cost of sourcing is often amortized across multiple roles for the same recruiter and obscured by down-funnel effects, we can make a reasonable estimate by approaching the question from three different directions, each of which gives us a similar answer.

The details get a little bit tedious, so I've split them off into a separate section at the end of the post, but to summarize:

  • Estimating from first principles suggests a cost of about $150 to source a candidate that makes it to a phone screen, times about 50 phone screens per hire, equals $7,500/hire.

  • Working backwards from hiring costs, starting from the 30-40k hiring cost typical of the Bay, taking half of that to be recruiting (as opposed to interviewing), and half of recruiting costs to be sourcing, gets us $7,500-$10,000/hire.

  • Empirical data from the two recruiting companies I have direct data for suggests about $10,000/hire at Triplebyte and about $15,000/hire at Otherbranch so far (the figure is higher for Otherbranch because I am not an expert on sourcing).

All of this points to a sourcing cost per hire on the order of $10k, give or take. Let’s be conservative and peg it at $8,000, since a lot of these numbers come from a less employer-favored market.

But there’s also value in hiring faster. This cost of time-to-hire doesn’t show up in quarterly accounting directly, but anyone who’s been involved in hiring knows that it’s a critical metric, usually a more important one than sourcing costs. 

Indeed, the mere existence of recruiting firms like Otherbranch means companies must place a lot of importance on time-to-hire. They’re willing to pay us 20% of a hire’s first year’s salary (typically about $40,000) - and they would be delighted if that resulted in an instantaneous hire.

Not all of that $40k is going into accelerating time-to-hire (some of it is e.g. saving the sourcing costs just discussed). But if we assume even a tenth of what our clients pay us is reducing time-to-hire, we still come up with at least $4k in opportunity cost from delay caused by sourcing.

So even with conservative estimates, sourcing adds about $8,000 in actual budgeted costs and $4,000 in opportunity cost, or $12,000 per hire.

And that lets us quantify what our 5.4x larger pool is worth. If we were losing $12,000 of real and opportunity costs to sourcing originally, and we cut that value by a factor of 5.4x, we get a value of $2,222 instead, for a savings of $9,778/hire.

Note that this is probably not how it would look in your own local data. Instead, since hiring is somewhat thermostatic (that is, hiring processes tend to react to results and change their numbers accordingly), reduced candidate pool would lead to an implicit reduction in quality bar or concessions elsewhere. That would look like lower candidate quality or other losses, but it would fundamentally derive from candidate pool (in the same way that many company failures in 2022-2023 could look like local product failures but in fact were symptoms of background economic conditions).

Combining this $9,778 with the $66,000 in extra salary costs gives us the value we quoted at the beginning of the article: $75,778 per hire.

Or, to summarize in table form:


Churn, like buttah

But cost-per-hire isn’t the only important value. If candidates strongly prefer remote jobs (and they do!), then in-office jobs are also likely to face increased churn: candidates are more attached to remote roles and easier to poach from in-office ones. That means that not only is each hire more expensive, but also that in-office jobs also have to incur hiring costs more often.

How much might RTO increase churn? It’s hard to give a certain number, but we can take a stab at it by returning to the compensation numbers already shown once in this article.

The horizontal gap between the curves tells you the additional pay that an in-office engineer wants, but the vertical gap tells you what percentage of candidates would in principle be poachable by a remote role with lower pay. Presumably, a candidate that would be willing to jump ship for lower pay would also be willing to jump ship for a lot of other things, too.

The gap is around 10 percentage points, or about 13% of total engineers at the salary range we’re looking at. If we assume that that 13% of candidates are about twice as likely to jump ship as everyone else is, we’d get that same 13% as an increase in churn.

At a 2 year average remote tenure, 13% increased churn implies an average in-office tenure of 1.77 years. Framed another way, a remote role with a tenure of 2 years needs 0.5 hires per year, while an in-office role with a tenure of 1.77 years needs 0.57 hires per year instead.

And that lets us work out a per-year figure: $38,669 per year per role.


Conclusions

$76k per hire, or $39k per role-year. That’s a lot of money.

These values are somewhat speculative, yes. But they’re speculation that sticks pretty close to empirical data, and the dominant cost - the salary gap - comes directly from our own hard data.

If you think we’re full of it and want to try the numbers yourself, copy this spreadsheet and try playing with the inputs. The most optimistic values I could come up with that I could possibly result in $54k/hire and $27k per role-year - lower, for sure, but not by that much.

So, is it worth it?

Well, that’s up to you.

I don’t have a horse in this race. My company is remote, but it’s remote because - honestly - that’s what I like and because it made it easier to get it off the ground without venture capital. I’m fairly agnostic on which option is actually better. But, like almost all arguments about trade-offs, I think the argument is better with an understanding of what the trade-offs actually are.

If you favor remote hiring, these numbers look like they're strongly in your favor. If we’re anything close to right about these values, remote companies seem like they should outcompete non-remote ones (and since you presumably already believe that). But that comes with a corollary: the more it seems like remote should win, the more you should change your views if it turns out it doesn't. If remote companies aren't outcompeting in-office ones by a lot in five or ten years, you should ask yourself what is overcoming this enormous extra cost.

On the other hand, if you favor - or are personally implementing - RTO, ask yourself if the numbers presented here surprise you. It’s easy to say “well, Amazon knows what they’re doing” - but you are probably not Amazon, and you are not sourcing from the massive pool of candidates for whom Amazon is a specific long-term career goal. You can’t necessarily demand the concessions that Amazon can. (Granted, if you’re just doing it as a form of “constructive layoffs”, I suppose we’ve just made the case that that’s likely to be effective, so…well done, I guess?)

I actually do think you could argue that RTO might be worth 78k a hire. But did you argue that? Is that a trade-off you meant to make? Would you have made it if you’d thought of it as an explicit cost that large? Can you quantify where you think that extra 78k of value is coming from?

And if you can’t, are you sure it’s the right call?

Extra details that didn't fit in the post:

More on cost of sourcing

Don't other sources find smaller remote/in-office salary gaps?

Wait, so the sourcing costs are only a tiny part?

Is crypto really THAT unpopular?

What did significant figures ever do to you?

Extra details that didn't fit in the post:

More on cost of sourcing

Don't other sources find smaller remote/in-office salary gaps?

Wait, so the sourcing costs are only a tiny part?

Is crypto really THAT unpopular?

What did significant figures ever do to you?

Extra details that didn't fit in the post:

More on cost of sourcing

Don't other sources find smaller remote/in-office salary gaps?

Wait, so the sourcing costs are only a tiny part?

Is crypto really THAT unpopular?

What did significant figures ever do to you?

Rachel

Founder/CEO

I'm the founder here at Otherbranch. I used to be the head of product at Triplebyte (YC S15). I'm trying to find the middle ground between "moving fast" and "breaking things", think 20% slower than a startup but 150% faster than a non-startup. There's a lot of backlash against tech lately, and a big part of that is that we've failed to make it work for people - and that's what I'm out to do.


rachofsunshine on Hacker News

Rachel

Founder/CEO

I'm the founder here at Otherbranch. I used to be the head of product at Triplebyte (YC S15). I'm trying to find the middle ground between "moving fast" and "breaking things", think 20% slower than a startup but 150% faster than a non-startup. There's a lot of backlash against tech lately, and a big part of that is that we've failed to make it work for people - and that's what I'm out to do.


rachofsunshine on Hacker News

Rachel

Founder/CEO

I'm the founder here at Otherbranch. I used to be the head of product at Triplebyte (YC S15). I'm trying to find the middle ground between "moving fast" and "breaking things", think 20% slower than a startup but 150% faster than a non-startup. There's a lot of backlash against tech lately, and a big part of that is that we've failed to make it work for people - and that's what I'm out to do.


rachofsunshine on Hacker News

Improve your onsite pass rate.
Skip the grind of tech screens.
Hire better and faster.

Improve your onsite pass rate.
Skip the grind of tech screens.
Hire better and faster.

For employers

For employers

For employers

Set yourself apart from the crowd.
Show your hands-on skills first.

Get candid interview feedback.

Set yourself apart from the crowd.
Show your hands-on skills first.

Get candid interview feedback.

For engineers

For engineers

For engineers