Summary of Key Points
This article discusses the common cognitive conflict in the workplace, where people say, "This isn't complicated at all," and reveals the root cause of different perceptions on the same task by managers and executors: both parties are looking at the issue from different abstract levels. Managers see a simplified goal (such as "user refund"), while executors face numerous real-world exceptions, boundaries, and risks (such as network timeouts during refunds, duplicate submissions, changes in permissions, etc.). The article also analyzes the linguistic, organizational, and resource factors behind this conflict and points out that this cognitive bias will become more prominent in the AI era, emphasizing the importance of acknowledging the complexity of reality.
1. Difference in Perspective: Leaders See a "Line," Executors Face a "Web"
The task in the eyes of leaders is often a simplified ideal process: for example, "User submits a refund request → System reviews → Refund is successful"—a straightforward sequence of steps. However, executors have to deal with all the "unexpectedities" that arise outside this line: What if the user doesn't provide complete information? What if the network fails and the transaction isn't completed? What if the third-party payment interface doesn't respond and requires retrying? What if the same user submits a refund twice, leading to duplicate payments? These types of issues, which represent a complex web of possibilities, account for 80% of an executor's time.
For example, creating a demo version of a refund process may take only three days—just to ensure it works once. But deploying it in a real environment can take a month because all potential exceptions must be considered to ensure the system "works without errors," not just runs.
2. The "Deceptive Power" of Language: Natural Language Conceals Complexity
When we communicate requirements using natural language, we automatically omit many details. For instance, saying "Add an automatic refund feature" is quick to say, but it hides a multitude of issues: Who has the authority to initiate an automatic refund? How much does the refund amount need to be before manual review is required? Can a refund still be processed if the user has already received the product? How should failed refunds be communicated to the user? These details are not deliberately made complicated by executors; they simply exist and were not mentioned.
It's like asking someone to "buy me a coffee" without specifying whether you want it iced or hot, whether to add sugar, or which store to use. The simpler the requirement description, the more details the executor needs to clarify, which is why conflicts arise: Those who make the requests think, "Why are you making so many issues?" and executors think, "You didn't provide clear instructions."
3. The "Compression Filter" of Organizations: The Higher You Go, the Less You See
In large companies, information is compressed at each level: Frontline employees handle 10 exceptions daily; technical leaders summarize them into 3 risks; department managers reduce these to 1 issue; by the time it reaches the CEO, it might be reduced to "The project progress is a bit slow." This compression is necessary (the CEO can't manage every interface timeout), but it can lead executives to mistakenly believe that "there are no problems."
It's similar to using an elevator: You press a button and you arrive on the floor without thinking about the braking system, sensors, or safety redundancies behind it. Excellent teams handle complexity at the lower levels, making it seem like everything is normal for executives. However, when key personnel leave, executives suddenly realize how complex the system actually is.
4. The Game of Resources: "Simplicity" Is About Controlling Time and Money
Sometimes leaders claim something is not complicated to control resources. If they admit complexity, it would mean adding more staff, budgeting more, or extending timelines. However, the omitted costs don't disappear; they are just shifted elsewhere. For example, compressing testing time might lead to more manual work to fix issues after deployment; poor monitoring can result in greater losses due to delayed issue detection.
It's like skipping waterproofing during a renovation to save money. It seems fine at the time, but half a year later, fixing the leaks can cost ten times more than the initial investment.
5. New Traps in the AI Era: "Easy to Build, Difficult to Make Reliable"
AI makes it extremely easy to quickly create prototypes. What used to take weeks can now be done in hours with AI. But this can lead to the misconception that the entire system is simple. In reality, AI only solves the problem of "being able to build" and not the problem of "making it reliable." For instance, while AI can process orders, it doesn't understand which orders cannot be processed, how to recover from errors, or how to stop issues with third-party systems.
Moreover, AI executes tasks very quickly. If an employee makes 10 mistakes a day, AI might make 1,000 mistakes in a minute across multiple systems. In the AI era, it's not about whether something can be done, but whether the risks associated with it can be controlled—such as knowing when AI must stop, who will take responsibility, and how to determine fault.
Conclusion
The statement "This isn't complicated" is not wrong in itself, but we need to understand that simpleness refers to the goal, while complexity lies in reality. Next time you hear this, don't argue immediately. Instead, ask yourself: "Are we seeing the ideal simplicity, or the complexity that has been hidden?" After all, true maturity does not lie in denying complexity but in turning it into a system that can be managed effectively.