I began writing this a couple of months ago, shortly after ALT-C, the Association of Learning Technology Conference. Then it turned into “one of those posts” that I had to perfect before I could publish it. And that’s silly, so I’m going to publish it now and continue it in further posts, because this is a blog, not a thesis.
Anyway, as is often the case at conferences when you meet a lot of people, I kept having to answer the question “What do you do?”. My actual job title is “ICT Project Manager”, which while impressive sounding doesn’t go any way to explain what I do. In the end, I came up with the following stock response:
“I’m a research technologist: I have a very similar role to learning technologists, except that I support academics as researchers instead of as teachers.”
There are a few roles out there which sound similar, or which have similar names, so I thought I’d mention a few things that set this role apart from other similar sounding jobs. This post is the first part of a series exploring those aspects.
First, a disclaimer
I’m not foolish enough to think I’m the only person doing this type of job, or to pick out these features as important, or even to come up with that name. I’m quite certain there are people doing this in IT departments, in research development departments, certainly in academic departments and quite possibly in e-learning departments too. It’s more that there seems to be no standard position for this role (except where institutions have dedicated e-research teams) and I’m setting out to find other people in similar roles to share ideas with.
Proactivity and innovation
Although part of my role is to support existing systems and respond to queries from users, that’s not the whole of it. I feel it’s important to keep abreast of the latest technology innovations and explore how they can be used to support research. This contrasts with the typical approach of central university IT services, which generally have a core set of “supported” software and services with rigorous procedures and checks in place to control changes to that set.
I don’t wish to suggest that this centralised model is inappropriate: on the contrary it’s absolutely necessary. University IT services have the very challenging job of providing an acceptable and consistent standard of service to a huge and diverse user base. To do this efficiently it’s necessary to make sure that all IT staff have a reasonable understanding of every supported service, which just can’t happen if that set of services is too large.
The trouble is that as well as providing users with a very stable, high level of support for essential services (networking, email, payroll and so on), it also tends to stifle innovation. If a new service is to be offered, a lot of time and resources must be invested in doing so at the level of existing services; quite a risk if there’s no guarantee that the new service will succeed. That means that there’s no scope to start something small, with the option of either growing it organically if it takes off or letting it die peacefully if it’s not right.
I’ll be exploring this further soon, but for now I’d be interested in your take, especially if you disagree or recognise some of what I say in your own role.