What Is the Curse of Knowledge in ITSM?
The curse of knowledge is a cognitive bias that causes people with specialized knowledge to assume others share the same understanding.
In ITSM, this means support staff often communicate as though users already understand systems, terminology, and technical context.
They do not.
The bias makes it difficult for experts to remember what it felt like to not know something.
Experts forget the moment before they knew. That forgetting is where user frustration begins.
That gap creates real problems.
Incident updates become unclear.
Instructions skip critical steps.
Users are left confused about what action to take.
The result is avoidable frustration, repeated back-and-forth, and slower resolution times across service desk operations.
The term was coined in 1989 by Colin Camerer, George Loewenstein, and Martin Weber in a Journal of Political Economy article aimed at countering assumptions that better-informed agents can accurately anticipate the judgments of less-informed ones.
Communication and decision making suffer when expertise creates blind spots that prevent recognizing what others do not know.
Organizations implementing ITSM frameworks such as ITIL guidelines can mitigate these issues by standardizing communication and workflows.
Why Technical Expertise Makes You a Worse Communicator?
Counterintuitively, the more someone knows about a technical subject, the harder it becomes for them to explain it clearly to someone who does not.
Expertise rewires how a person sees information.
Steps that once required effort become automatic.
Context that once needed explanation feels obvious.
This creates three specific problems in ITSM communication:
- Invisible gaps: Experts no longer notice what they are skipping.
- Compressed language: Jargon replaces plain words without realizing it.
- System-focused messages: Explanations describe how something works, not what the user should do next.
Technical depth does not improve clarity.
It often defeats it.
When ITSM advantages are not explained in business terms, adoption decreases and use becomes confusing.
Teams may prefer parallel channels like Slack or email instead of the ITSM platform, creating blind spots in reporting that make underlying patterns invisible to those who need them most.
Integrations can help by creating a centralized source that keeps data consistent and visible across systems.
The ITSM Moments Where the Curse of Knowledge Hits Hardest
Knowing where the curse of knowledge strikes most often is the first step toward preventing it.
Five ITSM areas carry the highest risk:
- Incident update handoffs – Updates sequence by investigation logic, not user impact, leaving stakeholders confused.
- Ticket triage – Internal category names obscure meaning for requesters who only understand symptoms.
- Knowledge base articles – Writers omit prerequisites they have already internalized.
- Service catalog items – Request names use IT terminology instead of outcome-focused language.
- Change and outage notices – Technical sequencing replaces plain-language impact statements.
Each area shares one failure pattern: experts write for themselves instead of their audience. When one brain encodes information, many minds decode that same information differently, meaning an ITSM message that feels crystal clear to a technician can land as noise to an end user. As expertise deepens, recalling “not knowing” becomes increasingly difficult, which is precisely the mechanism that transforms knowledgeable ITSM professionals into unintentionally poor communicators. Organizations should align communications with measurable service delivery goals to ensure clarity and business relevance.
How to Write ITSM Updates Anyone Can Understand
Mapping the five high-risk ITSM areas reveals a shared root cause: experts write for themselves instead of their audience. A reliable fix is a consistent update structure that answers five questions:
- What happened?
- Who is affected?
- What is being done?
- What should the user do now?
- When is the next update?
Lead with outcomes, not systems.
Write “Your login access is restored” before explaining why it failed. Use plain language, short sentences, and active voice. Keep paragraphs under four sentences.
Structure removes guesswork and prevents repeated follow-up requests from confused stakeholders. Title updates using action-oriented verbs to signal outcomes and help users immediately understand what the communication requires of them.
Choosing the right channel matters as much as choosing the right words, since channel selection should match the urgency and complexity of the issue being communicated. Effective communications also support scalable architectures by enabling seamless data flow between tools.
How to Build a Plain-Language Standard That Actually Sticks
Writing a plain-language standard that actually sticks requires defining what “plain language” means before a single word of the standard is drafted.
Plain language is content readers can understand on the first read and immediately use. That definition must anchor every decision that follows.
Before writing begins, teams should:
Before writing begins, do the groundwork — research your audience, define scope, and map every input and output.
- Research the actual audience
- Identify which artifacts the standard covers
- Map inputs, outputs, and escalation rules
Build the standard around real work patterns, not ideal ones. Validate every step with the analysts who perform the work daily.
A standard built on theory rarely survives contact with actual operations. Store SOPs inside the service desk or its knowledge base, where analysts already work, so the standard remains accessible during live operations rather than buried in a shared drive. Many teams already have relevant content scattered across separate tools — runbooks in Confluence, escalation paths known only to senior staff, on-call rotations in PagerDuty — and the plain-language standard should consolidate those fragmented knowledge sources into one findable location with clear ownership at every step. A good standard should also reference incident management best practices so teams can align wording with operational processes.
