Clouded Judgement 4.24.26 - The AI-Driven Employment Explosion

Every week I’ll provide updates on the latest trends in cloud software companies. Follow along to stay up to date!

The Impending Employment Explosion

I’m a perpetual optimist. It’s hard for me to see the world through any other lens! Sometimes I’m naive, but overall I think it’s a better way to live (and, generally, hard to bet against humanity’s resilience).

One of the larger debates surrounding AI relates to the impact it will have on employment. One side (booo, the pessimists!) argues we’ll see a collapse in employment as AI takes everyone’s jobs. The other side argues some form of “Jevon’s paradox” - with massive positive economic benefits. Given my intro, I think it’s clear what side of that debate I fall on!

There are many ways I’ve framed this in the past (I think I’ve even written about it in a prior week’s edition). However, I heard Jensen recently articulate it much more eloquently (surprise surprise, he’s better at framing this than me!). The crux of his argument (which I wholeheartedly agree with), is that the framing of “AI will take jobs” is wrong. In order to actually debate this, you have to separate the job, from the task. What does this mean? Let’s use an example. The job of a software engineer is to build high quality software. A task of a software engineer is writing code in an IDE. AI may in fact automate one task of a job (ie automating writing code which will no longer be done manually), but it won’t replace the job - building high quality software. Because there is more to the job than just one of its tasks. In fact, I’d argue AI will have the opposite impact! AI will make the task much easier, leading to an explosion of people doing the job! This isn’t anything novel (it’s a common claim to say AI tooling will lower the barrier to creating software, leading to lots more software created!). But I hadn’t heard it framed the way Jensen did - separating the job from the task.

What’s the common pushback to this? Well what if the one task represents a significant portion of the job! Saying software engineers are “software builders” is just putting lipstick on a pig! They’re really just code writers!” I get the pushback, but I think it misses something important. The hard part of being a software engineer was never the typing. It was never the syntax. It's understanding the problem deeply enough to know what to build. It's knowing how to architect a system, how to make the right tradeoffs, how to debug the thing when it breaks in some way nobody anticipated. The code is the output (not the job). And look, maybe the skeptic is right that writing code is 60-70% of the time spent today. Fine! But that just proves the point even more. If you can compress 70% of the time, you don't get rid of the person… you get that person shipping 3-4x more. And what does every company in the world want? More software. More tools. More internal apps. More automation. More everything. The demand for software is nowhere close to saturated. We've been supply constrained, not demand constrained. So when you make it much easier to supply software… you don't get fewer engineers. You get more. The nature of the software engineer job will change (probably a lot!). But the job itself? It gets bigger, not smaller.

Here’s a hypothetical example I like to use. Let’s say we existed in a world before cars were invented. And if you wanted to travel from your home to the grocery store you used a horse drawn carriage. Let’s call the person operating the carriage the chauffeur. Then, let’s assume some technological innovation happened EXTREMELY quickly, and all of a sudden cars were hitting the road (the key part of the analogy here is the part in all caps - this change happened QUICKLY, just like AI has). A pretty pessimistic take may be “Ah! This is terrible! Think of all the chauffer’s who will loose their job!” But it’s pretty easy to see the world through a different lens. What it means to be a chauffer stays the same (you help people get from point A to point B). The task of a chauffer was operating a horse drawn carriage (and maintaining it, buying parts for it, etc). Now, the task of a chauffer changes! Their job is still helping people get from point A to point B. BUT the task changes - now they need to learn how to operate a vehicle (how to drive a manual transmission car) vs how to use the reins to help horses navigate.

And what happens in this world? We have way more chauffer’s because transportation has instantly become way more efficient (ie less productivity waste). At the same time, entire new industries are born servicing the automotive industry! Auto mechanics, oil and gas, auto manufacturers, etc.

Yes - the task of operating a horse drawn carriage, or manufacturing the carriage itself went away. But the job of a chauffer saw a spike in demand (leading to more employment), and a trickle down of job creation in adjacent industries.

I’m so convinced we’ll see the same thing happen with AI, and an explosion of employment is coming. And we do have some precedent to support this! ATMs came out in the late 1960’s. However, from that point in time to the mid 1980’s the number of bank tellers in the US doubled. Tellers went from cash-in / cash-out machines (the task) to relationship bankers who cross-sold financial products (the job). The task got automated, but the job got more valuable. At the same time, the task got way cheaper! According to Claude: “Before ATMs, you needed ~21 tellers to staff a branch. After ATMs hit saturation, that dropped to ~13. So the cost per branch went down meaningfully.” Cheaper branches lead to more branches. And more branches led to more tellers (in aggregate). I asked Claude to chart the number of bank tellers in the US. What do you see, number of bank tellers exploding at the same time the ATM came out)

You could make a similar argument around lawyer growth in the 70’s, 80’s and 90’s. The job of a lawyer is to protect and advance their client's interests, the some of the tasks include researching case law and drafting documents. Before the PC, a huge chunk of a lawyer’s time was spent on tasks that technology was about to automate. Legal research used to mean physically going to a law library, pulling case books off shelves, reading through indices, cross-referencing citations by hand. That could eat days or weeks. Then Westlaw (1975) and LexisNexis (late 70s) came along and compressed that to hours. Later, full-text search made it even faster.

Document drafting was similar. Contracts, briefs, motions - all typed up by hand or dictated to a secretary who typed them. Every revision meant retyping the whole thing. Word processors (and later PCs with WordPerfect / Word) made it so one lawyer could produce 5-10x the document output. So did things that automated the “tasks” of lawyers (PC, internet, LexisNexis, word processors, etc) lead to a reduction in the number of jobs held by lawyers? Here’s a chart from Claude:

I feel like there’s so many other examples I could use. Radiologists (this is an example Jensen uses). In 2016 Geoffrey Hinton (Godfather of Deep Learning!) predicted radiologists would go away because of AI. What happened? The job of a radiologist is patient care. The task is reading and interpreting scans. AI got really good at the task. But the job didn't shrink (it grew!). Because the demand for imaging exploded (more types of scans, more conditions screened for, aging population), and radiologists' job of providing patient care evolved toward more complex interpretive work, interventional procedures, and clinical consultation

The through line is the same: automating a task is not the same as automating a job. And more often than not, it leads to more of the job, not less. I expect AI to be no different.

Quarterly Reports Summary

Top 10 EV / NTM Revenue Multiples

Top 10 Weekly Share Price Movement

Update on Multiples

SaaS businesses are generally valued on a multiple of their revenue - in most cases the projected revenue for the next 12 months. Revenue multiples are a shorthand valuation framework. Given most software companies are not profitable, or not generating meaningful FCF, it’s the only metric to compare the entire industry against. Even a DCF is riddled with long term assumptions. The promise of SaaS is that growth in the early years leads to profits in the mature years. Multiples shown below are calculated by taking the Enterprise Value (market cap + debt - cash) / NTM revenue.

Overall Stats:

• Overall Median: 3.0x

• Top 5 Median: 18.4x

• 10Y: 4.3%

Bucketed by Growth. In the buckets below I consider high growth >22% projected NTM growth, mid growth 15%-22% and low growth <15%. I had to adjusted the cut off for “high growth.” If 22% feels a bit arbitrary, it’s because it is…I just picked a cutoff where there were ~10 companies that fit into the high growth bucket so the sample size was more statistically significant

• High Growth Median: 10.6x

• Mid Growth Median: 4.9x

• Low Growth Median: 2.2x

EV / NTM Rev / NTM Growth

The below chart shows the EV / NTM revenue multiple divided by NTM consensus growth expectations. So a company trading at 20x NTM revenue that is projected to grow 100% would be trading at 0.2x. The goal of this graph is to show how relatively cheap / expensive each stock is relative to its growth expectations.

EV / NTM FCF

The line chart shows the median of all companies with a FCF multiple >0x and <100x. I created this subset to show companies where FCF is a relevant valuation metric.

Companies with negative NTM FCF are not listed on the chart

Scatter Plot of EV / NTM Rev Multiple vs NTM Rev Growth

How correlated is growth to valuation multiple?

Operating Metrics

• Median NTM growth rate: 13%

• Median LTM growth rate: 15%

• Median Gross Margin: 76%

• Median Operating Margin 0%

• Median FCF Margin: 21%

• Median Net Retention: 109%

• Median CAC Payback: 33 months

• Median S&M % Revenue: 35%

• Median R&D % Revenue: 23%

• Median G&A % Revenue: 14%

Comps Output

Rule of 40 shows rev growth + FCF margin (both LTM and NTM for growth + margins). FCF calculated as Cash Flow from Operations - Capital Expenditures

GM Adjusted Payback is calculated as: (Previous Q S&M) / (Net New ARR in Q x Gross Margin) x 12. It shows the number of months it takes for a SaaS business to pay back its fully burdened CAC on a gross profit basis. Most public companies don’t report net new ARR, so I’m taking an implied ARR metric (quarterly subscription revenue x 4). Net new ARR is simply the ARR of the current quarter, minus the ARR of the previous quarter. Companies that do not disclose subscription rev have been left out of the analysis and are listed as NA.

Sources used in this post include Bloomberg, Pitchbook and company filings

The information presented in this newsletter is the opinion of the author and does not necessarily reflect the view of any other person or entity, including Altimeter Capital Management, LP (”Altimeter”). The information provided is believed to be from reliable sources but no liability is accepted for any inaccuracies. This is for information purposes and should not be construed as an investment recommendation. Past performance is no guarantee of future performance. Altimeter is an investment adviser registered with the U.S. Securities and Exchange Commission. Registration does not imply a certain level of skill or training. Altimeter and its clients trade in public securities and have made and/or may make investments in or investment decisions relating to the companies referenced herein. The views expressed herein are those of the author and not of Altimeter or its clients, which reserve the right to make investment decisions or engage in trading activity that would be (or could be construed as) consistent and/or inconsistent with the views expressed herein.

This post and the information presented are intended for informational purposes only. The views expressed herein are the author’s alone and do not constitute an offer to sell, or a recommendation to purchase, or a solicitation of an offer to buy, any security, nor a recommendation for any investment product or service. While certain information contained herein has been obtained from sources believed to be reliable, neither the author nor any of his employers or their affiliates have independently verified this information, and its accuracy and completeness cannot be guaranteed. Accordingly, no representation or warranty, express or implied, is made as to, and no reliance should be placed on, the fairness, accuracy, timeliness or completeness of this information. The author and all employers and their affiliated persons assume no liability for this information and no obligation to update the information or analysis contained herein in the future.