Why generic business English fails IT teams

A company books a business English course for its engineering team. Six months later the team can talk about quarterly targets and write a polished email, and they are still silent in the sprint retrospective. The budget was spent, the attendance was good, and the actual problem did not move.

This happens often enough that it is worth explaining why. The issue is not the teacher or the effort. It is that generic business English and the English an IT team needs are two different things.

Open most corporate English syllabuses and you find the same topics: introductions and networking, business travel, telephone etiquette, presentations to a general audience, negotiation, and email writing. These are reasonable topics for a salesperson or an account manager. For a backend engineer, most of them never come up.

The course is built for an average office worker who does not exist on a software team. So the engineer learns vocabulary they will not use and practises situations they will not face, while the situations they face every day go untouched.

Watch where an engineering team struggles in English and a clear list emerges. None of it is exotic. All of it is specific.

In stand-ups, people need to give a status and a blocker in a few sentences without rambling or freezing. In code review, they need to ask for a change directly without sounding rude, and to push back on an approach without it turning personal. In technical discussions, they need to explain a trade-off and hold their position when someone disagrees. In retrospectives, they need to raise a real problem rather than stay safe and silent. On client calls, they need to turn a technical issue into something the other side can act on.

A small example shows the gap. A vague stand-up update sounds like this: "Yesterday I worked on the thing, it is almost done, maybe some problems with the API." A clear one sounds like this: "Yesterday I finished the payment endpoint. Today I am writing tests. I am blocked on the staging API key, I need it from DevOps to keep going." Same engineer, same work. The second version is the one a team can act on, and it is the kind of phrasing role-specific practice builds.

A lot of the everyday language on a software team simply is not in a general course. Words and phrases like backlog grooming, acceptance criteria, flaky test, rollback, merge conflict, story points, and "let us take this offline" carry real meaning in context. An engineer can know the textbook word for a concept and still not know how their team actually refers to it in a stand-up.

This is why people who pass an English exam can still feel lost in their first sprint planning. The exam measured a different vocabulary than the one their job runs on.

Classroom practice tends to be slow, turn-based, and forgiving. A real stand-up is fast, overlapping, and unforgiving of long pauses. Someone who is fine in a calm one-to-one lesson can lock up when five people are waiting and the meeting is moving. The gap is not knowledge. It is that the practice never resembled the real conditions.

Training that uses the team’s real meetings as the practice closes that gap. People rehearse the exact situation, at something closer to the real pace, until it stops being the thing they dread.

Role-specific training starts from the roles and the meetings, not from a textbook unit. A QA engineer works on bug triage language and how to raise an issue in a retro. A DevOps engineer works on incident calls and handoffs. A software engineer works on code review and design discussions. The vocabulary is the team’s own, pulled from their board and their calls.

UnifyHub runs this across multi-country teams as one managed programme, so a distributed group in Cyprus, Serbia, and Germany trains consistently rather than through separate local arrangements. The point throughout is the same: practise the conversations people actually have, so the English shows up in the next real meeting.