Sprint retro, eight people, one of them on a laptop speaker. Two side conversations start up while the main one is still going. The team is deciding something I have a clear opinion about, and I have the answer.
I get it out about four minutes after the decision is made. The notes record me as having agreed.
That has happened to me in schools, in offices, and in almost every job I have had since 2010, when I started my career in IT.
Two loads, one symptom
Moving to Ireland made it bigger. I arrived with about seven years of English classes behind me, and English teaching in Brazil leans heavily American, so accents were the first challenge. My first team had around ten people from Ireland, Spain, Argentina, Brazil, France and India.
Vocabulary and grammar were fine. What took years was everything wrapped around the words: the idiom, the reference set, the timing of a joke, who you can interrupt and who you cannot, what a specific tone of "yeah, no, it's grand" is doing in that sentence. No amount of vocabulary shortens that.
So, in a room with four people talking at once, I was paying twice.
The first cost is auditory, and it is well documented. In a survey of autistic adults, background voices caused more difficulty than any other environment tested, and 88% rated following speech with one or two other people talking as fairly challenging or very difficult. Separating two overlapping voices costs me processing that other people are spending on the content of what is being said.
The second cost is cultural, and every immigrant reading this knows it. Somebody makes a reference. Everyone laughs. I have parsed the sentence perfectly and understood nothing, and now I have half a second to decide whether to laugh along.
Both costs produce exactly the same observable behaviour: a quiet engineer in a meeting. From the outside, they are indistinguishable, so they get filed under the same line in your feedback.
I tried to fix it the obvious way, by talking more. Sometimes it worked. Sometimes I said something that landed wrong, people laughed, and the conversation carried on without me. Sometimes the conversation just stopped for a moment, and then restarted somewhere else.
After enough of those, silence starts to look like the correct engineering decision. Staying quiet has a known, bounded cost: I am the quiet one. Speaking has an unbounded one, because I cannot predict what will land badly until after it has. Anyone would run that calculation. Most people running it are not described as lacking soft skills. My yearly 360 reviews described me that way every time: excellent in problem-solving, and communication always listed as the main area to improve.
Diagnosis in a later stage
I got my autism diagnosis at 37. Everything above happened before that, without a framework to hang it on. For most of my career I was not managing a known trait. I was finding meetings expensive and assuming everyone did, and concluding I was worse at a normal thing than other people were.
That is the part that is hard to convey to a manager who has only ever known the diagnosed version of someone. The behaviour was the same for thirty years. Only the explanation is new.
The same trait, two names
Once you look at it this way, most of what gets written down about a neurodivergent engineer is one behaviour with two available labels, and which one you get depends on who is describing you.
| The trait | What it produces | What it gets called |
|---|---|---|
| Hyperfocus | Six hours on one problem, solved at the root | "Hard to reach", "doesn't answer Slack" |
| Needing to actually solve it | Cause found instead of symptom patched | "Scope creep", "can't let it go" |
| Following the written standard | The ADR exists, the contract holds, the linter passes | "Pedantic", "difficult in review" |
Two caveats.
Hyperfocus is not a productivity technique. I cannot summon it on demand, and it does not respect a calendar. Interrupt me four hours into a problem and I lose the whole state I was holding, and rebuilding it takes far longer than the interruption did. Teams want the output and then structure the day so it cannot happen.
And the standards one has a sting in it. I follow the written standard. Most teams run on an unwritten one, and enforce the written one selectively. Being the person who applies the documented rule consistently makes you difficult in a group whose real rule is social.
Why the rehearsed STAR answer still fails
This is the one I would most like hiring managers to sit with.
The advice to a candidate who struggles in interviews is always to prepare. Learn the framework, write your stories out, rehearse them. I have done that thoroughly. I have written STAR cases, refined them, practised them out loud.
Here is the bind. Unprepared, I am disorganised, and I ramble. Prepared, I am robotic and I "lack authenticity". Those are the two available verdicts, and I have received both. Technical depth works the same way: one panel told me I was too technical, another that my answers lacked technical depth.
STAR asks you to compress a messy multi-person situation into a clean arc, attribute the outcome confidently to yourself, recall it in real time, and deliver it while managing eye contact and reading three faces for signs that you are going on too long. Then somebody asks an unscripted follow-up, the script does not cover it, and the derail is worse than having had no script, because now I am recovering from the loss of structure while still performing.
The preparation that rescues a neurotypical candidate is the same preparation that exposes me. From the other side of the table, nobody sees the preparation behind an answer. They hear whether it sounds natural, and they score what they hear.
The frameworks assume one nervous system
Everybody is writing about soft skills right now. Almost none of it says which brain it was written for, which is how you end up with advice that helps one neurotype by doing damage to another.
| Standard advice | Helps | Costs |
|---|---|---|
| "Think out loud, share half-formed ideas" | External processors, a lot of ADHD colleagues | Processing that needs the answer assembled before it is spoken |
| "Send a written pre-read" | People who need time before the room | A dyslexic reader handed three dense pages the night before |
| "Back it up with live numbers" | Most audiences | Anyone doing arithmetic in front of a room, dyscalculia especially |
| "Read the room, match the energy" | Nobody, really. It measures conformity | Paid for by masking, at a price the room never sees |
| "Keep it brief, get to the point" | Busy managers | Accuracy that lived in the qualifier you just cut |
| "Be spontaneous and authentic" | Extroverts | Anyone whose competence depends on preparation |
Read down the "costs" column and the fixes contradict each other. That is the answer to the question in the title. A single soft skills framework cannot serve everyone, because "improve your soft skills" is one normative model of communication with one implied user, and it never declares who that user is.
The obvious rescue is to write a version per neurotype. That fails too, because the categories do not arrive one at a time. In a total population study of five-year-olds in Japan, only 11.5% of the children diagnosed with autism had autism alone; the other 88.5% had at least one co-occurring neurodevelopmental condition. In a Swedish twin sample, children with dyslexia had more than eight times the rate of other neurodevelopmental problems compared with typical readers. To be fair to the other side of the evidence, a recent twin study found that most children with ADHD, dyslexia or dyscalculia had only one of the three. Co-occurrence runs well above chance, but it is not universal.
Well above chance is enough to break the persona approach. Design an intervention for "the autistic engineer" and a meaningful share of your intended audience also has ADHD, dyslexia, or both, with requirements that pull against each other inside one head.
And the layer under that: within autism, the advice that circulates in tech is written about one presentation. Mine. Someone in professional employment, diagnosed late, with a support system and enough language to describe the problem. I can tell you what a retro costs me. I cannot tell you what it costs an autistic person with higher support needs, and if I generalised from myself, I would be reproducing the exact error I am complaining about.
What I would actually change
Four defaults. None of them are accommodations, and none of them require knowing anything about anyone's diagnosis.
- Put the actual decision on the agenda. "Decide between Postgres and DynamoDB for the events table" gives me something to prepare. "Data layer sync" gives me nothing.
- Write down what was decided in the ticket or the doc. If the record lives in people's heads, it cannot be queried by anyone who missed the moment.
- Let contributions after the meeting count the same as contributions during it. The good idea arriving twenty minutes late is still the good idea.
- State the interview format in advance, including whether follow-ups will be scripted. Say what you are testing. If communication under time pressure is a real requirement of the job, test it deliberately and say so. If it is not, stop scoring it by accident.
Every one of those improves the meeting for the whole team, which is the point. The team that does this stops needing a separate conversation about accommodations, because the thing that was being accommodated has already been designed out.
I know exactly what all of this costs me. What I do not know, and what the people writing soft skills advice do not seem to have asked either, is what it costs a dyslexic colleague handed a three-page pre-read, or an ADHD colleague in the twenty-minute meeting with no agenda. If that is you, I would like to hear where the standard advice breaks, especially where it breaks in the opposite direction from mine.
This is Part 3. Part 1 went through the hiring statistics people quote at conferences, and Part 2 covered what Irish employment law requires of employers.
Bruno Souza, Senior Full-Stack Engineer — Dublin
Top comments (0)