Priya had been freelancing for eight months when a client quietly stopped replying. The work was solid, the pipeline she had built ran cleanly, and the invoices were paid on time. Still, the weekly updates went unanswered, and the next project went to someone else. She spent a week assuming the problem was price. It turned out to be something she had never thought to check: nobody on the client’s side could comfortably read what she sent. This is a story about that mistake, and about the small fixes that make remote DevOps freelancing easier for everyone you work with.

The symptom: polite silence

Priya’s updates were long, technical and sent as one dense email with a screenshot of a terminal pasted in the middle. She was proud of how thorough they were. Her main contact, an operations manager in her fifties who read English as her third language, was skimming them on a phone during commutes. The terminal screenshot was unreadable at that size. The abbreviations were never explained. After a few weeks, the manager stopped trying and began asking a colleague to summarise them, and eventually stopped asking at all.

Nobody complained. That is the trap with exclusion: it rarely announces itself. People simply drift away from what is hard to use.

The diagnosis: written for an imagined average client

When Priya finally asked for candid feedback, the answer was gentle and clear. The updates were written for someone just like her, a fluent English reader with a large screen, plenty of time and the same vocabulary. Real clients are busier and more varied. Some read slowly in a second language. Some have vision that needs larger type. Some have a patchy connection and cannot open attachments. Some simply have no appetite for jargon.

That reframed everything. The issue was not that her work was weak; it was that her communication assumed a single kind of reader.

The fix, part one: plain words, answer first

She rewrote her update format. Each message now opened with two sentences: what changed this week and whether anything needs the client’s decision. Technical details came after, under clear headings, with every abbreviation spelled out the first time. Sentences got shorter. She stopped using idioms that translate badly, such as “ballpark” or “low-hanging fruit”.

The surprise was how much the technical reviewers liked it. Engineers on the client’s side also read faster when the point comes first. If you are new to this and wondering what other everyday questions beginners face, our list of common questions from people starting out as freelancers covers many of the same communication basics.

The fix, part two: more than one route

Priya also stopped relying on a single channel. For each client she asked how they preferred to receive updates and agreed on a default: email, a shared document, or a short call with notes sent afterward. For calls she began sending a written agenda ahead of time and a short summary after, so that people who think better in writing, or who cannot join live, are not penalised.

For screen recordings, which she often used to demonstrate a deployment, she added captions and a few typed lines describing what the viewer should notice. That one change helped a client with hearing loss, a client in a noisy open office and a client who always watched with the sound off.

The fix, part three: time zones and tired people

Remote work stretches across hours as well as languages. Priya began stating times with the zone and the local equivalent for the client, and she stopped scheduling meetings that only suited her own morning. If you are balancing client work with another job, as discussed in our piece on taking on freelance projects responsibly alongside full-time employment, clear boundaries and shared written plans protect both sides from the tired, rushed communication that excludes people most.

The fix, part four: look at your own documents

Handover documents were the last change. She reorganised them so that a person new to the system could follow along: a one-page overview, a glossary, headings that describe the content, and links with meaningful text. She tested them by asking a friend outside tech to explain back what the document said. Where the friend stumbled, she rewrote.

She also began publishing a short working note on her own portfolio site about how she communicates and what accommodations she is happy to make. Seeing how professional web teams do this was a help; cmsGalaxy, a web development and SEO outfit that posts an accessibility statement for its own site, is one example of stating openly what you try to support. Priya adapted the idea in a few honest lines: what she does, what she is still improving, and how to tell her if something is hard to use.

What changed

The silent client did come back, a couple of months later, after a colleague forwarded one of the new updates. Priya cannot prove that the format change decided it, and she is careful not to claim that. What she does know is that replies arrived faster, questions became more specific, and fewer meetings were needed to clear up misunderstandings.

A checklist you can use this week

• Open every update with the outcome and any decision needed.
• Explain each abbreviation once, in ordinary words.
• Avoid screenshots of text; paste text where possible, or describe the image.
• Ask each client how they prefer to be reached, and respect it.
• Caption recordings and add a few lines of written summary.
• State times with zones, and share agendas before calls.
• Ask for blunt feedback on readability at least once a quarter.

Designing communication for the person at the edge of your imagined audience is not extra work for the sake of kindness. It is how you make sure the work you do well is received well. Priya’s lesson was simple: the reader you forgot may be the one deciding whether you are hired again.