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.