What does it mean that decomposition reveals hidden complexity?

You do not understand something until you can decompose it — and the act of decomposition will show you exactly where your understanding breaks down.

Example: An engineering lead says 'we need to migrate to microservices.' Everyone nods. Then you ask: which services? What are the boundaries? How do they communicate? What happens to shared state? Within ten minutes, the room discovers that nobody agrees on what 'migrate to microservices' actually means. The complexity was always there — decomposition made it visible.

Try this: Pick one thing you believe you understand well — a process at work, a technology you use daily, a decision you recently made. Set a 10-minute timer and write a step-by-step decomposition: break it into every sub-part, dependency, and assumption you can identify. When you hit a step you cannot explain clearly, mark it with a question mark. Count the question marks. That number is the gap between your felt understanding and your actual understanding.