This post isn't about infrastructure. There's no YAML, no pipeline, no architecture diagram. This is about the stuff that doesn't get written in runbooks - the actual experience of doing this job when your brain processes text differently and your management doesn't know, doesn't ask, or doesn't care.

I'm dyslexic. I've been doing DevOps for years. And I'm writing this because I don't think enough people in this industry talk honestly about what that combination actually looks like day to day.

What DevOps looks like from the inside

People outside the field imagine DevOps as someone typing commands into a terminal and watching green text scroll by. And sure, there's some of that. But the job is overwhelmingly text-heavy in ways that don't get acknowledged: reading documentation, writing runbooks, scanning logs for anomalies in walls of output, parsing dense YAML configs, writing post-mortems, responding to Slack threads, reviewing PRs, writing tickets, reading tickets, and then reading the same ticket again because someone added a comment with context that completely changes the scope of the work.

For someone with dyslexia, that's not a minor inconvenience - it's the core of the job, and it takes more energy than most people around you realise. Not because you can't do it. You can and you do. But it costs more. Every day.

The management problem

Here's something I've seen in almost every team I've been part of: management measures output in ways that are invisible to anyone who doesn't process text the same way the majority does. Typos in a Slack message become a proxy for professionalism. A PR description that took twice as long to write as the code itself gets scanned for five seconds and approved or dismissed. A post-mortem that took hours to structure, re-read, and re-structure gets marked up for grammar and sent back.

Nobody ever said to me directly "you have a typo, you're not taking this seriously." But I've felt the version of that message in a dozen subtle ways. A tone in a review. A meeting where someone rewrites something I wrote in front of the whole group. Being passed over for tasks that involve external stakeholders. Small things, individually dismissible. Cumulatively, exhausting.

The gap isn't ability. The gap is that the people evaluating you have no mental model for what it takes to do what you just did.

Things I've actually seen

I want to be specific here, because vague complaints don't help anyone. These are real patterns I've encountered:

Verbal-only instructions with no follow-up. A manager explains a task in a meeting with no ticket, no doc, no written summary. For a lot of people that's fine - they'll just remember it or jot it down. For me, by the time I've finished processing what was said and thinking through the implications, half the detail is gone. If I ask for it in writing, I've occasionally been met with mild surprise, as if the ask itself signals something about my capability. It doesn't. It signals that I know how I work.

Treating documentation velocity as a performance metric. I've been in environments where the speed at which you produce written work is treated as a direct signal of how productive you are. Slow writer equals slow worker. That's not how it works. The doc I spent four hours on, re-reading every paragraph three times before sending, is probably more accurate and more useful than one that was written in forty minutes and never re-checked. But the four hours is visible. The quality difference often isn't.

Mistakes that aren't distinguished from carelessness. A transposed variable name in a runbook, a wrong date in a post-mortem, a missed word in a Slack message - these get read as not caring. I care more about the accuracy of what I write than most people in the room. That's exactly why catching errors is so hard for me: when you've read the same line six times, your brain fills in what should be there rather than what is. That's not laziness. It's literally how dyslexia works.

Performance reviews that read like copy-editing notes. I've had feedback in reviews that spent more time on the surface of my written communication than on the actual outcomes. The system that I kept running, the incidents I handled, the improvements I shipped - all of that existed in the same review alongside "could improve written communication." It's demoralising in a specific way that's hard to explain to someone who hasn't experienced it.

What nobody tells you about compensating

You get very good at compensating. You build systems: templates for every recurring document, spell-check and grammar tools running constantly, re-reading things out loud before sending, writing long-form in a separate doc and then cutting it down, using voice-to-text for first drafts. You get faster, more accurate, better at catching your own patterns. And none of that is visible either, because the compensation is the part that works.

What is visible is when the compensation fails. And when it does, the narrative is already written for you.

What actually helps

I don't want this to just be a list of grievances, so I'll say what's actually made a difference when I've been lucky enough to encounter it:

Managers who default to writing things down. Not because they were accommodating me specifically - just because it was their habit. A Slack message after every meeting with the actions and owners. Tickets before work starts. A summary at the end of a long thread. That costs them almost nothing and it means I'm working from the same ground truth as everyone else.

Review cultures where content is separated from presentation. "The approach here is solid, the description needs a pass" is useful feedback. It tells me the thinking was right, the surface needs work. "This isn't clear" with no further context doesn't help me fix anything.

Colleagues who ask what I need rather than assuming. That sounds obvious but it's rare. Most accommodations in tech are either formal and slow-moving or don't exist at all. The informal version - a teammate who just asks "do you want me to do a quick proofread before this goes out?" - is worth more than any HR process I've navigated.

Where I actually work well

Dyslexia isn't just a deficit. I want to be clear about that because it's easy to read everything above and conclude this is a story about struggle. It is, partly. But it's also a story about a brain that works differently, and that difference has real advantages in this field.

I think and communicate better verbally than in writing. Put me in a room and talk through a problem and I'm fast, precise, and useful. I can hold architectural concepts in my head and explain them out loud in a way that lands - no notes, no slides. That's not a consolation prize. In incident calls, in design discussions, in the moment when something is breaking and people need clarity, verbal processing is exactly what's needed.

Visual and spatial tools are where I do my best thinking. Give me a whiteboard, a diagram, a flow I can trace with my finger or move around on a screen, and I'm in my element. Architecture diagrams, sequence flows, dependency graphs - I can read those faster and more accurately than a page of prose. I can spot problems in a system diagram that I'd miss in a written description of the same system. When teams invest in visual documentation, I contribute more, faster, and with more confidence. That's not a workaround. That's just how I process.

The irony is that the tools I work best with - diagrams, flows, visual representations of complex systems - are also the ones that make good documentation. When I push for a diagram instead of a three-paragraph description, the whole team benefits. I've just had to learn to frame it that way rather than as a personal need.

Fighting Amazon for extra time - and losing

AWS certifications matter in this industry. They're a signal, a door-opener, and increasingly a checkbox on job descriptions that determines whether your CV gets read. I've taken them. I've passed them. And the process of getting there has been one of the more demoralising experiences I've had professionally.

I applied for extended time on AWS exams. This is a documented, legitimate accommodation for dyslexia - extra time on reading-heavy, time-pressured assessments. It's not a shortcut. It's a levelling of the playing field. Most certification bodies have a process for it. I went through Amazon's process. I submitted documentation. I made the case.

They refused.

I pushed back. I provided more documentation. I escalated. The answer stayed the same. No accommodation, no appeal route that led anywhere, no explanation beyond bureaucratic language about their standard process. I sat the exams without extra time, under the same conditions as everyone else, with a brain that processes text more slowly and less accurately under pressure. I passed - but that's not really the point. The point is that a global company with the resources of Amazon couldn't extend basic accessibility to someone who asked for it through the right channels and provided the evidence. That's a failure of process and of will, and I don't think I should have to be quiet about it.

Bullying, and what HR actually does

I've worked in environments where the head of tech made my working life actively hostile. Not passive, not ignorant - actively hostile. Comments about my written work that went beyond feedback into ridicule. Being publicly corrected in ways that weren't about the work. A pattern of behaviour that, when I look back on it now, was clearly targeted and sustained.

I went to HR. I documented what I could. I made a formal complaint. HR investigated in the way HR investigates: slowly, with language calibrated to protect the organisation rather than the person making the report. Nothing changed. The person is still in the industry. I'm not going to pretend that outcome was surprising - anyone who has been through a similar process knows that HR exists to manage liability, not to protect employees - but the experience of going through it, of doing everything right and having nothing come of it, leaves a mark.

I'm writing about it here because I think the combination matters. A manager who doesn't understand dyslexia is a problem. A manager who uses it as a weapon is a different problem entirely. And an HR function that treats a bullying complaint as a reputational risk to be managed rather than a person to be protected is a systemic failure that goes well beyond any individual organisation.

If you're reading this and you're in a similar situation: document everything, date everything, use email where possible. Not because it will necessarily change the outcome, but because it changes how you feel about yourself in the process. You're not imagining it. You're not being oversensitive. And you're not alone.

Why I'm writing this

Because the soft side of this job is real and it affects people differently. Because if you're a manager and you've never thought about this, maybe you'll think about it now. Because if you're someone who processes text differently and you're grinding through a DevOps role feeling like you're working twice as hard for half the credit - you're probably not wrong about that, and you're not alone.

The infrastructure works. The systems are stable. The pipelines run. That's the job, and I do the job. But it would be easier if the people around me understood a little more about what it takes to get there.