The Empathy Bottleneck
Why Brilliant Engineers Fail at Support
These years, I’ve been leading a platform engineering organization that serves our entire product engineering team. I have a bunch of incredibly strong senior and principal engineers—the kind of creators and system thinkers who can crack the hardest architectural problems. Greenfield, brownfield, monolith, distributed architecture, old languages - nothing is a problem for them.
Does this mean we have no challenges? Well… I do have many of them, and the hardest one is not necessarily related to technology. It has been support communication.
The symptoms are frustratingly common. Sometimes, our stakeholders actively avoid asking us for help, choosing instead to struggle for days figuring things out on their own. Other times, when they do escalate, the responses from the most senior folks in my group are perceived as disrespectful or offensive. Meanwhile, my teams come to me legitimately pissed off: “No one reads the documentation. People refuse to use our golden paths.”
What should be a 30-minute collaborative fix frequently stretches into a half-day, zero-value discussion.
It’s unbelievably frustrating when the majority of problems escalated directly to you are about your strongest team members seen as the assholes…
When you manage a platform that other engineers rely on, it is easy to view this friction as a personality clash. But it isn’t. What looks like a localized behavioral problem is actually a predictable system failure—one that has been heavily documented by behavioral economists and cognitive scientists.
The Science of the Gap
When a wide knowledge gap exists between high performers and average system users, two intersecting psychological phenomena take over the floor.
1. The Curse of Knowledge
Your principal engineers are not necessarily lacking empathy; they are battling a documented cognitive bias. Coined by economists Camerer, Loewenstein, and Weber in 1989, the Curse of Knowledge occurs when an expert loses the ability to reconstruct a novice’s state of mind.
Once an engineer internalizes complex system architecture, their brain groups discrete steps into single chunks of intuition. When a product developer asks a basic question, the expert literally cannot remember what it was like to not know the answer. They perceive the question as a lack of effort—hence the complaints about reading documentation—completely blind to the fact that the novice lacks the foundational context to even understand the docs.
2. The Collapse of Learner Safety
The reason your stakeholders hide and struggle for days is a textbook symptom of low psychological safety. In organizational behavior, researcher Timothy Clark maps this as a lack of Learner Safety.
A junior developer constantly weighs the risk of speaking up against the expected reaction. If previous basic questions were met with a sigh, a RTFM link, or a highly technical rant, they calculate that the social cost of asking is too high. So, they stop asking.
They guess, they break things, or they sit blocked.
The Question API Framework
Telling your senior engineers to “be nicer” or your stakeholders to “be braver” fails because it relies on ad-hoc emotional energy. Instead, treat communication like a technical system by implementing a Question API.
A Question API is a strict operational guardrail. When a developer needs help from the platform team, they cannot just drop a “this is broken” message in Slack. They must pass their request through a structured template:
The Objective: What I am trying to achieve.
The Attempts: What I have already tried (including links to docs referenced).
The Blocker: Where exactly I am stuck.
This framework solves both sides of the equation. It forces the individual to do the pre-work, which reduces their shame and gives them a predictable checklist. Simultaneously, it gives the senior engineer a highly specific technical constraint to solve. If a request comes in without using the API, the senior engineer is empowered to reject the interruption gracefully: “Please format this using our agreed format: Objective-Attempts-Blocker so I can help you efficiently.”
It protects the expert’s cognitive load.
Structuring Senior-to-Junior Mentorship
To bridge the gap further, you must rely on the Cognitive Apprenticeship Framework (CAF). Developed by cognitive scientists in 1989, it addresses the reality that knowledge work hides the most important steps inside the expert’s head. You have to force the expert to make their thinking visible.
Here are three empirical protocols to enforce:
The “Think-Aloud” Protocol: When helping a blocked developer, the senior is forbidden from simply fixing the code or pointing to the solution. They must narrate their internal diagnostic monologue out loud. Novices cannot learn from watching an expert solve a problem; they must observe the mental model of how the expert isolates the issue.
The 1-3 Rule for PR Reviews: Presenting a junior developer with 20 architectural corrections simultaneously halts knowledge retention and triggers defensiveness. A Principal Engineer should be constrained to leaving 1 to 3 primary pieces of structural feedback at once. Let automated CI/CD pipelines and AI code-reviewers handle the pedantic baseline. Reserve expensive senior cognitive energy for system-design flaws.
The SBI Feedback Constraint: Require seniors to format critical feedback using the Situation-Behavior-Impact model. It forces the expert to translate their frustration into objective data. (e.g., “In the database migration PR [Situation], you used a nested loop [Behavior], which will cause an N+1 query issue under load [Impact].”)
Will This Solve All Problems and Frustrations?
The candid answer is no. These frameworks will not cure human nature, nor will they permanently eliminate a Principal Engineer’s desire for speed or a junior developer’s imposter syndrome.
Expecting a communication framework to permanently solve human frustration is like expecting a perfect CI/CD pipeline to permanently solve the existence of software bugs.
Instead, view these protocols as the SLAs (Service Level Agreements) for your team’s interactions. They don’t prevent the friction entirely; they manage the blast radius. By replacing ad-hoc empathy with rigid, predictable communication APIs, you lower the failure rate of those interactions to a manageable level. The frustration shifts from “this person is annoying” to “this person didn’t follow the process.”
The Ultimate Metric: Time-to-Question
You measure the success of these interventions exactly how you measure the health of any system: by tracking throughput and bottlenecks. Specifically, you must track Developer Experience (DevEx) through the Time-to-Question metric.
When Learner Safety is low, a developer will burn days spinning their wheels silently. When safety is high, they hit a wall, gather context, and ask for help immediately.
My own hint: whenever I hire a junior engineer, I give them this exact advice for their day-to-day work: If you have a problem that seems like a blocker, spend 1 hour on it. No more, no less. If you haven’t moved in that hour, do not wait—escalate to peers, experts, or managers.
Track this in your 1:1s. Ask your team: “Think of the last time you were completely blocked. How much time passed before you asked a senior engineer for help?” When that answer consistently drops to one hour, and those questions flow cleanly through your Question API, you will know your platform team is finally functioning as a true force multiplier.