Law Thirty-Six

You gotta go with what works

Straw boater on a punt pole

Five things I learned in my first job


Looking back over the last twenty years, it’s easy to see the influence of my first ‘proper job’ on my working life since. There was what might appear to some to be a sharp change in the direction of my career as soon as I left university. Two weeks after finishing a postgrad course, I was living in Oxford and working as an IT trainer. It was one of the best times of my life, probably the best job I ever had, and I see that I’m not the only person working who thought so. The people I worked with there have gone on to achieve great things in their respective fields: IT directors, company directors, conference speakers, an Exchange MVP, and a priest among them. That may say something about how we recruited, but I think it speaks to what they gained from their time with the company. Sadly, the company itself ceased to exist a few years after I left, although some of the players of the time have since resurrected the name and it has risen again, providing Microsoft identity and access management solutions.

Oxford Computer Group’s job advert asked ‘Are you reasonably good at everything’. Its interview process required you to work out what part of a train always goes backwards, and to discuss what determines whether an electric shock is lethal. HR professionals may sneer at the techniques we used, but they were effective: it selected staff who had the arrogance (for want of a better word) to stand up at the front of a classroom and purport to know more about a subject than any of the delegates and who were self-sufficient enough to deal with the demands of the role.

By the time I left the company five years later, I had learned a number of extremely valuable lessons about work.

Living on the edge is motivating

One of the company director’s catchphrases was “How hard can it be,” and that summed up the company’s approach to challenges. New recruits were put on a steep learning curve. In my first week at OCG, fresh out of university and never having participated in let alone managed a project in my life, I found myself sat on a Microsoft Project 4 Introduction course. In week 2, over the course of five days, I restructured and re-wrote the two-day Project 3 Intermediate course for version 4. Instruction came from a series of 10 minute conversations with my manager a couple of times a day. On the Friday of week 2, I worked my first all-nighter, alone, while my boss attended an Oxford college ball. By 10am on Saturday, I had seven copies of the manual bound and packed in a bag together with the usual kit for an on-site training course, and my boss flew out to Dallas that day to teach it.

Get a group of OCG trainers together and it’s like listening to extreme sports enthusiasts, bragging about the time when they nearly fell off a cliff face or they cut it a bit fine opening their parachute. The classic story was of the two founding directors teaching a particular course: one would be in the classroom, one was in the room next door writing the next module. Every hour, they would swap round.

My own stories weren’t quite as extreme. My first course was on the client’s premises in Staffordshire and involved me driving up with eight computers and an OHP in the boot of the car, and powering the whole lot from the only floor socket available in the training room. I vividly remember the penny dropping about why you needed an intermediate table in a many-to-many database relationship whilst explaining it on a SuperBase intermediate course. There are also a shocking number of stories about staying up well into the early morning learning a course followed by getting up and driving for two hours to deliver the training. How I avoided ending up dead in a ditch, I don’t know.

If you’d asked me at 2am whether I was enjoying myself there and then, I doubt I would have said yes. But if you’d asked again at the end of the week when the course was over, the evaluations were in, and I was sat in the Rose & Crown with a pint in a glass with a handle, working my way through a half-pint of pistachios… oh yes, it had been a great week.

Mostly, we got away with it. We were set an impossible goal, and we would rise to the challenge through whatever means necessary. And the following week, we’d do it again, high on the adrenalin we got out of being just two pages (or less!) ahead of the delegates. The sales team could sell what they wanted without worrying too much about whether it was possible. Hence, we landed a contract to deliver Lotus Notes email training to a national law firm, despite the fact that (a) no-one in the company had ever seen Lotus Notes; (b) we didn’t own the software; (c) we only had two weeks to write the course; and (d) it took over a week for us to work out how to install a Notes server.

Occasionally, there were failures. Mostly, these involved the death trap that was Microsoft’s Supporting Windows for Workgroups 3.11 course. Many a good trainer was dashed against the rocky shore of Microsoft’s bizarre networking stacks. For the record, the first time I ever made one of my delegates cry was when I was teaching this course.

The only one who’s going to look stupid is you

When you stand up in front of a room full of people to teach a course, you either know your stuff or you don’t. Once you shut the door to the training room, there’s not a huge amount anyone else can do to help except mop up the tears afterwards. Delegates need to trust you, and each question you fail to answer and each time you’re caught out in a mistake damages that relationship with your class. As a fresh-faced youngster trying to teach project management software to battle-weary engineers, I would start each course confronted by a roomful of sceptical stares, and I couldn’t afford even the slightest lapse.

Therefore, you came prepared. You knew the material, you knew the exercises you were going to walk through and all the ways they could go wrong. You anticipated the questions that would come up. You played with the software until you broke it, then you worked out how to put it back together again. It was an extreme lesson in self-reliance, and it fostered skills in being able to assimilate knowledge quickly (even if you only retained it short term) and in thinking on the spot. I’ve always thought that the way in which OCG trainers prepared for courses was similar to the way in which barristers prepare for court appearances (assuming This Life is representative…): late night sessions spent mastering the brief, followed by six hours of winging it in front of a potentially unforgiving audience.

One of my colleagues used to say that a good course was one where none of the delegates stood up, pointed at him, and shouted “Charlatan!”

Of course, there were techniques you learned to get by. You would tend to get delegates who would start questions with “Isn’t it true that…” or “Doesn’t that mean that…” followed by five or six sentences of unintelligible geekspeak. One of my fellow trainers would typically respond with a non-committal shrug and the answer “Superficially, yes.” I was never sure whether he entirely understood the question he had been asked.

Training taught you that completing something to an ‘okayish’ standard just wasn’t good enough. This extended not just to preparing for training deliveries but to all aspects of work. Fifteen years before Lynne Truss and the Internet grammar police, one of our Directors had a reputation for copy editing and fact checking course material with a whiteboard marker. Your draft might come back to you with just a line through it and the comment ‘Rubbish’. Your grammar mistake could end up being emailed to the whole company with a rant about why it was wrong. This encouraged you to get it right before you handed it in.

Find your niche and you will go far

If I’ve given the impression that OCG was staffed entirely by fraudsters, then let me correct that. There were a large number of devastatingly clever people working at the company, and we traded on a reputation for technical excellence. We literally used to teach the Microsoft support engineers about Microsoft products. Two people wrote a highly-regarded course about NT4 recovery – how to understand what those blue screen errors are saying and what to do about it. Another colleague could speak at conferences on the depths of C++ or the intricacies of TCP/IP with equal skill. Another knew not just how many worksheet functions were available in Excel 5, but also what all of them did, including the obscure statistical ones. When not madly preparing for the following day’s training, we had the luxury of time to dig deep into our chosen products. Little was done internally to manage the skills profile of the trainers, but we naturally found niches for ourselves and pursued them.

This was an age before the Internet became the indispensable IT resource that it is today. We learned to read the product manual in the same way you might read a history book rather than the way you might read a maths textbook. We questioned it — surely that statement can’t be true, the product can’t work like that. No, it doesn’t. So how does it work? We would work back to basic principles and posit how the system ought to work, and then test to see whether it did. It’s a problem solving approach I still employ today with real-world IT problems.

There has to be give and take

My final two points here are observations about management lessons I learned at OCG.

Working for OCG was demanding. If you were training, that was generally not in Oxford. After travelling back to the city, you’d probably go back to the office to check email and deal with some admin tasks. Not all the trainers had laptops, and downloading email over a 56k modem could take so long that it was quicker to go back to the office than to try to work remotely. If you went into the office on a Saturday, you could be fairly sure that you wouldn’t be the only one, and the trainer’s prep room was often as busy at weekends as it was during the week.

Last year, we replaced everyone’s PC or laptop at work. As I walked around the office at midnight, checking that we hadn’t missed any of the machines due for replacement that night, I would come across several of our graduate trainees, still working away, keen to give the right impression to their employer and hoping to secure a permanent position at the end of their training. As I wondered how on earth they managed to keep this up for an extended period – and indeed why they put up with the workload – I realised that their working life was little different from the way I’d started out at OCG. They’re young, they have energy, and most have the flexibility in their personal lives to be able to make this work commitment.

OCG sometimes asked impossible things of its staff. One group of trainers found themselves on a fourteen-week project teaching the same one hour course five times a day and living out of a hotel at a motorway service station. Sometimes the margins on the training we were delivering didn’t allow for us to book accommodation. One client in Greenwich comes to mind – and so you’d spend two-and-a-half hours driving to the training venue each morning, and then the same or longer driving back at the end of the day, every day for a week. A last minute schedule change could see you booked to teach a new course at short notice, and everything in your life would have to make way so that you could prepare.

If you want your staff to have this kind of commitment, you have to give something back. I think OCG got this right. We paid well (in my opinion). We did pay reviews twice a year because that was how fast your value to the company changed. And if you weren’t booked to teach a course, there was flexibility about things like what time you arrived in the office. After courses finished on a Friday afternoon, you’d have to stay on to build the PCs for the following week’s training, and step 1 in that process was to go to the fridge and grab a beer – which is great from a staff morale perspective but not so good in terms of making sure the training rooms were set up properly!

There were other little things as well, such as making the pool company cars available to staff at weekends or providing a company punt (well, it was Oxford after all). OCG was a small company at the time, and these kinds of things are generally much more difficult to achieve as the organisation gets bigger. But I think it was also part of the management ethos — it doesn’t surprise me that in the video tour of OCG’s current premises, you can spot a table football game in the background.

Without this give and take, as an employer you simply cannot make the same level of demands on your staff. Good will runs out, staff become inflexible or leave, and you can find yourself with problems on all sides.

Not all groups of co-workers are teams

Eventually, OCG recognised the need to send its managers on some kind of management training. One of these was among the best training courses I’ve attended (and I am really bad at attending classroom training that I’m not teaching myself). But we reached an interesting point right near the start of the course. The module was all about encouraging teamwork, and started with a question about what constituted a team… and it was arguable whether the trainers within OCG actually fitted into the definition.

We agreed a collection of criteria for what constituted a team. There had to be a shared goal or common purpose, and there also had to be an element of co-dependence. It was on this last point that the test broke down. We had selected and developed a group of independent, self-reliant people who spent their working days stood in a room with the door closed between them and their colleagues. Yes, trainers would support each other where they could, even if only by listening to the latest horror story of the delegate from hell or a nightmare course. Absolutely, there was camaraderie, one of the coping mechanisms that we used to deal with the non-trivial levels of stress involved in the job. But that’s not necessarily the same as being a team. We were perhaps like a group of independent contractors who spent a lot of time with each other.

I don’t present this as a bad thing – it was just a fact, and once you understood it, it explained some of the ways in which the group behaved and why some of our management approaches weren’t working. Equally, you can use this definition the other way round: if you have a group of co-workers and you want them to act more like a team, you should start by looking at whether the pre-requisites exist. Do they share a common purpose? If so, make sure they understand that. In what way are they co-dependent, or how can you introduce that co-dependence?

I blame Hugh

Looking back twenty years, I know that I wouldn’t be doing the job I have today but for the fact that one day in June, I pointed out the potential grammar confusion in a sentence about “the solitary swans lake”, I didn’t get flustered by Ken trying to take me off script five minutes into my presentation, and I was still stood at the front of the room at the end of a group discussion on train wheels. A very productive day.

Update: US spelling of “sceptical” removed to please Ian Davies.

Leave a Reply

Required fields are marked *.