CategoryEconomics

Tech Wages After Covid

In a few of the tech-oriented slacks I’m a member of there’s been a lot of back-and-forth about what might happen to tech wages in a post-COVID (and during-COVID) world where lots of tech jobs (prominently including more and more major players like Twitter and Facebook) are moving to fully remote.

Before getting into this topic, I want to acknowledge what a privilege it is to even have a job right now. I really feel for all of the people who are out of jobs and who work in industries that are likely to be severely impacted by the current crisis until we have a widely available vaccine. I’m writing this because it’s a topic of interest and I’m trying to practice making public predictions on things I’m interested in.


Of ongoing interest in these discussions is whether or not tech salaries in hubs like San Francisco and New York will remain elevated above tech wages in the rest of the country. Lots of larger companies either implicitly or explicitly use a cost-of-living adjustment to scale wages up or down for remote workers depending on where they live. I want to use this blog post to think a little bit about what the economics of tech-wages might look like post-COVID.

In this post, I’ll be assuming that:

  • The economy eventually returns to full steam due to reaching some amount of “herd immunity” or the broad availability of a vaccine.
  • The shift to remote work (at least to some degree) is essentially permanent — I won’t make claims about what the “future of work” will be, but I’m assuming that there has been a permanent shift in the willingness to consider remote work for both contract- and full-time employees for tech jobs.
  • Market forces (supply and demand) largely set wages for tech workers, regardless of how much value they may add (or not) to a company’s bottom line
  • The majority of tech jobs are located in high-cost-of-living (HCOL) areas like New York City and San Francisco
  • The barriers to hiring overseas workers remain high, even in remote-work settings1Language, time zone, and legal hoops remain very real here!

There are a few first-order impacts of the shift to remote work (and the increase in perceived risk associated with living in dense cities):

  • Some amount of workers currently in HCOL areas will move out of HCOL areas to lower-cost-of-living areas2I’m ahead of the curve here, having moved to Mexico 18 months ago to exploit the difference between my US wage and the lower COL in Mexico.
    • I assume that large cities will still hold appeal for lots of people for lots of reasons, but my belief is that there’s a large group of people who want to move to somewhere that isn’t New York City or San Francisco but had stayed put because that’s where the jobs were.
  • Tech companies, as they shift to supporting remote-first working styles, will recruit from broader swathes of the country

So there are really two market effects here:

  • Workers have more jobs they can apply to — if more companies support remote work, there are more jobs you can apply to no matter where you live (New Yorkers can now apply to San Francisco-based jobs, and vice versa. Software engineers in Oklahoma can now apply to both.)
  • Companies have a larger pool of applicants that they can select from — rather than selecting only people who live in San Francisco, or New York, or Boise, companies can find employees from all of them.

As we surely all recall from our intermediate microeconomics theory course3surely, the change in wages will be determined by:

  • The magnitude of the shifts in terms of both supply (number of workers) and demand (number of companies hiring)
  • The price elasticity (slope) of the supply and demand curves

Under this simple model, one might suggest that wages for tech-workers will generally drop under this new paradigm — tech companies in HCOL areas are now hiring from a wider pool (downward wage pressure) and tech workers are moving from HCOL areas to LCOL areas (dropping the “reserve wage” that they need to take a job / maintain their lifestyle).

However, this model is, in my opinion, not very good because it assumes that tech workers are homogenous — that simple supply and demand exercise assumes that the goods on the market are homogenous and interchangeable. In the market for tech workers in the United States, that’s just simply not true. Tech workers are actually highly differentiated4it’s exactly this differentiation that stemmed the tide of tech offshoring that many feared would drive American tech workers to extinction. — tech companies will pay a premium for top-tier talent and that’s one reason why so many tech companies are based in SF and NYC: that’s where the top talent lives.

If we assume that tech talent is differentiated, my prediction for tech salaries is this:

  • The shift to more remote work will exacerbate inequality (wage differentials) both within any given industry and for the world as a whole.
  • Those at the top of the skill distribution will earn more because there are more companies competing to hire them
  • Those at the bottom of the skill distribution will earn less because they will face more competition from others in areas with lower cost-of-living who can underbid them.

The more specialized your skillset is, and the more in-demand those skills are, the higher the wage you’ll be able to command. While you’re probably facing additional competition from other super high-skilled workers, the additional competition for your skills and expertise will likely lift your wages.

However, if you’re on the lower end of the skill distribution (maybe you’re still earlier in your career), the more substitutable your skills are and the more downward wage pressure you’ll face. Companies will see no good reason to pay San Francisco salaries for mediocre web developers if they can get the same talent in Sheboygan for half the price.

What that means is that we’ll see the highest tech salaries go up, and the lowest tech salaries go down.

So what does that mean for you? It means you should make your skills as specialized and as valuable as you can! If you’ve been skating by as a mediocre software engineer, now’s a good time to think about upskilling so that your wages don’t get driven down by people living in lower cost-of-living areas. Or you should start hunting for properties in West Virginia!

Ask the people what they want

I’ve been reading James C. Scott’s Seeing Like a State and as Scott chronicles the myriad ways that governments totally screw things up for their constituents through (often) well-meaning schemes of modernization and improvement, I’ve been thinking a lot about how this concept applies to the work I do in software engineering and product management. (Note: if you want to read a more general review of the book, go check out Scott Alexander’s review from 2017.)

The fundamental thesis of Seeing Like a State is that governments, in order to be able to be governments, necessarily have to abstract from the truth on the ground — a census can capture certain data points about the population, but necessarily cannot reflect all of the wonderful human variety that makes us who we are and that we observe and rely on in ourselves and in our neighbors. Like in Borges’s story fragment On Exactitude in Science we know that a map is only useful to the extent that it abstracts (strategically) from the true detail of our world — a map that actually includes all of the detail that might be relevant to any living being will necessarily be as large as the territory itself!

Where this is a problem is when so-called “High Modernist” governments believe that they can effectively use their birds-eye (and necessarily abstracted) view of the world to impose “improvements” on their constituents. Scott points out that these improvement schemes consistently fail because the governments fail to recognize that the differences they have abstracted over are actually incredibly meaningful to the human beings actually operating on the ground. Scott gives lots of examples from agriculture where government bureaucrats insist on the use of certain farming methods that have been “scientifically proven” to work in the lab (or in another country).

Unfortunately, when put into place in a different context, the methods fail abysmally and, though well intentioned, cause great suffering among the populations they were supposed to help. In general, the farmers on the ground tend to know better than the bureaucrats in the capital what will or won’t work well in their particular farm — they actually tend to have lots of expert knowledge about their particular soil, how it holds or releases moisture in different seasons of the year and how well different crops may or may not perform (and they recognize that this might vary substantially within their own property and from their neighbor’s land). When bureaucrats impose rules from the capital, they elide over these “minute” details that are actually critically important to maximizing the productivity of the land.

As I’ve been reading these accounts, I keep thinking that what the government should do is not force the farmers to “modernize”, but rather simply … ask the farmers what they need. If the farmers need tractors, deliver tractors! If they need more consistent water for their crops, the government can help installing water pipelines and irrigation systems. If they need seeds, the government can deliver seeds. Where the government consistently fails in these schemes is in assuming that the farmers are ignorant and that they do not know what is best for themselves and their families.

While it’s easy to mock these schemes as clearly destined for failure, I often see the same thing happening in software! Especially for tools- or services-oriented internal teams (like the Analytics and Data Teams that I tend to work with) it’s very easy to assume the hubris of the misguided bureaucrats and believe that all your users need is your particular solution to fix their problem (that they might not even be aware of). When this happens, the best case scenario is that the software gets built and goes unused — in the worst case scenario the software builders break a solution that used to work and replace it with a less-flexible system that actually increases the work load of the users it was intended to help. Here’s how I’ve seen this in the real world:

  • The software engineer observers a workflow that seems cumbersome and error-prone. Often involving complicated spreadsheets.
  • The software engineer thinks to himself: I know, I can code this process up in R or Python, get the benefits of version control and it will save these excel jockeys a boatload of time
  • Software engineer starts coding. Realizes this excel spreadsheet is more complicate than they thought. Keeps coding, eventually gets to feature parity.
  • The software engineer attempts to role out their shiny new tool, only to learn that 1) the excel model they were attempting to re-create has already changed substantially since they started this project and 2) the users don’t want to use the new tool because they crucially rely on the flexibility of Excel to do their jobs

I’ve seen this happen a number of times (and have been guilty of it myself!) — while this happens very frequently with data scientists and analytics engineers who look down on excel workflows, I know it also happens in other realms of software engineering as well.

Where this process goes wrong is that the all-too-helpful software engineer failed to ask their users what they actually needed help with — they jumped from their assessment of the problem to a proposed solution that missed out on crucial details of how the users actually do their jobs and the features that they need to continue doing that job well.

What we as software engineers and product people must always remember is that you have to actually talk to your users. In the example above, the software engineer might have learned that the most pressing problem was actually a version-control and file-naming problem — in which case the software engineer could have focused on that problem in particular and saved the user (and the rest of the organization a lot of headaches) while also wasting less time (==money) on the project.

That user probably does recognize that their workflow isn’t ideal, but in order to figure out how to help them, you actually have to talk to them to understand their true pain points. As internal tool-builders, we are often at greater risk of building tools that our users don’t want or need because there are no market forces that drive our product adoption. With external user-facing features, our business will observe if users like them or not (or, if our business isn’t paying attention to these things, probably won’t be around much longer anyway). However, with internal tools the danger of being the bureaucrat imposing changes from a too-abstracted view of the wold is much more present, and we should remain vigilant that we aren’t building useless tools or, even worse, imposing our broken new tools on users just trying to get their jobs done.

Price and Value

Last night on a boozy zoom call with some friends I did a very poor job of trying to explain how I think about the difference between price and value (and why that difference is important). I’m going to try to use this space to clarify my thoughts on the subject in a way which will hopefully be informative to y’all as well.

I believe that the term “value” can apply to a few distinct concepts:

  • Usage value — this is something like the “utility” that I get from using  a product or a service
  • Financial value — this is the purely monetary value of an asset and generally refers to future expected income streams from owning an asset

The consumption of consumer goods often only have usage value — for example, buying a ticket to go see a movie has no financial value because there’s no future expected returns from that. Owning a financial instrument, like a stock or a bond, often only has financial value in that there’s no additional utility that comes from owning that asset. Something like owning a home has both — both usage value (if you live in that home) and some amount of financial value from a potential future sale of that home or from renting the home out to others.

The financial value of an asset can be tricky to reason about because there are a few different interlocking concepts:

  • Financial value
    • True future income stream — this is the “true” schedule of future returns from owning the asset. This is unknowable except in retrospect.
    • An individual’s fundamental valuation — this is the net present value of the assets future expected returns.
      • An individual’s belief’s about the future income stream of an asset (i.e., what’s going to happen in the future)
      • An individual’s net present value function which will vary depending upon the individual’s belief’s about the future and their risk tolerance (the value of money today vs money tomorrow)

I want to say that there exists a true future income stream of an asset that exists but that it is unknowable, and lots of different individual’s fundamental valuations. Individual’s valuations may differ because they have different beliefs about the future or because they have different discount rates.

One thing that complicates this picture is that to any given individual, there are two different ways that an owner can realize the value of an asset:

  • Receiving a stream of income into the future according to the assets true future income stream
  • Selling the asset to someone else at the prevailing price

The second point is what can lead to confusion about what the value of a financial asset is — since owners of an asset can always sell the asset at the prevailing price, it can be tempting to say that the price reflects the asset’s value.

When I’m talking about financial assets, I want to define price and value distinctly.

  • Price: in financial markets, price reflects the weighted average beliefs of all the individuals in the market about the financial value of the asset

So, price does not impact the financial value of an asset in terms of future income streams, but it can affect the value to an owner of the asset, because if the price is higher than the owner’s individual fundamental valuation, they can (and should!) sell the asset on the market and come out on top.

The point that I want to keep clear is that the price of an asset can move around a lot (e.g., in the stock market) without the underlying value of the asset shifting at all — sometimes they both move together, sometimes the value can change while the price stays the same. But they’re too distinct concepts and hopefully this clarifies how they’re distinct.