Tagged delegate

Four common mistakes in delegation

Delegating can be the Number One time saver, but it does have its traps. Even after several years of heading my group, there is still lots of space for improvement for me. Here, I’ll cover how you can avoid four common mistakes with delegating. Let’s make life just a little easier…

mistakes in delegating

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

Delegation is the Number One strategy of freeing up your time, so that you can focus on doing what’s most important and what you do best (I discuss more strategies here). I guess, it’s also everyone’s dream before they become a leader: Once I am the boss, I’ll tell everyone what to do… Well. As it turns out, this can be harder than one might think.

Mistake 1: Not delegating (enough)

Once you are in that admirable position of being able to delegate, doubts start creeping into your head:
Can the person I hired really do this task well? Without all the knowledge that I have collected over the last years, it’s impossible to do it well! And besides, I can do it so much faster than this new PhD student, so I should just do it myself.

Chances are you know the feeling: no one can do anything as well, or as fast, as you can.

This is the biggest mistake of all that you can make with delegating. It keeps you trapped in the everyday tedious tasks that eat up lots of time. It feels important to do them (and it is!), but too little time remains to do all the things that come with leading: planning; supervising; writing.

Often, we’re stuck in our old routines, and, without thinking, we execute whatever tasks lay before us. Here are 5 steps that help you identify which tasks you should delegate.

  1. Get an overview. Write down all the things you have done in the last one or two weeks. Try to catch everything, especially all the little stuff.
  2. Identify recurrences. On your list, identify all tasks that recur regularly. These are prime candidates for delegation. First, you will save time every time the item recurs and someone else does it for you. Second, given the recurrence, it’s well worth teaching someone else how to do it.
  3. Find what you do best. Make a new list. Write down those things that you do best. Try to avoid biasing your list towards the what I’ve done recently list; this new list should be more of a what I’d do if I could freely choose list. Compare this new list with the old list. Those things that overlap between the two lists are things you probably shouldn’t delegate. Your aim is to have only these kinds of tasks on your todo list.
  4. Sort out what you can. Re-examine your first list (the what I’ve done recently list) once more. There are now probably items on there that weren’t recurring, but that also aren’t on your wish list. For each item, think hard whether it is something that you have to do yourself, and that can be done so fast that teaching someone else to do it is not worth it.
    My experience is that there are many items that at first feel like I must do them myself. Often, though, I realize that someone else can do them just as well. Consider, for instance, handling finances, hiring student assistants, or checking out choices and getting quotes for a new lab device.
  5. Improve continually. Once you’ve made a start by identifying tasks that can be delegated, make it a habit to ask yourself with everything you do: is this something I can potentially delegate, or does it belong to my core responsibilities and to the things I do best?

Mistake 2: Not taking enough time for teaching

Delegating can go wrong. You’ve handed a task to someone, and the result is not what you wanted. In the worst case, you have to run after the whole thing and clean up a mess.

As a consequence, next time, you do the task yourself again. But, with this strategy, chances are some unloved tasks will stick with you.

When you first delegate a task that requires either special knowledge or skill, you will first have to invest time and work. This is a common hurdle, because in the beginning it feels as if delegating takes more time than doing things yourself. This is true, but temporary.

It is important to invest the time and effort to teach the person you delegate to. Only then can s/he successfully do the task. And you’ll have peace of mind.

Mistake 3: Not communicating clearly

The other day, I needed to find the best option for a product we needed in our group. Luckily, I remembered that I don’t have to do everything myself, and delegated the task to one of my PhD students. In my mind, I’d get the info about the best product in a day or two. Instead, I got a long email with a lot of links to many different products, with the friendly note that I could now look at all of them.

Clearly, I had failed to communicate my requirements and expectations.
When communicating what you want, let the person know what result you want to receive, and at what point you want to be back in the loop.

Michael Hyatt distinguishes 5 levels of delegation:

  1. Do exactly what I tell you. You give step-by-step instructions, and expect that they will be followed. No room for creativity.
  2. Research the topic, report back, I decide. Someone does the collecting for you.
  3. Research, outline the options, make a recommendation. Here, you want the person to actually think.
  4. Make a decision, then tell me what you did. You trust the person you’re delegating to with the task. You only want to make sure you can step on the brake if you disagree after all.
  5. Make a decision, act, no reporting necessary. This works either with unimportant things that you really don’t care about, or with people who are competent with the task at hand and whom you fully trust.

Besides defining the result you want back, it is often useful to set a deadline. Some management people insist that every delegated task must have a deadline. Of course, we all know we only start things the day before a deadline. So the assumption seems to be that without a deadline, the task would never be done. So, if you experience that your delegated tasks often don’t get done, try out deadlines.

When delegating a task, let the person know what you want and need. It’s useful to

  • summarize at the end of a delegating conversation
  • ask the person what she thinks she is supposed to do (and correct if wrong)
  • and to leave room for questions.

While these points may sound self-evident, they really are not, when you distribute tasks via Email, or shout out your request in a hurry before you run elsewhere.

Remember: It’s important for the person to know exactly what you want. If they don’t know, they’ll make their assumptions, and those might be right. Or not.

Mistake 4: Not following up on your delegated tasks

It’s crucial to keep track of the tasks you’ve delegated. So, keep a list. If you use the Getting Things Done system, then you’ll tag every task you delegate with the waiting context, and also tag it with the person you’ve delegated to.
(If you don’t know what GTD is, you can read about it in this post; and about implementing it in Evernote here.)

Why is it important to follow up on delegated tasks?
First, you want to be sure that they got done.
Second, by following up on each and every task, you create a culture in which it is clear that you are serious about the tasks you distribute.
Third, with many tasks, you’ll want to check the results or base a decision on the outcome.

An easy way to keep track of finished delegated tasks is to ask your team members to email you when they are done.

Have you experienced difficulties with delegating to your team? Do you have useful tips? Leave a comment for everyone to read!


Michael Hyatt has podcasted and blogged quite a bit about delegation, for instance, The fine art of delegation and How to do more of what you love (and less of what you don’t).

Hyatt also has an episode about delegating if you don’t have a team to delegate to. Interesting. Not all of it will work in the science world, but some might. After all, we never have enough people to do the all work!

Manager Tools Basics podcast has a couple of episodes on delegation. These guys talk much, but their advice is very helpful.

Delegation is but one of many ways to recover time for yourself. I’ve written about some others in my post Remove yourself: start leading, stop micro-managing

Photo credit: Skley / Foter / CC BY-ND


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

Remove yourself: start leading, stop micro-managing

When you were a PhD and Postdoc, you became an expert for the scientific methods you used for your research. Stepping up the career ladder as a group leader, you use your hands-on scientific expertise less and less, and your work is dominated by conceptual planning and team leadership. I’ve said before that the step from Postdoc to research group leader is very similar to that from expert to small business leader: the most important step of the entrepreneur is to remove himself from the everyday business.

remove yourself

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

Any business depends on its owner – but, as Michael Gerber explains in his book The E-myth, often for the wrong reason!

Gerber explains that the biggest mistake small business owners make is that they stick to doing expert work, that is, the work they used to do so well that they decided to base their own business on it. This ties them up, and they aren’t free to do the work for which their business should really depend on them: leading and expanding.

As leader of your research group, you face the same challenge: to get stuck in the day-to-day research and to fail stepping up to steer. The solution is to systematically “remove yourself” from the research work. A weird thing to say, isn’t it? Yet, before I started leading my own research group, those who already did consistently told me that my work would change. So, rather than waiting until you can’t wait any longer, make it an explicit aim from the start: remove yourself.

3 reasons to remove yourself

Why would you consider to remove yourself? There’s at least 3 important reasons.

Your job description has changed

First and foremost, you now employ people who do the operative work. Your role in the group is to lead. Some of the tasks that come with being a group leader are rather obvious, such as making decisions and structuring everyone’s responsibilities. But maybe the more important part is that you now have to grow and develop your group. This means that you have to write and revise many more papers than before; decide when you need new people and new money, and write the grants for it; make sure that your team members develop new skills and expertise and coach them. You simply won’t have time for operative work anymore.

The idea of scale

In business, scale refers to doing more of the same simply by adding one more. One more McDonald’s. With one more set of employees who have exactly the same functions as those in all other McDonald’s franchises. Look at my post on Michael Gerber’s book, the E-Myth, which lays out the idea of scale for small businesses in more detail.

The idea of scale ports directly to your research group. It means that you have to make sure that you can get more research done by simply adding new people to the team. This will only be possible if the work in your lab does not depend on you. If you have to train every new lab member yourself, then there’s a tight limit to the number of new people that can join. If you have to invest significant time into every project that is running in your lab, then the number of projects is seriously limited.

Make your group sustainable even in times when you can’t be there

remove yourself – but stay in controlAs you climb up the career ladder, you’ll have more stuff going on outside the lab: talk and conference invitations, review boards, administrative meetings etc. You’d like to be sure that work gets done when you can’t be there.

You might find that writing and planning – of which you’ll presumably be doing more than before – is easier in other places than the office, and decide to work at home on some days.

And if you are planning to take a break from work or to reduce your working hours to raise children, this point is especially important. You’ll be much more calm about being gone if you know that your group’s work continues, and that you will be notified only when it doesn’t.

So why am I still here?

As the leader of your group, your main responsibility is to steer where the whole thing is going. Of course “removing yourself” cannot mean that you have nothing to do with your group anymore. It means that you stop doing the operative work that you used to do and for which you became expert during your PhD and Postdoc time. Yes, you drop all that to free yourself for a different kind of work: planning, expanding, guiding, supervising, thinking, and writing.

6 strategies to remove yourself

How can you set up your group in such a way that you can remove yourself? Although you want to be able to be gone, the research group is still your baby, and you have to be in control.

I’ll give a brief list of strategies, and pick each point up again in separate posts later on.

  • Delegate. The most obvious thing to do is to hand off as many tasks as you can to your team. Your work should be the things that a) only you can do, and b) you do best. This means that you have to hire the right people – those who can take over as much as possible of all other tasks. I’ve written about delegation here.
  • Templates, Workflows, and Instructions. Create documentation of the knowledge that is necessary to do the research right. I’ve posted about this here.
  • Create a group culture. When you aren’t there, then your team must make its own decisions. You would like those decisions to be the same ones you would have made yourself. The way to ensure that is to have a group vision and culture. If you and your team share the same priorities and values, then everyone will make compatible decisions. Development of a group culture requires explicit communication with the team.
  • Set up an organizational structure. It must be clear who is responsible for what; who can answer what questions; what kind of events may be handled entirely without you (and by who); and for what kind of things you want to be kept in the loop, or make the final decision. You can delegate some leadership roles to some of your group members, e.g. Postdocs. Make sure they know what you expect of them, and where their competence ends.
  • Set up communication. Make sure you can be reached. For example, hand out your mobile number, or have an emergency email address for your team that you check even when you don’t check other email. Everyone should know how to best forward information to you. There are many interesting options for team communication besides Email, such as Evernote, Slack, Gitlab, Google Docs, and Asana. I’ve posted on being available here.
  • Set up regular meetings. It is essential to have regular meetings with the group, and with each team member. Many business people recommend weekly One-on-Ones with individual teams members; I’ve found that this is good for new lab members, but can be too much later on.
What strategies are you using to remove yourself? Share it in the comments!

Photo credits: walking up stairs: Pexels; waving woman: Starbug / Foter / CC BY


I’ve mentioned Michael Gerber’s book, the E-Myth, in several posts, for example in my review of the book, and in The Scientist as an Entrepreneur.

Tim Ferriss has written a lot about the idea of removing yourself in his book, The 4-hour workweek. The book’s aim is rather different from this post’s, but it is full of thought-provoking ideas that can be used for our purposes.


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

Three ways to make sure knowledge stays in your group

I had a shocking experience recently. Within a week, my three PhD students all told me that they were thinking of leaving the group and going elsewhere when they’re done. Who’s going to do their work? And how??

When you started your group, things probably developed somewhat “naturally”. Without really planning for it, your group develops “a way we do things around here”.

Your group members know things you don’t

In my group, each PhD student has specialized beyond my own expertise. This means, they know more than I do. At least about the specific methods they are applying in our current experiments. In the beginning, I tried to keep up and learn with them. This started with technical things; for example, we use motion trackers to monitor movements of human participants. With my last grant, I had bought a new brand. Besides having to figure out the complicated setup, we had to re-write our Matlab code to control online measurements and data transfer. Today, I wouldn’t be able to run an experiment without the help of my PhDs.

But their knowledge monopoly doesn’t end with technical things. It continues with expertise about data analysis, experience in how data should look so that they are usable, and many other aspects of everyday scientific work.

So, when my three PhDs leave… well, I really don’t want to finish this sentence.

Document what your group is doing

People turn-over is high in science, with our short-term contracts on third-party funding, so my PhD disappearance problem is definitely not a one-time mishap. So, how can I retain the knowledge in my group? How can I make sure I consistently get similar quality in all the work done in my lab?

The answer is threefold: workflows, instructions, and templates. All three are types of documentation. Will you be surprised when I mention that I got these ideas reading business books?


A workflow is a series of steps that have to be taken to complete some task. You can think big and small.

For a big example, in my group we’ve created a workflow for running an experiment. It has all the steps that need to be done from creating a standard folder structure; Evernote documentation folders; documentation of idea, goals, computer code; instructions about what steps must be discussed with me or in the group; …

For a small example, we have a workflow for giving a contract to a new student assistant.

So I can see you thinking: running an experiment? I don’t need written instructions for that! But have you ever tried to find a file in the idiosyncratic folder structure one of your PhDs came up with, because there weren’t defined places of where specific files should go? Have you ever forgotten to check the experimental setup before your master student started acquiring data, only to find later that there was a cardinal mistake in the setup?

Multiply these “accidents” by 10 when you have a new lab member. Multiply by 100 when your team changes completely.

And have I mentioned how much time you save when you don’t have to explain everything to the new guy yourself, but he can go to a document and only return to you with a couple of things he didn’t understand?


Document how things are done. For the new motion tracker I mentioned, my PhDs created detailed instructions about how to set it up. You can use photos, mark things on them, and make detailed lists. Seriously: the more detailed the instructions, the less will go wrong the next time someone new has to do it the first time.

Write lists for things that need to be done regularly. For example, we have a list of what all needs to be done when we clean the lab.


These are masks that you can use over and over. You can use templates in quite a few situations.

If you have to contact a lot of people, such as to recruit them for experiments, you can have email templates.

We have a set of templates for the consent forms our participants must sign before they can take part in our experiments. Every time someone starts a new experiment, all they have to do is get the doc and adjust a few lines.

There are ethical guidelines about what all you have to tell your participants when you instruct them for experiments. We have a template so that no one forgets any of the required info.

I’m sure you can think of more.

Nice. But we don’t have time for this.

My group didn’t love me for it when I introduced workflows and instructions. It’s extra work.

We were lucky, because we had documented here and there already in Evernote. Those documents weren’t always complete and up to date. But we could use them as a start.

Your documentation will build over time. You don’t have to do it over night – unless you wait too long, until your PhDs have one foot out the door. So start now – the earlier, the better. If you are starting a new group, ask your group members to create re-usable workflows from the beginning, and then use them the next time they do the same task. Then they can revise and optimize them continuously with little extra effort.

Making it a priority to document all your lab’s best practices in is central to retaining knowledge in your group.

Does your group document workflows, instructions, and templates? If not, then why? What other things do you document? Use the comments section to let us know!


Michael Gerber takes documentation to the extreme in his book, The E-Myth Revisited. His point is that the more everything is standardized by documentation, the easier it is to scale, that is, have someone do the same thing again elsewhere, because you don’t have to be there yourself to make it happen. The classic example is a franchise. Every McDonald’s is the same. Obviously, not really what we want in research. But it’s worth looking at what all you can at least consider to document and standardize.

Michael Hyatt suggests using email signatures to create templates for replies you repeat often. Instead, you can use tools like TextExpander that paste arbitrarily long and complex text when you type a shortcut.

This article in PC Magazine has a long list of tips about how to write good workflows.

A picture is worth 1,000 words. If you need to document a lot of stuff on-screen, then Skitch might help; it integrates with Evernote. But there are plenty of other solutions, such as Clarify-it and Jing.

There are some fancy (but rather pricey) online tools to create pretty workflows. But a txt file, Word doc, or my favorite, Evernote, will do.


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

Book: The E-Myth Revisited by Michael Gerber

This book about how entrepreneurs can build a successful and scalable business has lots of insight for a science team leader.

book cover emyth

Michael Gerber’s book, The E-Myth Revisited, has been an eye-opener for me.

At first sight, it has nothing to do with a science group. Gerber talks about new small business owners, and how they screw up and fail within the first few years of their endeavor. And then about what they can do to succeed with their business.

The key idea of the book is that the job of a business owner is very different from the job of a specialist. But before becoming their own boss, most small business owners are specialists, and then attempt to build their own business based on their expertise. They then make the mistake of doing the same as they did before – being a specialist – instead of becoming the head of their new business.

Why does that matter to a scientist?

You’ve probably realized now why the book is relevant to a science leader: we basically go the same path. First, we are specialists. Then, we become group leaders – boss of our very own “small business”. The big mistake we can make is to not fill that leading role, and instead try to continue being a specialist.

The two points I find most important in Gerber’s book are, first, that you have to build a vision about what you actually want your business to be. The second point is that you have to systematically remove yourself from the everyday work of your business. Of course, you don’t disappear, but your planning and actions have to follow this ultimate goal: to be free of the operative work, so that you can shape the business.

I’ve written more on the idea of removing yourself and porting Gerber’s ideas from a small business to a science lab in a blog post, Remove yourself: how to be free for leading without losing control. Suffice it to say, although the book reads a bit cheesy, it provides lots of food for thought.

Check out the book here.

If you’ve read the book, post your comments below!

Check out more book reviews!