Post 3 of 5 — Vocational IT English
This is a companion piece to Englisch in der IT-Ausbildung: Was Azubis wirklich können müssen — that post sets out the case for trainees and employers; this one is the practitioner’s version, for other teachers building similar material.
The mismatch
A vocational IT trainee will spend their working life reading documentation, writing tickets, and troubleshooting in English with colleagues who are also not native speakers. Very little of that is served by a general English syllabus built around social conversation and travel vocabulary.
This is not a proficiency gap. It is a domain gap. A trainee at B1 who can read a configuration guide and write a clear incident report is more employable than one at B2 who can discuss holiday plans fluently. Vocational English instruction should optimise for the former, and much of it does not.
What the job actually demands
Analysing the language tasks first, before deciding on any grammar sequence:
Reading
- Dense procedural documentation, read for extraction rather than comprehension
- Error messages and log output, read diagnostically
- Documentation written by non-native speakers, requiring tolerance of inconsistent register and occasional ungrammaticality
Writing
- Support tickets and incident reports where imprecision has direct operational cost
- Procedural documentation intended for readers less expert than the writer
- Email that is economical, unambiguous, and appropriately urgent
Interaction
- Asynchronous troubleshooting where a badly framed question wastes a day
- Clarifying questions that narrow a diagnosis rather than restating the problem
Notice how much of this is precision under constraint rather than range. That has consequences for how it should be taught and assessed.
Exercise design
Scenario-grounded rather than topic-grounded
Every exercise starts from a situation a technician would recognise. Not “read about networking” but “this ticket arrived; what do you know, what is missing, what do you ask?”
A live example: ticket comprehension and helpdesk register
Taking one of the live pages rather than a constructed illustration: IT Support & Service Requests, one of ten units in the IT English series. It is open — no login, no name required.
Domain: Service desk — first- and second-level support | Target level: B1–B2
Trainees read the history of Ticket #4821. A user in accounting cannot open files on the shared drive; an error appears every time. The text is written the way a ticket is written — timestamped entries, first-level support asking for a restart that does not help, an escalation to second level at 09:30, a workaround issued before the actual fix, closure at 11:05 inside a four-hour SLA, and a follow-up action left open. The cause turns out to be permissions changed during an overnight system update.
Exercise A — extraction. Six items on what the ticket actually states. The distractors are the plausible wrong diagnoses — a broken hard drive, a virus, a forgotten password — so the trainee has to read what this ticket says rather than what a helpdesk problem usually is. One item asks what second-level support will check next, which lives in a single clause at the end that a fast reader skips.
Exercise B — nomenclature. Seven gapped sentences fed by a word bank of service-desk terms: ticket, escalation, SLA, workaround, first-level support, incident, resolution, service desk — plus sprint and encryption, which are not needed. The surplus entries matter. A bank with exactly the right number of words can be completed by elimination; a bank with two decoys cannot.
Exercise C — register. Eight items on how a technician actually addresses a user: indirect questions (“Could you tell me … ?”), reported speech for summarising what the user said, and modal choice for softening a request. The last item drops the multiple choice entirely and asks for a rewrite — turn “What is your computer name?” into something you would send to a customer. That single open item is the one that shows whether the pattern has been internalised or merely recognised.
Why this works better than a documentation-reading exercise: all three sections come out of one artefact the job produces, and every language point is one that artefact needs. The trainee is not reading about service desks; they are reading a service desk’s own record and then being asked to speak its language. What this unit stops short of is extended production — so that lives in a separate page, Writing Task: Texts the Job Produces, which assigns one of five real workplace texts (ticket reply, incident report, procedure for a non-expert, status email to a non-technical manager, asynchronous troubleshooting message) by a hash of the student’s name, so neighbours write different things.
Vocabulary in layers
Technical English separates cleanly into layers that need different treatment:
| Layer | Content | Teaching approach |
|---|---|---|
| Nomenclature | Domain nouns and acronyms | Glossary, always available |
| Process verbs | deploy, configure, escalate, patch, roll back | Taught in collocation, not isolation |
| Causal language | as a result, due to, this triggers, stems from | Taught through log and incident analysis |
| Register | Passive for documentation, active for collaboration | Taught by contrast between paired examples |
The glossary stays available permanently, including during assessment. Working technicians use references; removing them tests memory rather than competence.
Assessment and the integrity question
Vocational cohorts raise the integrity problem in a sharper form than school groups, because the deliverable — a written ticket, a report, a procedure — is exactly the kind of short professional text a language model produces well.
The response is to separate the two task types explicitly.
Practice tasks are open. Trainees may use whatever they like. Using a model to check a draft ticket is a legitimate professional workflow and pretending otherwise is not credible to adult learners.
Assessed writing runs under invigilated conditions — but not yet in this series. The client-side toolkit exists and is in use on the university writing assessment: paste and shortcut blocking, right-click and DevTools blocks, focus detection with an on-screen warning, typing-speed anomaly detection, a submission time gate, word-count and required-vocabulary enforcement, non-selectable prompt text, four-variant prompt randomisation by name hash, three-minute progress snapshots, and an integrity record submitted with the work. The IT units do not use any of it, for the simple reason that they have no assessed writing to secure — the writing task described above is submitted for teacher feedback, not for a mark. When an assessed IT variant is built it will inherit the same toolkit; until then, nothing in this series produces a number worth defending.
The full implementation, the caveats it requires, and the data-protection questions it raises are set out in the companion post on academic integrity. The short version: it is deterrence and evidence, not prevention — a phone beside the laptop defeats all of it — and a flagged anomaly is grounds for a conversation rather than a verdict.
One point is specific to adult vocational cohorts. They are considerably more tolerant of invigilation than of a marking scheme they suspect is unenforceable. Explaining that assessed writing is secured because the certificate is supposed to mean something lands well with trainees who intend to use it. What does not land is pretending the practice tasks are secured too.
What I am still working on
- Multimodal input, combining configuration files and system screenshots with language tasks
- Extended scenarios requiring sustained language use across several linked artefacts
- Peer review of technical writing, which develops the reader’s judgement as much as the writer’s
The argument
Vocational language teaching works when learners recognise they are building professional capability rather than studying a subject. Authentic scenarios do most of that work. Clear, honestly explained assessment conditions do the rest — adult learners are considerably more tolerant of invigilation than of a marking scheme they suspect is unenforceable.
Post 1 sets out the academic integrity framework in full. Post 4 covers Abitur writing preparation; post 5, MSA exam practice.
Improve your English skills 