English, Communication and Code: The Skill Mix Remote Clients Pay For

Imagine two developers applying for the same Upwork job. Developer A has excellent React skills and writes: "i can do this job pls check my profile for more info. i have experience." Developer B has the same React skills and writes: "I noticed you need a dashboard with real-time data updates. I built something similar last month using React and Supabase. Here is the live demo: [URL]. I could deliver the first version within 10 days. Would it help to discuss the data schema before I start?"

Developer B gets hired. Every time.

The code they write might be identical. But the client does not see code until after they hire someone. What they see first is communication: proposals, messages, and emails. That is where the hiring decision happens.

This is not about accent or vocabulary. It is about clarity, professionalism, and making the client feel confident that you understand their problem and will handle it competently.

Remote work is text-first. Slack messages, email, pull request descriptions, documentation, and project updates are all written. Your written English is your professional appearance in a remote setting.

Quick wins:

• Capitalize properly. "i can do this" looks unprofessional. "I can do this" takes zero extra effort.
• Use punctuation. A message without periods or commas is harder to read and looks rushed.
• Proofread before sending. Read your message once before hitting enter. Catch the obvious errors.
• Use Grammarly or a similar tool. It catches errors you miss and improves your writing over time.

Deeper improvements:

• Read technical blogs written by good communicators. Notice how they structure explanations. Dan Abramov (React), Julia Evans (systems), and Kent C. Dodds (JavaScript) are excellent examples.
• Write regularly. Blog posts, documentation, code comments. Writing is a muscle. The more you use it, the stronger it gets.
• Study how experienced developers write pull request descriptions. A good PR description explains what changed, why it changed, and how to test it. Model yours after theirs.

One important note: Kenyan English is valid English. You do not need to sound American or British. You need to be clear, professional, and precise. "Kindly revert" is fine. "pls do the needful" is fine in informal contexts but should be avoided in professional settings because it lacks specificity.

Set expectations early. At the start of every project, tell the client: how often you will send updates, when they can expect deliverables, and how they can reach you if something is urgent. This one conversation prevents most communication problems.

Give regular status updates. Every 2-3 days for active projects. A simple message: "Hi [Name], quick update. I have completed the homepage and about page. Working on the contact form now. On track for the Friday delivery." This takes 30 seconds to write and saves the client from anxiously wondering if their project is progressing.

Say "I do not know" when you do not know. Clients respect honesty. "I have not worked with that specific API before, but I can research it and give you an estimate by tomorrow" is far better than "Yes, I can do that" followed by silence when you get stuck.

Manage scope changes clearly. When a client asks for something outside the agreed scope: "I can add that feature. It would take approximately 3 additional days and cost KES 15,000. Would you like me to go ahead, or keep to the current scope?" Clear, professional, and leaves the decision with the client.

Handle mistakes directly. If you introduce a bug or miss a deadline: "I found an issue with the payment integration that will take an extra day to fix. I apologize for the delay. I will have it resolved by Thursday evening." Own it, give a solution, and move forward. Hiding mistakes erodes trust faster than anything.

Most of your clients (and many managers in remote companies) are not technical. They do not know what React is. They do not care about your database schema. They care about what their website does, when it will be ready, and how much it costs.

The translation skill:

Instead of: "I need to set up a PostgreSQL database with RLS policies and connect it to the frontend through a Supabase client."

Say: "I need to set up the database that stores your customer data. This includes security rules so only authorized users can see their own information. This takes about two days."

The technical detail is for your team and your documentation. The client-facing communication focuses on what it means for them: what happens, how long it takes, and whether it costs extra.

Practice this translation regularly. After building any feature, try explaining it in one sentence without using any technical jargon. If you cannot, you do not understand it well enough yet. This exercise improves both your communication and your technical understanding.

Use analogies when they help. "The API is like a waiter. Your website tells the waiter what it wants, the waiter goes to the kitchen (the server), and brings back the food (the data)." Analogies are not always perfect, but they bridge the knowledge gap.

Kenyan developers have a genuine competitive advantage in communication that many do not recognize.

English proficiency. Kenya's education system teaches English from primary school. Most Kenyan developers are comfortable in English, which puts them ahead of developers from non-English-speaking countries competing for the same international work.

Multilingualism. Most Kenyans speak at least two languages (English and Swahili), and many speak three or more (including a mother tongue). Multilingual people tend to be better at adapting their communication style to different audiences. This is a real skill in remote work where you interact with people from diverse backgrounds.

Cultural adaptability. Kenya's exposure to both Western and African business cultures gives developers an intuitive understanding of how to communicate with clients from different backgrounds. You code-switch naturally, adapting your formality, directness, and communication style based on who you are talking to.

The key is to be deliberate about leveraging these advantages. Do not assume that because English is natural to you, your professional written communication is already where it needs to be. Professional English in a remote work context has specific conventions (clear subject lines, structured status updates, concise messages) that differ from conversational English.

Communication improves with practice, not with reading articles about communication. Here are habits that compound over time.

Write a daily standup to yourself. Even if nobody asks for it. "Yesterday I completed X. Today I am working on Y. Blocked by Z." This trains you to summarize your work concisely.

Write detailed pull request descriptions. Every PR is a communication exercise. Explain what you changed, why you changed it, and how someone can test it. Over time, this becomes automatic.

Read and respond to emails within 4 hours. Responsiveness builds trust. You do not need to have the answer immediately. A quick "Got it, I will look into this and get back to you by tomorrow" is enough.

Join online developer communities. Engage in technical discussions on Twitter, Discord, or Reddit. Explaining code to strangers who cannot see your screen forces clarity.

Record yourself explaining a technical concept. Listen back. You will notice filler words, unclear explanations, and rambling. Repeat until the explanation is tight and clear. This is how you prepare for technical interviews and client calls.

These habits cost nothing and take minutes per day. Over 6-12 months, they dramatically improve how you communicate, which directly improves how much you earn.