Please note: this older content has been archived and is no longer fully linked into the site. Please go to the current home page for up-to-date content.

# The Research Technologist part 2: research focus

Tuesday 10 January 2012
Tagged with

- Research technologist
- Research
- Job description
- Reflection

This is the second part in my exploration of what it means to be a research
technologist. If you haven’t already, check out part 1: proactivity and
innovation.

## Research focus

There’s another area where the role diverges from the typical member of IT
staff: a focus on the unique needs of researchers. Network infrastructure, file
storage, email are necessary but not sufficient to meet the needs of a modern
researcher.

It’s vitally important to pay close attention to the unique needs of
researchers and to find appropriate tools and techniques to adapt to serve
those needs as well as possible. Research is after all the primary business of
a university, alongside teaching.

So we need to find ways to fulfil the needs not just of an institution’s
researchers, but of a faculty’s researchers, or a department’s or even a single
research group’s.

I actually think that once we start doing this well, there will be a lot more
commonality than there appears to be right now. But first we’ve got to get
there.

## Serving the long tail

The much abused Pareto Principle holds that in many circumstances 80% of your
profit comes from 20% of the people/products/whatever. But we’re not looking to
profit from our users, we’re looking to serve them. Questions of how to fund
that not withstanding, taking this attitude means you’re ignoring of the
people!

If there’s one thing we’ve learned from successes like eBay, Amazon and many
more, it’s that if we’re smart we can use modern technology to efficiently
provide large numbers of niche products and services without drowning in the
overhead traditionally associated with trying to do so.

## Research attitude

Again, this can be a problem for centralised IT services, because it’s seen as
inefficient for them to put significant R&D time into things which may only
ever be of use to a minority of their users.

In an academic department, however, the culture is different. Success in
research demands innovation, which requires risk. Scientists and engineers, for
example, intrinsically understand the need to experiment, and no-one questions
the idea that many of those experiments will fail.

Notice that word fail. In this context failure is not a loss, it’s merely a
failure to produce the anticipated results. Most researchers still don’t like
failure — they’re human after all. But they learn not to get so hung up on it,
because if you set up your experiment right (which is really the key to the
whole enterprise) then you learn as much or more from failing as you do from
succeeding.

And that’s really the point. We want to help our researchers to do their jobs
even better than they already do, which means we need to learn, which in turn
means we need to make mistakes. There are no lectures and degree courses to
teach us about ideas which don’t exist yet.

So to steal one of those trite little phrases life coaches and the like love so
much: fail early, fail often, fail smart and learn from it.