Tagged become better

Initiating, planning, and running collaborations

Collaborations are everywhere in research. They are the Number One way to import methods and expertise into your research group, and to export your own knowledge to help others go new ways.. They also give your team members additional training opportunities. So today’s post is all about initiating, planning, maintaining, and quitting collaborations – both for PIs and their group members.

together we can

This post is part of the open draft for the Research Group Leader Book
[about] [read more]

In this post, I address collaborations both from the view of the PI, and from the view of a scientist in training. One of my PhDs asked me to write about this topic, and it’s definitely one of the topics that should be discussed and taught during graduate training.

Being strategic about collaborations

I first collaborated at the very beginning of my PhD; of course, this collaboration had been initiated by my supervisor. Then, nothing followed for a while. When the first opportunities presented themselves toward the end of my PhD, I was thrilled and jumped at them. But I found that with my first papers out, and with becoming known in my field through conferences and talks, there were soon more opportunities than I could possibly serve.

At this point, senior scientists told me that I should be strategic about my collaborations. So, while it might be take what you get at a very early stage, opportunities for collaborations abound once you’re at the stage of Postdoc or PI. And then, each collaboration you agree to means saying no to others.

The three most important questions to ask about any potential collaborations are:

  • What am I looking for, and what is my gain? Some aspects are access to data acquisition and anaylsis methods; expanding into a new topic; getting into a new social network. You might have others.
  • What can I offer the collaborator; what is his gain? One important thing you can always invest is your time and effort.
  • Therefore, is this collaboration worth investing my and my team’s time? And, what other work, projects, or collaborations will I have to sacrifice to be able to handle this one?

Responding to invitations to collaborate

…if the PI is asked

As PI, inquiries can go three ways:

First, the collaboration might involve you directly, such as writing a review paper together, writing a collaborative grant together, or providing expertise only you as PI own in the lab. In this case, you have to answer the above questions about the value of the collaboration; probably more importantly, you have to decide whether you have the time to take part.

Second, the collaboration might rather involve someone in the lab, for instance, an expert for some fancy method. Of course, the decision whether to start this collaboration should involve that person. But step one should be for the PI to decide whether it strategically fits the lab. Step two is to discuss with the lab member whether the collaboration will advance their career. The worst way (though this happens quite a bit in real life) is to inform the lab member that, by the way, there is this new project they will soon be working on in addition to all the other stuff they are already doing.

Third, a potential collaborator might ask to work with or in your group. Although the first response to this is usually that as long as that person comes with their own money and do the work, all is fine, any such collaboration does require your supervision, and, at the latest when the resulting paper must be written, considerable time. If the student wants to join your lab, it is also important to think about whether s/he will fit into the group, and how much your lab members will need to be involved in the project. Accordingly, don’t forget to ask them.

…if a lab member is asked

Lab members are probably most often asked to contribute their expertise. This means, they will have to invest considerable time. Let your team members know whether you are open to them discussing collaborations, and at what point you want to be involved. On the one hand, they are on your pay roll. On the other hand, they are on a career path. The further they are in their career, the less they will be willing for you to impose decisions on them. To take conflict by its horns, it is best to discuss openly how much freedom they would like, and how much you are willing to give.

Your team members are likely less experienced with collaborating than you are as a PI. So share your experience with them, and help them get their priorities straight for effective career planning.

…in any case

It’s a risk to enter a collaboration with someone you do not know. I’ve read that some people advise to collaborate only with people you know well. I personally don’t think this is realistic if you want to build a relatively wide network of collaborations. However, it is important to get to know your collaborator as much as possible before giving the final go.
Ask others in your network. Most of the time, someone has information about your prospective collaborator. Furthermore, trust your gut during the initial discussions. If it doesn’t feel right, consider letting it go. And make sure all important aspects of the collaborations are negotiated up front and agreed upon by everyone.

Initiating collaborations

Initiating a collaboration is probably the easiest part of the whole endeavor.
It usually takes as little as a conversation at a conference, or an email.

Your approach will be most successful if you communicate the following things:

  • What is the specific project / topic / experiment you are proposing?
  • What is your background, your lab, etc.?
  • What time frame are you thinking about?
  • Who will pay for the project (travel, living expenses, experiments), and/or does it involve writing a grant?
  • What is your investment, and what would you like the collaborator to provide?
  • What result are you aiming for? (In most cases, this will be a publication.)

You might not communicate all of these points at once; in a conversation, you can contribute them piece by piece when they fit. If you go via email, some things might be discussed only after initial contact has been made.

Your collaborator will have his own agenda and ideas, and might propose alternatives to your own ideas. Don’t be too quick to say yes to everything. Remember to evaluate the collaboration strategically. Therefore, before you make initial contact, know what you really want out of the proposed collaboration.

Planning the collaboration

Once it’s clear that both sides are generally interested, it’s time to do some real planning:

  • In your own lab, make sure people know who is involved in what way.
  • Specify the project. Decide on the exact experiment or product. Make sure everyone is on the same page.

  • Discuss who will provide funds. If the collaboration involves someone staying in the other’s lab, this includes travel and housing cost. Make sure to think hard about all types of cost that will arise: experimental subjects, materials, publication cost etc. If grant writing is necessary, agree upon who will provide which parts.

  • Discuss a timeline.

  • Discuss authorship of a prospective publication. This can feel very weird, especially when you do it the first time. But it really helps to clear up everyone’s role in the project ahead of time. For instance, the first author will be expected to do pretty much all the work noone else feels responsible for. The last author will probably be the one to provide funds for experimentation. But these things will depend on your field, and on the specific situation.
    Discussion about authorship is especially important if junior members of both collaborating teams are involved: both might want to use this work toward their qualification (e.g. PhD), which is often only possible with a first authorship. Equal contributions are becoming more common, but might not be admissable in all graduate programs. As PI, be sure such administrative aspects are cleared up well in advance to avoid dark hours for your PhD later.
    Discussion about authorship is also relevant for the seniors of the collaborating labs, as last authorship may be important for tenure, success-oriented funding, and salary increases. Here, too, shared authorship is becoming fashionable. Again, it’s smart to clear up the consequences of author order in advance.

  • Distribute tasks. Where will what work be done? Who will program the experiment? Who will do what analysis? Who will write? Will there be student assistants who can support data acquisition? It’s good to know these things early on.

Maintaining the collaboration

Schedule short status checks to show your collaborator that you have the project in view. If the work is done in your collaborator’s lab, ask for status updates if they are not provided. If the work is done in your lab, be proactive: let your collaborator know how it’s advancing regularly. If it is not advancing, let him know too, and explain the reasons.

If your lab members are involved, make sure they represent your lab in the way you expect. For instance, ask them to give you and the collaborator regular updates. Make sure they keep their deadlines, and communicate well in advance when they see that they can’t keep them.

If the collaboration goes well – and this mainly means: if everyone gets a long well, and mutual trust has developed – one collaboration will lead to another.

Handling problems and taking the exit

Not every collaboration goes the way you imagined. There might be personal issues. You might learn that you do not trust your collaborator, or that their work ethic differs from yours. It’s possible that your collaborator does not deliver what he promised, or passes deadlines by months.

Whatever the reason: if you notice early, bring it up in your meetings. Your collaborator might not be aware that he is not meeting your expectations. Or he might think that you are fine with how it’s going as long as you don’t complain. As PI, let your collaborating student know that you will support him if the collaboration becomes difficult. As a junior researcher, claim your supervisor’s support if you don’t get enough.

Yet, sometimes all the talking does not result in the changes you want to see. There can come a point at which the value of the collaboration has become too low for you to maintain it. Or, to say it in more colloquial words, at some point, it’s just annoying without benefits.

At that point, consider ending the collaboration. There might be some reasons that make you feel you can’t, such as if your collaborator is someone really important in the field whom you do not want to cross. But even then, think hard whether you can find a way to exit gracefully. If you can’t come up with a good solution, ask a mentor or a colleague you trust.

The more work has gone into a project, the less we are inclined to let it go. Yet, if the situation in the collaboration is such that success does not seem probable, any additional effort going into the project is too much.

Celebrate your wins

And because I don’t want to end with such depressing things as quitting collaborations, let’s instead end with something happy: when a collaboration ends successfully, don’t forget to thank your collaborators. A phone call or email can be adequate. Or a dinner with all project members at the next conference. Or raising a glass of sparkling wine over skype.

Now, all the best for your collaborations!

I’m sure there are more tips for collaborating, both from the view of the PI and of junior scientists. Please share them below by leaving a comment!


Others have discussed how to quit a collaboration if it doesn’t work anymore.

The book Essentialism: The Disciplined Pursuit of Less is a plea for reducing the number of things we do. Certainly something to consider when planning collaborations. Then again, don’t forget that collaborations build your network like nothing else.

Photo credit: DonkeyHotey / Foter.com / CC BY


This post is part of the open draft for the Research Group Leader Book [about] [read more].

Debriefing: two questions to ask when it’s all done

Most of the time, I’m more than glad when a project is all done and written up. Research projects can have this tendency to take too long and require a lot of breath towards their end. In a hurry to get it over with, it’s easy to forget to look back and evaluate what went well and what didn’t.


This post is part of the open draft for the Research Group Leader Book
[about] [read more]

In our scientific work, we are used to progress step by step. Each time an experiment doesn’t turn out the results we expected, we adjust methods and paradigm a little and try again.

But when it comes to the way we organize our teams and our projects, we often don’t show the same scrutiny. Maybe we’re just fed up with that project. Or it’s all the new stuff that’s already piled up. Either way, we forget to sit down with the project members and evaluate or debrief.

Although there are detailed schemes available, a project debriefing can be really simple. All you need to do is ask yourself, and your team, two really short questions:

What worked? And, what should we do different next time?

That’s all. Easy. And note, it’s about the positive just as it is about the negative. Just like any good feedback should be.

The two questions can apply to any aspect of organizing your projects, but here are a few examples:

  • Communication and supervision. Did everyone know what their responsibilities were, and did the supervisor delegate well? Was conflict dealt with adequately? What kind of communication worked well (email, skype, personal meetings…)? Was help available when needed?
  • Writing. Was authorship handled properly, e.g. did everyone know early on where they would land in the authors’ order? Did manuscript reviews go smoothly between all authors? How can writing together be improved?
  • Lab handling. Did everything work out with the technical setup? Are there any procedures that need to be changed, and communicated to others? Which procedures were good, and can be distilled into workflows that others should follow?

Of course, there may be many other aspects that merit discussion. Then again, it’s not necessary to make it a therapy process. Just don’t skip the debrief all together, and identify a few good things to keep, and the bad ones to throw out.

In some cases, a project evaluation may be part of the conversation you have during the personal evaluation meetings with your individual team members. Yet, if a project involved several people, debriefing together with the entire project team will provide more valuable input, and allow clearing up any hickups that may still await closure.

Do you have a routine for project evaluation? Tell us about it in the comments!


I think there’s a lot to learn from entrepreneurs and marketers. Jeff Walker presents the two questions in his video blog here.

Photo credit: Stocksnap>


This post is part of the open draft for the Research Group Leader Book [about] [read more].

Work-life balance and the sense of significance

I’ve spent a frantic week of trying to get things done before going on vacation. It’s reminded me that work-life balance doesn’t come easy.


I don’t know about you. I have this tendency to think that, before I go on a vacation, I should finish as much as possible. The result usually is that by the day the vacation starts, I am powered out. But at the same time, I haven’t been able to get all the things done I set out to do.

This last week was one of those weeks. I had impossible plans for myself (I won’t even bother to reveal what all I had on my list). Then, unexpectedly we received proofs for a new paper (“please return within 24 hours” — you know the drill); a draft came back from a co-author, opening up the possibility that it, too, could be finished before the vacation (not on the original list, mind you), and I had forgotten that I had promised a student to grade her thesis before I leave.

In the attempt to live up to my self-imposed goals, I skipped sports, spent far too little time with my family, and worked until late at night every day. Now, I’m out of balance, tired, and overworked.

When I left the office on Friday afternoon to start my vacation, one of my PhDs pulled up this cartoon for me – quite the perfect description for the trap I’d once again failed to avoid.

Why is it so easy to get wound up with too much work?

I think, it boils down to the sense of significance. There are actually two kinds of that. The first kind is the idea that my projects won’t run without me — I’m important for work. The other kind stems from the tendency to use work to define myself — work is important for me.

Step one on the way out is to put both in perspective: to take a deep breath and realize that my team members will do just fine while I’m gone; what wasn’t done now will get done next. And to re-evaluate and remember that work is great, but not all there is. To land back on earth and be realistic about how much can be done in a day.

Step two on the way out is to get back into a sustainable routine: get enough sleep, do sports, spend time with partner and family. Because I get more done when I’m rested, fit, and grounded in knowing that my kids couldn’t care less whether parietal cortex transforms skin-based coordinates into an external-spatial code or not, but get excited when I teach them to walk, practice riding a bike, or take them to watch Fack ju Göhte 2.

By chance, Stu McLaren and Michael Hyatt had a podcast episode on achieving work-life balance this week. I mean, talk about coincidence. Their podcast, This is your life, is of the kind that mostly reminds you of things you should know and do, but forgot and neglect. One of their main points was that balance is intentional. Unfortunately, it doesn’t just happen.

Chances are that as a science PI, you’re driven and used to pushing yourself to the limit. From time to time, ask yourself whether the pace you’re going at is sustainable.

Balance doesn’t just happen. But it happens quickly that you lose it.

Any thoughts you have on this are welcome. Use the comments section below!

Photo credit: Unsplash

Thinking together: pooling the team’s ideas for cooler research

A report about an ongoing attempt to change the flow of coming up with research ideas.

thinking together

In this post, I’ll share about how we’re experimenting with being creative in the lab.

Typical ways to develop new work programs

In the past, I’ve experienced mainly two ways of how new research programs were developed in science labs.

Model 1:
A more or less senior person, often the group head, more or less secretly comes up with more or less great new ideas, writes them up in a grant, gets the money, and then looks for someone to do the work. Thus,

  • ideas come from a single person
  • discussion about these ideas was minimal, or restricted to a few conversations, e.g. at a conference or with a mentor
  • criticism and improvement of the research ideas and their (e.g. experimental) implementation are sought at the implementation stage, that is, when a newly hired person starts working on moving the ideas from paper to the lab.

Model 2:
Ongoing research throws up some interesting, or at least unexplainable, discoveries. New work follows up to clear up the unknowns. Thus,

  • new work is directly related to current work; it is not visionary (what a big word…), but incremental.
  • The new work continues an existing line of thinking, and doesn’t connect to new fields. It specializes, but doesn’t broaden perspective.

A different way to develop research programs

In one of the podcasts I listen to (unfortunately, I can’t recall which one it was), I heard about a company that has all employees come together for a whole day once a month. There is a single rule: you can’t talk about your regular, day-to-day work.

Instead, the employees of that company talk about anything that is on — or comes to — their mind that normally gets pushed back due to the pressures of everyday workload and deadlines. The objectives of these meetings are to increase communication in the company, identify trends, collect ideas etc.

A slightly more organized approach

I was intrigued about the approach to explicitly cancel work for a day and to focus on a higher level of things, and decided to give it a try.

We organized a 3-day group retreat. Half of it was dedicated to discussion about “higher level” science ideas, with the explicit aim to get away from what we’re currently doing.

Here’s how we went about:

  • Everyone read 1-3 recent review papers that sounded interesting in preparation of the retreat. They were unrelated to current projects.
  • At the retreat, everyone gave a 15-20 min overview over the main points s/he learned from the paper(s), and what s/he found most interesting and promising.
  • Then, we teamed up in couples to discuss for an hour. This discussion had 3 aims:
    1. Try and find connections between the two topics of the two discussants.
    2. Try and find connections to our group’s current work: can we expand towards these fields; can we find new experimental paradigms from those fields; do these fields challenge our work and our assumptions in some way?
    3. Try and come up with experiment ideas, whether related to current work or not.
  • Everyone teamed up with everyone else, so we had several discussion rounds.
  • Each time, we wrote thoughts, ideas, difficulties etc. on flip charts.
  • At the end of the day, we wrapped up, with each small team recapping their discussion in 5 minutes. We created a mindmap of the day’s outcome.

The results were amazing.

We opened up entirely new roads of possible research. Although I took part in the discussions just like everyone else, the coolest ideas came from the teams in which I wasn’t a part. We have a mindmap of directions we can go, and we can take it out to form new experiments, and to add on still new ideas. And last not least, everyone felt that we had been able to discuss in a way that has just not been possible in our everyday lab life, even with communicative group meetings and journal clubs.

So, we’re now setting up monthly discussion days. I’m not sure yet whether and how we’ll structure those, but the aim is to step out of our daily routines, to continue building the mindmap, to expand our group’s horizon, and to pool together everyone’s ideas.

Model 3…

So, group creativity is an alternative to Models 1 and 2. Its characteristics are:

  • Ideas come from many people, each of them smart(er than the group head).
  • An idea’s potential, caveats, confounds, etc. are discussed well before implementation, and many eyes see much more than 2 or 4.
  • New research has a bigger chance of being visionary (yes! yes! again the big word!), and less incremental.
  • As a “side” effect, by the way, everyone in the team gains a broader horizon, new knowledge about less directly related scientific topics, and there is more communication between different projects in the lab.

Open questions

In a company, it might not be very important who came up with an idea, as long as the money comes rolling in at some point. In science, this is a bit different. Ideas are the core of a scientific career.

If ideas are thrown around freely in a big group like I suggest in this post, it is important to talk about how to make sure that credit is given to who deserves it. I think this is different than when you discuss ideas one-on-one with a team member, because it will be much harder to keep track of who said what.

We’re talking, for instance, about first and last author positions on papers. But more than that, imagine you’re a Postdoc at the stage of writing your first grant, and you find that the ideas that developed out of your input to group days — which you assumed would end up in your grant — turn out to be part of your supervisor’s new grant initiative.

It will not always be easy to reconstruct where an idea came from. And, let’s be realistic, seniors can be hard nuts about authorship. In your group, you’re the senior, and it’s your responsibility to be fair, in return for everyone letting out their creativity.

So, probably some form of write-up at the end of the day, summing up the major ideas and contributors, might be useful (though it feels like a creativity killer at the same time).

In my group, we’re just starting the discussion about these issues. I’ll post updates as we go along.

In the meantime, I’m really curious how ideas develop in your team. And, about whether and how you handle giving credit to originators of ideas. Post a comment in the box at the end of the page!

Photo credit: / Foter / CC BY-SA

The rule of 3 and 10: group life still working?

Humans like routine. Group life is no different. Before you know it, things just “go like that”, “work that way”, and “have always been like this”. Of course, routines break all the time. The rule of 3 and 10 predicts that routines stop working when the number of group members changes. But even if it doesn’t, rethinking group life from time to time keeps your group healthy.

still working?

Organic growth

Every group has its own life. You have certain meetings, certain ways to communicate, and certain ways to do things.

A lot of these aspects of group life develop by themselves, driven by the people of the team. Some things, of course, you decide in the beginning, such as the kind of meetings you will have and when.

Things stop working

Sometimes, what worked really well for a while just stops working. Meetings get so boring that you can hardly keep your eyes open, and people start texting instead of listening.

Communication fails: tasks are forgotten, important messages aren’t delivered.

Information becomes hard to find: team members just don’t find the info they need, and start reinventing the wheel.

Take action before it’s needed

If you look out for it, you can catch these kinds of decline well in advance. On a regular basis, ask yourself and your team whether things are still going well:

  • Are meetings still effective and instructive? Have the regular building blocks of your meetings become boring? Have they lost their purpose?
  • Are you even having the right meetings? Are the right people attending? Can some people stop attending?
  • Are the organically grown processes still efficient and effective? Where does information get lost, and where is the way things are done complicated or annoying?

Together with your team, find better ways and improve things. It doesn’t have to take long.

I put meeting evaluations on my calendar every 3 months, and just ask at the beginning of a meeting what everyone thinks could be done differently. Nothing’s built in stone.

The rule of 3 and 10

Grown group structures become obsolete especially when the number of team members changes. Phil Libin, the founder of Evernote, reports that pretty much all processes need overhaul whenever group size triples or reaches the next order of magnitude. So, from being alone to being 3; from 3 to 10; 10 to 30; 30 to 100.

In science, most groups won’t reach 100 members. But the lab I used to work in grew from 4 to 40 within some 7 years. I didn’t know the 3/10 rule, but looking back, I can see how things broke and needed fixing.

Group growth can go much faster than you anticipate. Over the last couple of years, my core group was 5 people, but we had a flow of student assistants, BSc and MSc students. In the blink of an eye, a group meeting grew from 5 to 15. And indeed, we changed the meeting structure. New people, new needs.

Keep your eyes and ears open.

Leave a note about how you go about changing your lab’s routines in the comments below!


The rule of 3 and 10 was passed on from Hiroshi Mikitani to Phil Libin, the founder of Evernote. Read more about it here.

Photo credit: jeffeaton / Foter / CC BY-SA

Book: Getting Things Done by David Allen

If you’re struggling with task management – keeping an overview, choosing what to do next, and finishing enough stuff – then Getting Things Done by David Allen is probably the first book to go to.

book getting things done

The book Getting Things Done by David Allen is a classic, and I find it a must-read if you are looking for ways to improve your productivity. The strength of the book is that it offers a complete system to approach to task planning.

The ultimate credo of the book is that you have to get stuff you need to remember (i.e., your todo list) out of your head into a “trusted system”. What Allen means by this is that you need to follow your system so consistently that you are never afraid that it won’t work. This frees up your head to be 100% on the task you decide to do at any given time. And if you follow the book’s advice, you can set up such a system. Warning: it can feel very anal, especially at first. But: if you do follow it, it’s really great.

5 steps to peace of mind…

Allen breaks up task planning into 5 steps:

  • capture anything that comes to mind that needs to be done, be it small or huge
  • clarify what you want to do with every single item you captured and identifying the next concrete action you need to do to move towards getting this thing done
  • organize by putting stuff where it belongs (and he has a very specific set of lists and places)
  • reflect, that is, review your lists, on a regular basis so that you always know what’s going on in your life
  • engage by choosing, from your lists, what to do right now.

There’s a lot more to each step, and Allen also goes into levels of planning, from how to organize today to identifying what you want to be or do with your life.

There’s a 2015 updated version of the book. If you believe what people are posting on the net, then it doesn’t really matter which version you read.

If you’ve read Getting Things Done, I’m curious about your thoughts. Have you implemented the system? What works? What doesn’t?

Related resources

David Allen has made a company out of his system, and they’re selling coaching and all kinds of related stuff.

There are many apps that are either designed to use GTD, or can be set up for GTD.

One such app for real enthusiasts (or nerds?) is Omnifocus (Mac/iOS).

Another one I really like is 2Do (Mac/iOS/Android).

David Allen explains his ideas quite well in several podcasts, for example in two episodes of Beyond the Todo List (one: www/iTunes; two: www/iTunes), and in an episode of [EntreLeadership][itunes-entre] ([www][web-entre-episode]/iTunes).

In the Evernote series of my hands-on section, I’ve described how you can set up Evernote for a pretty nifty GTD implementation.

Check out more book reviews!