The Neurodivergent Developer in the Multiverse

Picture two versions of the same developer. They have the same knowledge, skills and intentions. They attend the same event, receive the same task or walk into the same office. Yet in one version of the story they end the day exhausted and frustrated, while in another they finish with energy left.

That is the multiverse I want to explore. The difference is not that one version tried harder. Often, it is a combination of self-awareness, support from colleagues and managers, and an environment designed with different minds in mind.

Neurodiversity is already part of our teams

Neurodiversity describes the natural variation in how people think, process information, communicate and experience their surroundings. It is often associated with autism, ADHD, dyslexia, dyspraxia and Tourette syndrome, among other profiles. A frequently quoted estimate is that 15 to 20 percent of people are neurodivergent. Treat that as an estimate, but the message is simple: it is not unusual, and some colleagues may not know it about themselves or may choose not to disclose it.

For developers, differences may show up in sensory processing, working memory, planning, switching between tasks or interpreting ambiguous requests. These are not lists of weaknesses. The same person may have strong pattern recognition or deep focus, while finding a seemingly simple activity unusually demanding. If you have met one neurodivergent person, you have met one neurodivergent person.

A spiky profile, not a simple scale

We often imagine capability as a line from low to high. Real people are more like an uneven radar chart: high in some areas, average in others and lower elsewhere. A developer may be excellent at investigating a complex production issue but struggle to follow a long series of spoken instructions in a noisy room. Neurodivergence can make this unevenness more pronounced.

The useful question is therefore not, “Is this person capable?” It is: “Under which conditions can this person use their capabilities well?”

From reflection to strategy

Start by reflecting on your own working profile, without trying to diagnose yourself. Which situations repeatedly drain your energy? When do you do your best work? Then turn what you notice into small experiments. If task switching is a problem, finish or deliberately park one task before starting the next. If every notification is a trigger, use a two-minute pause or do-not-disturb mode. The right strategy is personal, so try something small and adjust it based on what happens.

Four cases across the multiverse

Case 1: Attending a large event

In one universe, a developer attends a large event and must present the takeaways afterwards. Registration is unclear, lunch means navigating a crowd, announcements are hard to hear and the journey home changes. None of this is big on its own, but together it drains the battery.

In another universe, the developer prepares the route and the day beforehand, and breaks are planned. The manager asks for a short summary email instead of a presentation, and the organiser provides clear instructions and a quiet space. Same event, same developer. Uncertainty, sensory load and expectations have simply been managed.

Case 2: A quick introduction to postmortems

In one universe, a developer receives a large set of detailed slides on creating a postmortem, and the postmortem becomes an impossible task to finish. In another, they recognise that it is hard to process and ask a colleague for help. That is not failure, it is an effective strategy.

In a third universe, the process starts with one clear instruction:

Open the incident page and select Create postmortem.

The detailed guidance still exists, but it no longer blocks the first action. This is progressive disclosure for internal documentation, and it helps new joiners and people under pressure just as much.

Case 3: A day in the office

In one universe, there is no plan and no real lunch break, and calls and conversations continue around the desk all day. The developer goes home with a headache. In another, the day has a rhythm: meeting rooms for team rituals, a short walk at lunch, an agreement on when headphones are appropriate and a quiet period before the journey home. The goal is not a silent office, but a mix of focus, collaboration and recovery.

Case 4: The coffee-machine question

A colleague asks a quick question while the developer is getting coffee. By the time they are back at the desk, it is gone from working memory, and the colleague may read the silence as disinterest. In another universe, the developer says, “Please send me a message so I do not forget.” A reminder is not mistrust. It is a communication agreement.

Support exists at three levels

Self. Learn your patterns, anticipate hurdles and test strategies. This should not become an expectation that people solve every environmental problem alone.

Circle. Colleagues and managers can make expectations explicit, put requests in writing and ask what helps. An engineering manager does not need to diagnose anyone, only create the trust for people to explain how they work best.

Organisation. Clear processes, quiet spaces and accessible documentation make work easier for a wider group. This is the difference between equality and equity: equality gives everybody the same thing, while equity recognises that people may need different conditions to contribute.

What engineering teams can do now

Write down decisions and requests.
Separate the first step from the full manual.
Agree on interruption rules for messages, headphones and focus time.
Make expectations concrete: outcome, scope, priority and deadline.
Plan demanding days deliberately, with recovery time.
Offer more than one way to contribute.
Treat reminders as normal tooling.
Ask, do not assume.

Many of these practices are simply good engineering: reduce ambiguity and do not let success depend on hidden assumptions.

One developer, many possible outcomes

The multiverse removes blame. A difficult outcome does not automatically mean someone lacked motivation, competence or care. Sometimes the path contained more friction than others could see. Reflection helps us notice it, strategy helps us respond, and teams can remove the barriers that never needed to be there.

Start small: one recurring situation, one change, kept long enough to learn from it. Support is often what turns a struggle into smooth sailing.