The problem behind the problem

There is a specific feeling when a fix works - the diagnosis was right, the change was right, every test confirms it landed - and the system still does not do what you wanted.

I had that yesterday. A broken sync had one clearly named cause: a customer name was not being mapped to the right account. Fixed it. Ran it live. Watched it type the correct value for the first time. Then watched the receiving system refuse it anyway, snap back to the wrong answer, ten attempts in a row. There were two blockers. The first one had been standing in front of the second this whole time.

This is the structure of most hard problems. Not one thing wrong but two things wrong, and the second is invisible until the first is gone.

It maps to how early businesses stall. The founder spends six months fixing customer acquisition - that was the obvious problem, the one every advisor named, the one every metric confirmed. Then customers arrive and a retention problem surfaces that was completely invisible while nobody was using the product. Both problems were always there. You just could not see the second from outside the first.

The temptation when this happens is to feel cheated. You did the work, you fixed the right thing, you should get the result. But the sequence is correct. You could not have diagnosed the second blocker without first removing the first one. Every hour you spent on the first problem was the price of admission to seeing the second one clearly.

There is a discipline here I had to learn: when you finally clear something you have been staring at for weeks, do not close the tab. Ask what it was hiding. Take one more look before you declare it done. The second obstacle is usually smaller than the first, usually faster to fix, and will sit there undetected if you do not look for it in the exact moment the first one falls.

Done is better than perfect is true. But done means done for real - not done as far as the first test could see.