The single most common source of friction between managers and neurodivergent engineers is not performance — it is communication. Specifically, it is the gap between what the manager said and what they meant.
The Implicit Communication Problem
Neurotypical communication is saturated with implication, subtext, and social softening. Managers learn to deliver feedback and instructions in ways that preserve social harmony — hedging, softening, and embedding the real message in layers of politeness. This works well when both parties share the same implicit social code. It fails completely when one party processes language literally.
Consider this exchange:
Manager (intending urgency): "Hey, when you get a chance, it might be worth taking a look at the login page. No rush, just something to keep in mind."
Neurodivergent Engineer (processing literally): This is optional and low priority. I will address it after my current tasks.
Manager (three days later): "Why hasn't the login page been fixed?"
The engineer did not fail to perform. The manager failed to communicate. The instruction contained no deadline, no priority signal, and an explicit "no rush" qualifier. The engineer followed the instruction as given.
The Explicit Communication Protocol
Effective communication with neurodivergent engineers — and frankly, with all engineers — requires stripping away the social softening and being explicit about what you actually need.
Unclear: "We should probably think about the login page soon if you have bandwidth."
Clear: "I need you to refactor the login page authentication flow. Priority: high. Deadline: Thursday at 2 PM. The specific issue is that session tokens are not being invalidated on logout. Is this timeline feasible for you?"
The clear version specifies: what (refactor login page), why (session token bug), when (Thursday 2 PM), and priority (high). It also asks for confirmation, which surfaces blockers before they become missed deadlines.
Feedback Without the Sandwich
The "feedback sandwich" — compliment, critique, compliment — is a common management technique designed to soften criticism. For neurodivergent engineers, it is actively harmful. The structure buries the actual feedback between social noise, making it genuinely unclear what the important message is.
Sandwich (confusing): "Your code quality is really impressive, and I love the creativity you bring to the team. I did notice your commit messages have been a bit short lately, but honestly your technical contributions more than make up for it. Keep up the great work!"
Direct (clear): "Your code quality is excellent — no issues there. Your commit messages are too short; reviewers can't understand the context of your changes. Here is an example of a well-written commit message: [example]. Please use this format going forward. Do you have any questions about what's expected?"
The direct version is not unkind. It is respectful — it treats the engineer as a professional who can handle clear information and act on it. The sandwich version is condescending in a different way: it assumes the engineer needs to be emotionally managed rather than professionally informed.
Written Confirmation
For important instructions, follow up verbal conversations with a written summary. "As discussed: you will refactor the login page auth flow by Thursday 2 PM. Let me know if anything blocks you." This is not micromanagement. It is a shared reference point that eliminates the ambiguity that causes most miscommunication.
A common leadership interview question is: "Describe your communication style as a manager." Candidates who mention adapting communication style to the individual — including being explicit and literal with engineers who prefer direct communication — demonstrate emotional intelligence and practical management skill. Mentioning that you follow up verbal instructions with written summaries signals operational rigor.