An ideal environment for research

October 5th, 2013

I’ve been very fortunate to work in a number of research institutions over the years. These are places set up specifically for people to work on new discoveries and developments – in my case, mostly in engineering, though it applies equally to many other fields. I really, really love good research institutions, and this evening I’ve been musing on what would make an ideal one. Here are my thoughts.

Firstly, you want the right people. It is, after all, mostly about the people. You want people that are interested and committed, and who have a varied range of skills and experiences. You’ll want several flavours of researcher from different fields, and then to support them with enthusiastic and helpful support staff. However, don’t employ too many – I think that about 200 people is the largest practical size. Why?

Firstly, geography – you can fit 200 people and all their stuff into one sprawling building, or a cluster of interlinked ones. You really don’t want to be having more than one building, or worse a split site with half the institution several miles down the road. This results in two institutions and not one. Most people can get to know 200 people and remember their names (mostly) within a year or two, given the right environment. Any bigger than this and you start to think of your colleagues as functions (“Purchasing”, “Geophysics”, “IT Support”) rather than as people, which really hinders collaboration.

If possible, you should provide opportunities for people to have casual conversations. These provide the vital cross-connections between people working in different offices. The key to ensuring casual conversations are two concepts from the world of retail – footfall and dwell time. Footfall is the number of people who pass through a space. If all your offices radiate from a central lobby, that lobby will always have high footfall as people move about the building, making it more likely that two people will meet in the lobby. However, if your offices are arranged into corridors by department, with the corridors interconnected at the central lobby, most people will only move about within their departmental corridor and the central lobby will be mostly quiet. In this situation, you can improve the chances of people meeting by increasing the dwell time in the central lobby. Put a coffee machine, a tea kettle. or a water cooler, and some chairs and tables in the lobby. People passing through will be encouraged to stop by, and people wanting coffee or water will come to the lobby deliberately and hang around. Increased dwell times mean more casual conversations.

Another great place to have casual conversations is in the canteen. You should definitely have a canteen – you don’t want your staff to disperse at lunchtime and not talk to one another, or worse to sit in their offices eating packed lunches whilst surfing the web. You should offer a choice of various types of food. You should allow people to eat their packed lunches in the canteen if they’d rather bring their own. You should have only just enough chairs and tables, so that people have to sit with other people that they don’t know when the place is busy. I think that having rectangular tables that seat four, that can easily be moved around, should be encouraged – these tend to then form a few long refectory tables for the gregarious types, whilst also providing quieter tables elsewhere. Make sure that the food is good and not too expensive. Make sure your catering staff are enthused and motivated – and perhaps even consider employing them directly rather than contracting out. For bonus canteen action, serve breakfast snacks mid morning and cake in the afternoon to encourage people to go, eat, talk and discuss their work with one another. If possible, make your canteen a through space, with multiple entrances to different parts of the building, so that it forms a natural meeting-place.

Now, the introverts reading this will say “but I need a place to think!” which is indeed very true. People need space to think and concentrate at times, without distractions. So, I’d recommend that you provide a number of tiny “carrels” – little quiet rooms with a desk and a chair and plenty of light – that people can book to use when they need a small, private space to work. Providing access to carrels means that you can continue to put your staff in shared offices – perhaps 3-4 to an office – which makes for better group-working than individual offices.

You’re also going to want meeting rooms of various sizes. Again, make these bookable by everyone, rather than reserving them for particular departments.

Now, on to the thorny topic of support staff. There’s always a reticence to employ support staff because they’re a “fixed cost” and seen as “not contributing directly” to research output. This is a fallacy. You have brilliant researchers, you want to enable them to do stuff they’re good at and give the stuff they are lousy at to other people that are better at it. Speaking as an engineer, I would strongly recommend that scientists are discouraged from building their own equipment without help from engineers! Huge amounts of time and resource can be wasted while people reinvent wheels or build Heath Robinson apparatus because they’re unaware of techniques or equipment that come from other fields. Likewise, good technicians are worth their weight in gold. Good mechanical technicians can make things out of bits of metal in an afternoon that would take me a week. Good electronic technicians can wire up cabinets neatly, and solder delicate components without damaging them. Employ good technicians, pay them properly, make them feel valued.

Give your research staff a briefing on how to use the support departments effectively. This isn’t rocket science, but a surprising number of people don’t get it.  The simple rules for dealing with support departments are:

  • Be polite.
  • Ask nicely.
  • Explain clearly what you want, and when you want it by.
  • Be reasonable.
  • Say thankyou afterwards.

If you do this as a researcher, you will find that your support staff will go the extra mile to help you when you find yourself in a difficult situation. If you take them for granted, they’ll get jobsworthy.

As a manager, please don’t ask your support departments to charge internally for their time. This causes two levels of evil – firstly, the researchers go “how much!?” and then try to do the support task themselves badly, or circumvent it by some other method to avoid paying. Secondly, your support departments become less helpful, because the response to “can you help me with this?” becomes “what’s your charge code? it’ll cost you!”. By all means have your support staff keep job logs, so you can see which individuals/departments are making heavy demands on support departments if you think they are being abused.

Information is the lifeblood of research. You need to know what is being done elsewhere, and also crucially what has been done in your institution in the past. So, you need access to books, journals and conference proceedings. A lot can be obtained electronically but you probably will still need a library to keep physical media in. This also provides another useful quiet workspace. Please have everything in some sort of electronic catalogue or portal page so that staff can easily find out whether the institution has access to the particular paper they’re looking for. Consider partnering with a university library to buy information services from them, or to allow your staff to have “visiting scholar” access if required.

Almost as critically, make sure that you retain information within your institution. Knowledge that doesn’t get published in peer-reviewed journals should nevertheless be held onto within an internal publishing system. I’m strongly in favour of the BBC’s system for doing this, which is called the Technical Note. TNs can pretty much contain any content you like and be of any length, though most are 10-30 A4 pages. When a member of staff writes a TN, it is signed off by their Head of Group and circulated to all the other senior managers and anyone else involved in the work. It is also archived and catalogued. The distribution of TNs ensures that information flows between departments, via the managers, and crucially provides some helpful validation for the researcher in question when senior people meet them in the corridor and say “Oh, I found your TN very interesting!”. TNs are also a convenient, measurable deliverable thing that results from any piece of work – a few hours of exploratory research, a new proposal, the outcome of a brainstorm – all these things can be captured, archived, and distributed around the institution.

Provide great facilities, the best that you can afford. Make sure someone take responsibility for looking after them – research labs often suffer “crisis of commons” effects where valuable equipment gets damaged through lack of experience and training. Provide “general” lab space, and make sure that you avoid departmental turf wars over lab and bench space. If you are constrained for lab space (and who isn’t?), I suggest a leasing system – a bench is “leased” to one project for a given period (weeks or months) and the lease is then reviewed when it “expires”. If the project is continuing, a new lease can be issued. This avoids the problem of dead projects squatting facilities that are needed for new ones. Some sort of “warm storage” facility would be nice – then you can put equipment into store that may not be used for a few months, rather than have it sit there gathering dust in the lab.

Administration is necessary and helpful, and admin people should not be looked down upon as lesser beings. On the other hand, you should not allow your administrators to dictate business processes for their own benefit! Make your purchasing and budgeting systems streamlined. If possible, provide regular updates to budget holders about how much money they have committed from their budget to purchase requests and how much has actually been paid out against invoices. Most accounting systems I’ve seen only keep track of payments and not budgets, so nearly every manager I’ve ever worked for has run some sort of parallel accounting system in Excel to work out how much budget they have left. This is a waste of everyone’s time – build the budgeting into the purchasing system and make it work for everyone. Train your research staff in how to interact with the admin and business processes, and make sure you have guides to common procedures in a staff handbook or on an intranet.

To summarise – hire awesome people, help them work together, with excellent facilities and well-thought-out processes. Produce excellent research. Profit!


Data management

September 20th, 2013

There’s a software-developer maxim that I heard recently, which is “if you’re writing code, you should be using source control”. Source control, also known as version control, is a system that looks after all the code that you write and stores it, and data about all the changes you make to it, in a form that allows you to revert to previous versions easily. It also allows you to work collaboratively with other people. By analogy with this principle, let me introduce a new maxim: “if you’re collecting data, you should be doing data management”. What’s “data management”? Let me explain…

Data management is looking after your data, and storing it a form that makes it easy to retrieve and understand later. A common situation is that you start out doing some “play” experiments, fiddling about to try and get a handle on some new piece of equipment. You collect some data, perhaps some numbers in a logbook, perhaps some sort of data file. Then you do more experiments, and unless you were meticulous, you end up with a whole load of different experimental results with filenames like DATA_EXPT.xls, DATA_EXPT2.XLS, DATA_TUESDAY.xls, etc. You put them aside for a week and then come back to them. They were meaningful then, but now you’ve forgotten what the parameters were, or which of the runs produced interesting results. Now you have a data management problem. Read the rest of this entry »


Technical book club

March 8th, 2012

I have a new job (in Oxford – more details in a later post) and as part of it I’m going to be doing a lot more board-level electronics than I have been before. I ought to brush up my skills and keep current, and so as a step towards that I’m going to start reading more technical books.

I have several problems with electronics books:

  • they are expensive – £50 is a typical price
  • they are rarely stocked in real bookshops, so online purchase is nearly always necessary
  • a lot of them are rubbish – either they’re very maths-based with very little application, or they’re badly written, or out of date.

So, I have a plan. I will buy one new technical book a month (which I can afford), based on reviews and online previews. I read it during the month, write a brief review on this blog (and on the bookseller’s website) and if it’s no good, send it back for a refund or resale. March’s book will be Analog Circuits by Robert Pease.