Somebody Has to Do the Hard Part
Tesler's Law and the real work of enterprise design
Larry Tesler worked at Xerox PARC, Apple, and Amazon. He spent his career on one simple idea: every app has a hard part that will not go away. The only question is who does the work. Not whether. Who.
He put a number on it. Say you cut one step from a job that a million people do. You just saved a million small moments of effort. It costs your team one engineer for one week. That trade is almost always worth it. It almost never gets made. The engineer's week shows up on a plan. The million tiny moments do not.
Every application has an inherent amount of irreducible complexity. The only question is who will have to deal with it: the user, the application developer, or the platform developer.
Tesler worked this out while at Xerox PARC in the mid-1980s, and it has a second name that explains it better: the waterbed theory. Press a waterbed down in one spot and it bulges up somewhere else. You never removed the water. You moved it. Complexity behaves the same way. His own framing was blunt. There are far more users than developers, so a week of the team's pain is worth a huge amount of saved user pain. And he chose one word on purpose. Irreducible. He meant the complexity you cannot delete, only relocate.
Where enterprise design goes wrong
Business software fails in the same way over and over. The work really is complicated: tax rules, medical steps, who is allowed to see what. Instead of taking that weight off you, the screen dumps all of it in your lap. Every box in the database becomes a box on the form. The screen turns into a photo of the database. That is the one thing it should never be.
Think of onions. Someone has to chop them. Either you chop them, or the shop sells them already chopped. The chopping never vanishes. It just moves to whoever is willing to pay for it. Software works the same way. The hard part is the onions. You are deciding who holds the knife.
The excuse is always the same: our users are experts, they want power. That is half true, and it is the wrong half. Experts want control over the choices that need their skill. They do not want to type in forty things the system already knows. It is like a company asking for your address on a form when they mailed you the letter. Being asked feels wrong, because it means the software does not understand the job.
- One form box for every database column
- Raw codes and ID numbers on show
- Errors only after you hit submit
- Boxes ordered by the table, not the task
- You are the glue holding it together
- A box appears only when a human must decide
- Codes turned into names, links followed for you
- Errors flagged as you type, before you commit
- Order follows the job, common path first
- The software is the glue
| Who does the work | What it costs to build | What it buys the user |
|---|---|---|
| User | Almost nothing up front | Slow work, mistakes, training, quiet churn |
| Interface | Design time: defaults, staged options, checks | An easy path that grows with skill |
| Platform | The most engineering: guessing and working out | Work that disappears, if you can still check it |
Where the complexity actually goes
Moving complexity is not the same as deleting it, and every place it can land sends a bill to someone real. There are three landing spots. It helps to name the person who pays before you decide to move it.
Push it down to the platform and it lands on an engineer. Someone has to write the code that guesses and fills and checks, and then keep it alive for years. That is a maintenance cost, and it shows up later as pages at three in the morning, as changes that get slower because the smart code is fragile, and as a system only one person on the team understands. Absorbed complexity is not free. It is a debt the team pays in small instalments, forever.
Push it onto the user badly and it lands on a support team. Every confusing form becomes a ticket, a training session, a phone call, and a quiet fraction of people who give up and leave. In enterprise software the support cost of one bad screen usually dwarfs the engineering hour that would have fixed it. The user's pain does not vanish when you ignore it. It reappears further down the corridor as a cost centre nobody connects back to the design.
Push it into automation and it can land on infrastructure. Working things out for the user often means more computing, more storage, and more services to run and watch. A model that fills the form for you has a bill measured in compute and a fresh set of failure modes to monitor. The complexity turned into an operations cost. Someone still pays. It just wears a different uniform.
| Where it lands | Who pays | How the bill arrives |
|---|---|---|
| The platform code | An engineer, for years | Night pages, slower changes, one-person systems |
| The user | A support team | Tickets, training, calls, quiet churn |
| The automation | Infrastructure | Compute, storage, new failure modes to watch |
So the platform should absorb it is not a free win. It is a choice about who pays: the engineer in maintenance, the support team in tickets, or the infrastructure in running cost. The skill is picking the cheapest payer for the value at stake, with eyes open, not pretending the cost went away because you can no longer see it.
The three moves that actually work
- 01Work it out before you ask. For every box on a form, ask how often the right answer is already knowable. From the person's role, the last record, the company's rules, today's date. If it is right more than seven times in ten, fill it in for them and let them edit it. Do not ask.
- 02Show things in stages, but be honest. Hiding advanced options only works if the simple path really finishes the job. If people must open the advanced part to succeed, you have not made it simpler. You added a step and hid the instructions.
- 03Sort by how often, not how important. The thing people do every hour and the thing they do once a year should not fight for the same space. Most dashboards are laid out like an org chart, not like the actual work. That is why the button everyone needs is buried in a menu.
Sometimes the right move is to delete it
There is an honest objection to all of this. Tesler's law can become an excuse. Someone has to deal with it is true, but it can quietly justify never simplifying at all. If you decide up front that the complexity is fixed, you stop asking the better question. Does this part need to exist.
Fred Brooks drew the line that matters. In his 1986 essay No Silver Bullet he split complexity into two kinds. Essential complexity is baked into the problem itself. Filing a tax return really is complicated, and no clever interface can delete the tax code. Accidental complexity is the mess we piled on top: the extra step, the field nobody reads, the feature one customer asked for in 2019 and no one has touched since. Tesler's law only covers the first kind. Remember, he chose the word irreducible.
So before you move complexity, prove it is essential. Half the time the honest fix is not to relocate the hard part. It is to cut it. Delete the feature. Drop the option nobody picks. Kill the field the system does not truly need. Moving accidental complexity down to the platform just buries junk in a more expensive place, and now an engineer maintains that junk forever. The waterbed only conserves water you actually meant to keep.
My rule now runs in that order. First ask if the complexity is essential. If it is not, delete it and stop there. Only what survives that cut has earned the harder argument about who should carry it. Skip the first step and you spend real engineering moving weight that should never have been on the scale.
Too simple is also a trap
The opposite mistake is real, and I have made it. You smooth an expert tool until it feels lovely, ship it, and find out the people who live in it eight hours a day now need three screens to do what one packed table did before. A busy screen is not clutter when the job is comparing things. A trading screen, an air traffic display, a code editor: overwhelming to a beginner, perfectly tuned for the person who actually uses it.
Edward Tufte made this point well. What matters is not how much is on the screen. It is how much of what is on the screen is real information. A packed screen of useful data beats a bare screen of pretty summaries. Expert users will always want the first one.
Where AI fits in
Language models, the AI behind chatbots, are the best tool we have ever had for that bottom row: pushing the hard part down into the platform. A model can turn one sentence into forty correctly filled boxes. That is a real Tesler win. The skill needed drops, but the power stays.
But this only holds if you can check the result. If the model fills forty boxes and you cannot see, confirm, or fix what it picked, you have not taken the hard part away. You have hidden it. It will come back as a disaster at the worst moment. Work that is truly absorbed is invisible until you look for it. Work that is hidden is invisible until it breaks.