What Happened

A Juejin article identifies a common failure mode among technical professionals: the stronger your problem-solving ability, the harder it becomes to explain that problem to non-technical stakeholders. The author calls this the "curse of knowledge" — when a developer is deep in context, they start explanations from implementation details rather than outcomes. The article proposes three structural templates to fix this across three common workplace scenarios.

Why It Matters

For indie developers and SME engineering teams, poor communication directly costs money. A developer who cannot explain a three-day API timeline to a product manager creates conflict, delays approvals, and loses credibility. The article provides three concrete frameworks:

  • CBI Model for incident reports (Conclusion → Background → Impact): Lead with the resolution status, then explain cause in three sentences, then state business impact and preventive actions.
  • Translator Model for cross-department talks (Analogy → Pain Point → Solution): Map technical concepts to everyday objects before explaining consequences and fixes.
  • 5W1H Framework for technical proposals: Start with Why (business pain), then What (measurable targets and explicit out-of-scope items), then How (macro architecture only, 3–5 diagrams), then Alternative (one-sentence rationale for technology choices), then Risk and Cost (system impact, machine costs, timeline).

The underlying principle across all three: assume your audience is a smart person with zero context, not a junior engineer who shares your mental model.

Asia-Pacific Angle

Chinese and Southeast Asian developers going global face a compounded version of this problem. When pitching to international investors, enterprise clients, or open-source communities in English, the default technical-first communication style common in Chinese engineering culture creates an additional barrier. Applying the CBI model in English-language incident postmortems, or using the 5W1H framework when writing RFC documents for GitHub projects, directly increases the chance of adoption and collaboration. Developers building SaaS products for markets like Singapore, Japan, or Australia should note that business stakeholders in those markets have even lower tolerance for unexplained technical jargon than domestic Chinese counterparts.

Action Item This Week

Take your next technical proposal or status update and rewrite only the first paragraph using the CBI model: one sentence stating the current status or conclusion, two to three sentences of background, one sentence on business impact and next action. Share it with a non-technical colleague and ask if they understand the situation without asking follow-up questions.