Peopleware, Scienceware

I've been doing a lot of programming at work lately.  As I've said before, neuroscience is increasingly becoming a form of computer science, so I decided to do a little computer science reading.  To find a book, I looked to two of the best comp. sci. bloggers out there, Coding Horror and Joel on Software.  Both recommended Peopleware, which is about managing software development teams, so I read it.

While neuroscience research and software development are not directly analogous, there are some similarities.  Both disciplines involve small groups of people working on limited length projects.  They both involve applying relatively standard techniques to create something new.  They require creativity and thought.  In essence, they're both knowledge work.

While I don't manage a lab yet, I hope to someday, so I took some notes.  These are the points that stood out for me at this point in my career:

1. "The major problems of our work are not technological, but sociological in nature"

While neuroscientists try discover how the brain works, the techniques we use are fairly standard: Westerns, imaging, molecular biology, patching, etc. Certainly these techniques can be skill intensive, and require intelligence to use, but they are uncomplicated enough that hundreds of labs around the world use them.  Only a handful of labs are developing truly new techniques like STORM/PALM imaging, or FLIM imaging.  Consider the biggest technical innovation of the past ten years, Channelrhodopsin, was just smartly applied molecular biology.

Yet project failures and delays happen all the time at least in the labs I've been around.  Part of this is because, unlike software development, there are no clear goals in science (although I'm sure some software developers with waffling clients would disagree).  Yet even without clear goals, most projections still usually have a direction, some purpose.

A bigger issue is the people, and their morale.  When an experiment runs into problems, it is usually solvable: if your PCR doesn't work, you tweak your Mg²⁺ concentration, or elongation times, but eventually it works. How quickly it gets solved is determined by morale. You need to go back to work the next day, and try something different.  All too often, when an experiment fails, your boss will ask what went wrong rather than making sure you're eager to fix it. (And once a PI stops doing experiments, their technical ideas for how to fix things become quickly outdated.)

This is partly due to how we train and promote PIs: most PIs are there because of their technical acumen, not their people skills. I've only met two PIs that understand happy workers are productive workers on a deep level.  The most successful labs will realize that projects usually run into problems when their people do, and not due to technical difficulties.

2. "There ain't no such thing as overtime"

Scientists like to think that they work hard, long hours, but with a few exceptions, I haven't seen it.  Sure, people will be in the lab area 10-12 hours a day, and come in a bit on weekends, but for almost every overtime hour they work, they also work "undertime."  Sometimes this undertime comes in the natural flow of work, whether waiting for gels to run, or stacks to be acquired. But all too often, I've seen people dicking around when they're not waiting for something, then staying late to make up for it (myself included).

While I don't doubt scientists' dedication to their job, we all have lives outside of work, and we need to drop the myth of being super productive.  Vanishingly few people can work 60-80 hour weeks for months on end, and trying to hold people to that standard is only going to drive them off.  One thing the scientific community lacks is a sort of "middle class" of people who do good work, but don't have the ambition to become a PI.  And this ridiculous standard of working long hours is part of the reason.

3. "You never get anything done around here between 9 and 5"

Knowledge work, unlike say construction or retail work, requires uninterrupted thought.  It takes a while to get into the flow of working, to remember where you are in an analysis, and to solve things quickly.  And to get into the flow you need the right environment, with no interruptions.

Despite that few labs are really set up to let people think in peace.  Some labs at Duke were set up smartly, with desks next to the windows in groups of two.  Others were set up almost optimally for disruption, with all the desks crammed into an office, where one conversation could interrupt everyone.  New buildings are often laid out in an open plan to "facilitate interactions."  I can only imagine how little work gets done there, and how often the people stay home to get some work done.

...

The rest of the book covers topics like hiring, and team building.  I don't have much management experience, so I can only consider the problem from the perspective of the managed.  I'm certain the issues look different from above.  The main lesson of the book, though, is pretty simple: hire smart people, keep them happy, and remove obstacles from their progress.