Bugs crushed 0/8
Who runs software teams?

Nobody here can code.

Many software teams are run by managers who can't judge the work. They smile for the camera, and the code pays for it. Here is how that happened, what it costs, and why that era is coming to an end.

Somewhere along the way, looking busy became the job.

01 · How we got here
Part 1 of 3: How we got here
CH 01How we got here · 1990 to 1996

Software used to be a small world.

In the early 90s, a company that needed software didn't build it. It hired a software firm, and engineers ran the whole project.

Then the internet arrived. Every company wanted its own tech team, and tech jobs grew far faster than anything else. Even in one small US state that nobody links with tech, high-tech jobs grew five times faster than jobs overall.

+65%high-tech jobs in 6 years
+12%all jobs in the same 6 years
High-tech jobsAll jobsBoth start at 100 in 1990

Up nextWhen a field grows that fast, it attracts people who come for the money, not the craft.

Data: state employment records, 1998
02 · How we got here
CH 02How we got here · 2007 to 2024

Teams filled up with people who don't build.

New roles grew around the engineers: product managers, scrum masters, product owners, business analysts. In some teams these roles outnumbered the engineers.

Many of the people in them had never built software or been trained to manage it. They moved up anyway, because demand was so high. Google's parent company Alphabet shows the scale of the hiring boom: 11 times more staff in 15 years.

17k to 190kAlphabet staff, 2007 to 2022
First cutsin 2023, after the peak
See the numbers
YearEmployees

Up nextAnd it wasn't only the tech giants. Soon every company wanted to call itself a tech company.

Data: Alphabet annual reports via Statista. Hover a tower to see the year.
03 · How we got here
CH 03How we got here · 1990 to 2025

Everyone became a "tech company".

Look at businesses whose actual product is software. From 2000 to 2015 their number barely moved.

What changed after 2015 was the label. Taxi apps, hotel sites and streaming services all started calling themselves tech companies, and the count of "software" businesses shot up.

6,100 to 6,250software businesses, early 2000s vs 2011 to 2015
14,5002021 to 2025

Each coin is about 500 businesses. The glass ring shows how uncertain each estimate is.

Up nextBut calling yourself a tech company doesn't make you one. Your bank can tell the difference.

Data: estimates from Census Bureau County Business Patterns, IBISWorld and industry reports
04 · How we got here
CH 04How we got here · How banks label companies

Your bank knows what a company really is.

Every card payment carries a four-digit code that says what kind of business took your money. Pay Uber and the code says taxi. Pay Netflix and the code says cable TV.

CodeWhat the bank seesExample
4121Taxis and limousinesUber
4899Cable and pay TVNetflix
5045Computers and softwareSoftware makers
7372Programming and data processingCloud and SaaS

These companies use software to run a taxi, TV or hotel business. Selling software is not what they do.

Click the card to see the next company.

Up nextThat difference changes how seriously a company treats its code.

Data: ISO 18245 merchant category codes, Citibank MCC list
05 · How we got here
CH 05How we got here · Why the label matters

Build for many customers, or only for yourself.

A real software company sells the same code to hundreds of customers running different versions. If the code gets messy, every one of those customers feels it. So these companies have to keep their code clean.

A company that only runs software for itself has one customer: itself. It can get away with messy code for years, and its managers tend to see software as a cost, not as the product. That's where non-technical managers took over.

72 customers on 5 different versions. Hover a dot.

Up nextSo what happens when the people in charge can't see what the code needs?

SHIP

Every shortcut pulls a block from the bottom.

06 · What it costs
Part 2 of 3: What it costs
CH 06What it costs · 1990 to 2025

The invisible work gets cut first.

Features are what software does. Just as important is how well it does it: is it fast, secure, reliable, and easy to change later? Engineers call this non-functional work, and it takes about a quarter of a team's time.

Users never see it, so a manager who can't explain it to their own boss cuts it to ship more features. It works for a while. Then the bill arrives, and it tends to arrive when a boom ends.

20 to 30%of team time that should go to this work
15,900software business failures in 2025, close to the dot-com peak

Up nextEvery cut corner leaves something behind: technical debt.

Data: estimates compiled from Bureau of Labor Statistics and court records
07 · What it costs
CH 07What it costs · Survey of CIOs, 2020

The debt keeps stacking up.

Technical debt is what you owe for every shortcut. Like money debt, it grows. Each shortcut makes the next change slower, until a two-week feature takes months.

Tech leaders know this. Most of them still spend very little fixing it.

Went up60%
Same25%
Went down15%

The tower has 100 blocks, one for each 1% of tech leaders, colored by how much of their budget goes to fixing debt. Only the top 8 spend more than a fifth. Watch the blocks slide out as you scroll.

0-5%6-10%11-20%21-25%26-50%

Up nextLeft alone, the debt spreads into the design of the whole system.

Data: McKinsey, "Tech debt: Reclaiming tech equity"
08 · What it costs
CH 08What it costs · System design

Clean systems turn into spaghetti.

In a healthy system, each part has one job and talks to the others through a few clear connections. You can change one part without breaking the rest.

When design time gets squeezed out of every sprint and decisions come from people who can't see the structure, parts start reaching into each other. Change one thing and three others break.

10 to 20xhigher cost to run and build a spaghetti system

Up nextA lot of this could be caught early, if teams were allowed to experiment first.

Estimate based on 25 years of engineering practice

Change one thing and three others break.

09 · What it costs
CH 09What it costs · Prototypes

Skipping the experiment.

Good teams build two kinds of early versions. A test prototype answers one question, "can this even work?", and then gets thrown away. An MVP is a first version that grows into the real product.

Non-technical managers almost always skip straight to the MVP. So the hard technical problems show up halfway through the build, when fixing them costs the most. Apple built dozens of throwaway prototypes before the first iPod.

Test prototypeMVP
AsksCan we build it?Do people want it?
AfterwardsThrown awayBecomes the product
Finds problemsEarly and cheapLate and expensive

These toys are test prototypes. Click one to try it.

Up nextEven managers with an engineering background can get this wrong.

10 · What it costs
CH 10What it costs · Software vs machines

Software is not a gearbox.

Managers from mechanical or other physical engineering do better than pure business managers, but they often run software like a factory. That doesn't fit.

A gearbox is built once and can keep turning for decades, even if its maker disappears. Software is never finished. It needs constant care, and it dies the day nobody maintains it.

SoftwareMachines
Change speedMinutes to hoursWeeks to months
Cost of a copyAlmost zeroMaterials and tooling
If the maker is goneIt diesIt keeps running

Up nextWithout technical judgement, even picking the right tools becomes a guess.

11 · What it costs
CH 11What it costs · Choosing tools

Chasing the shiny new thing.

Which tools should a team use to build an app? An experienced lead says "it depends on what we need", then tests the options before choosing.

A manager who can't judge the options picks whatever had the best sales pitch or the most buzz, then switches when the next trend arrives. Every switch resets progress. The debt starts before anyone writes a line of code.

Sticking with it: slow, steady progressChasing trends: progress keeps resetting
Chart idea after Rachel Pedersen
12 · What it costs
CH 12What it costs · Learning

Nobody has time to learn.

Software changes every year, so engineers need regular time to learn, about a fifth of their week. A manager who isn't learning themselves rarely makes room for it.

The result is a team that falls behind. Today that looks like engineers writing long hand-coded rules for problems a small trained AI model would solve better and cheaper.

20%of engineering time should go to learning
3 yearsof formal training, and you're still a beginner

Up nextFor years, the boom hid all of these costs. Now the boom is over.

The boom hid everything. Then the music stopped.

13 · Why it is ending
Part 3 of 3: Why it is ending
CH 13Why it's ending · 2020 to 2025

The hiring boom is over.

Software job postings more than doubled during the pandemic, peaked in 2022, then dropped below where they started almost everywhere.

AI makes skilled engineers much more productive, so the support roles around them are the first to go. And AI won't turn a non-technical manager into a technical one. It just helps them make confident mistakes faster.

2.7xpostings at the 2022 peak, vs early 2020 (highest country)
4 of 5countries below their 2020 level by early 2025
AustraliaUSGermanyFranceUK
Data: Indeed job postings via FRED, as charted by The Pragmatic Engineer. February 2020 = 100.
14 · Why it is ending
CH 14Why it's ending · What comes next

Back to teams that understand the work.

The free-snacks, ping-pong-table era is over. We expect software teams to look more like they did around 1998 to 2005: smaller, more technical, and led by people who can read the code.

For companiesPut people who can judge the work in charge of it.
For managersLearn the craft, or hand technical decisions to someone who has it.
For engineersLevel up with AI and machine learning. Average won't be enough.