Notes · from the field

The pain moves, and the budget follows it.

Pain in a company doesn't stay where it is produced. It travels along the path of least resistance, toward the team that can be asked to absorb it without saying no. By the time it has a name, it has usually moved twice.

The money follows the pain, which means it follows it to the wrong address.

A decision that keeps getting made badly shows up first as a slipped launch, then as an overloaded team, then as a hiring request, then as a "culture issue". Each stop gets its own budget line, so there's a tool here, a senior hire there, a reorg, a consultant. Every one of them is a sensible response to the pain where it is being felt, and none of them touches the place where it is being made.

Three things keep pushing it downstream. The loops that would tell the company about itself get cut for cost or speed, so it loses the ability to feel its own pain where it starts. The people closest to the pain learn to absorb it, their absorbing becomes invisible work, and the invisible work becomes a job title. And attention follows money: whatever a team is paid to see, it sees, and the rest drops out of view.

That second one is the expensive one. Somewhere in most companies there is a person who has become load-bearing for work the system should be able to carry. Ask who would cause the most damage by disappearing for a week, and everybody knows the name. The budget treats that person as a strength. Structurally, they are the symptom with a job title.

So when we look at a company, we read the budget backwards: where the money goes to treat something, what that something is a symptom of, and what would still be hard if the loudest bottleneck disappeared tomorrow. Then we walk back along the line, stop by stop, to the decision that is producing it.

The budget is a very good map of where the pain ended up. It is almost never a map of where it started.

All notes

Tell us what keeps getting stuck.

Tell us the problem, who it hits and what happens when it goes wrong, and we'll tell you whether there's a useful first project.