There is a clutter of ‘English for IT’ ideas, activities and nagging questions in my head and by now I feel that the only way to ‘untangle the tangle’ is to write some of it down.
So this is a placeholder post where I’ll later put together links to other IT-related posts and lesson plans, but for now – here is just ‘the story so far’.
I’ve been teaching Business English in-company for around three years now and most of that experience has been in IT companies. Back in September 2011 I was given my first IT group by the language school I was working in. The school supplied me with a 120-hour ‘Business English’ syllabus that I wasn’t supposed to adapt and off I went to teach my first group.
Teaching in this setting has been quite a journey with its ups and downs (one particularly memorable ‘down’ came in the very first month, when I asked a group which consisted of three software developers and three software testers to share their views on how responsibilities should be devided between developers and testers, and an almighty row ensued.)
My first degree was in maths and IT and I’d actually worked as a software developer in a quite large IT company for some time while studying at university. This experience, however limited and remote, was an undeniable asset when it came to thinking up warmers and mini discussion topics that would be perceived as relevant by my students, but it also made it quite difficult for me to do justice to the syllabus. Having my (limited) personal experience to compare with the coursebook topics and contexts, I sometimes totally failed to see how some of the topics we were supposed to cover would be of any relevance to my students. The company I was teaching in was a service provider which basically had been developing one product for the past ten years. How often would my average student, who mostly communicated with other members of their distributed team and with support specialists, describe graphs (sales peaked in the early 1980s and they hit a trough in 2008/9)? Negotiate a contract? Present an innovative gadget to a potential investor?
This of course became a self-fulfilling prophesy, as I often couldn’t convincingly introduce those topics to my groups.
But then some topics that I did ‘believe’ in, such as meetings, sometimes resulted in unsatisfactory lessons too, with the groups failing to retain any functional language and sabotaging the roleplays I was trying to use (picture a group of bearded men giggling self-consciously while solving a business problem).

An IT stand up meeting. Image source: https://c2.staticflickr.com/2/1069/1470213175_3c53cf5a58.jpg
On the whole this has been a journey of, on the one hand, learning more about my students’ actual needs and tweaking and tailoring the course after all, but on the other, learning not to overcomplicate the issue, to draw more on my students as a resource, to assume less and trust the material more but ask the right questions to help my students connect what they’ve learnt to their own experience.
Six months ago I quit the language school and joined a software company as a full-time teacher. So far this has been not only an absolutely fascinating experience but also a huge challenge. I keep hitting on/learning about ideas that, once I know about them, seem embarrassingly obvious. The one that struck me the most was advice given by Evan Frendo in his presentation on Investigating discourse practices within a company: ask your students, “What differences are there between
your [presentations] at work and in the English training?” I couldn’t believe I’d actually taught several courses in company, worrying that the coursebook didn’t address my students’ needs and scouring the internet for recordings of real IT meetings (in vain), and never actually asked them to list specific differences between the genres presented in the coursebook and their workplace communication. Probably I was too busy feeling guilty for not knowing about those differences already and fearing to lose face and thus missed the most obvious and natural thing to do.
This is why, I’m afraid, this series of posts comes with a huge ‘captain obvious’ sign: I want to write up ideas that weren’t obvious to me when I was starting out – which does not mean that they are not self-evident or common practice.