-
Notifications
You must be signed in to change notification settings - Fork 20
/
saying_no.Rmd
55 lines (28 loc) · 20.1 KB
/
saying_no.Rmd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
# On Saying No
## Why say no
*This chapter is primarily focused towards academics conducting research. While it may apply to other fields, it discusses choosing which studies to conduct, which may be a privilege not afforded to other jobs. For this reason, please feel free to skip this chapter if you'd like.*^[Academics who have more hourly tweets than lifetime publications should stop reading this chapter and start writing more papers.]
Academia is built on uncertainty. This is most clearly evident in how our currency of published papers are evaluated - through anonymous reviewers that in many cases want different things from your paper which means that you may spend equal time writing the paper as revising it for the whims of reviewers, often in areas that don't actually address the core of the paper.^[The idea that reviewers are indeed anonymous is one lie that academics like to tell others in public but all should know to be false. The prevalence of working papers published on personal websites or preprint websites mean that few papers are truly anonymous. The insistence of certain reviewers to (pathetically) demand that several of their own papers be cited in the paper that they are reviewing (and the editor's acceptance of these ridiculous 'suggestions') also means that not all reviewers are anonymous.] But the most serious avenue of uncertainty for academics, and the least visible, is that you never know what you have to do to achieve your career goals. If you're a PhD student, how many papers do you need to be hired? If you're an assistant professor, how many papers or service committees do you need to get tenure? There is no clear answer - other than that "more is always better." For this reason, academics tend to say yes to everything.
Academics are *terrible* at saying no. This has become a (often playful or self-pitying) meme about how academics juggle too many things and can't focus (or have no free time). But it is, in my opinion, a serious problem in the field and one that's actually not that hard to solve.^[Over-extending oneself is often seen publicly in people's affiliations where one academic is affiliated to multiple organizations or causes and actually spends very little time doing any work on these affiliated projects.] In my experience, academics - and particularly early career academics - approach every offer to do something with the question "will this help me?" The answer is, in almost every case, YES. Almost everything that you're asked to do will help you.
This isn't to say that academics just accept everything for no reason. Part of the reason that I think academics accept doing so much is because so much turns out to be useless (in terms of career benefit) because many projects don't pan out - data sometimes can't answer your question at all, results may be non-significant (which shouldn't be a reason to kill a project but null results are harder to publish so some people don't try to publish them), co-authors stop responding to emails.^[If you are one of my co-authors who is currently waiting for my email, please be patient.] So by necessity you need to accept more than you think is necessary since you know that some of it won't work out. The second, and a major factor in this, is that the entire culture of academia supports always saying yes. And, importantly, people see agreeing to everything as demonstrating that you are providing "service" to your department and to the field by doing everything they ask for - even when saying yes actually makes you worse at doing each of the things you agreed to do. Another potential reason is that academia tends to come in waves. All the bad news tends to come at once, as does all the good news. Given this lack of consistency it makes sense to try to keep doing even more since you know that the good times never last - and the bad times can last for a very long time. ^[My first paper was accepted in its first round of reviews for the first journal it was submitted to. Every paper after that for two years was rejected.] It's easy to feel good about your work when you get good news and be willing to do more work. It's also easy - easier in fact - to be willing to do more work just to try to eventually get something with a positive outcome during the bad periods.
This book is focused on making research more efficient. Nearly everything in this book can be done manually - from subsetting data to webscraping, you can do it by hand - though doing so would be incredibly inefficient. Over-extending oneself, which is the inevitable outcome of not being able to say no to things, is also inefficient. Research takes time. If you have 10 active projects, you will be less effective than working on 3. If you're trying to solve a complicated programming question, like one you've encountered in this book, it may, for example, take you an hour to solve it. But this is an hour focusing on the problem and not being distracted by anything else. If you spend 30 minutes on it and then get distracted you may lose all the work (which in many cases in solving programming problems is all in your head, not writing code) you've done and have to start from scratch. To give another example, if you need to bake a cake for an hour you need to keep it in the oven the whole time. You can't put it in for 10 minutes and take it out then put it back it - you need to leave it to cook!
Research works the same way. You need to spend a lot of time focusing and thinking (literally just thinking, not writing or reading or anything visible. Just thinking about whether what you're doing makes sense and what it means) about the project to get it done. So splitting up that time is far more destructive to efficiency than it may seem if you believe that finishing a project is merely spending X hours on the project, no matter how you split up X.^[A small number of criminologists seem to put out an incredible number of papers each year. I commend their co-authors for this accomplishment.]
### The problem with (always) saying yes
There is also a good reason to say no even when you're not overwhelmed with work - you don't want to get a reputation for always saying yes. Saying yes all the time means that when someone is trying to figure out who to ask to do something that people don't want to do, they'll likely end up asking you since you're the easiest person to ask. If you, for example, always say yes to review requests then editors will likely send you an increasing amount of requests. If you always have time to serve on a committee, you're going to be asked to serve on more committees. So it's useful to say no (at least) every once in a while so you can avoid even being asked to do the unpleasant work that no one wants to do.^[My high school criminal law teacher said that a trick lawyers do when meeting with a new client is to *pretend* to be on the phone with someone as the client walked into their office. So the client thought that the lawyer was busy and in demand, and would therefore respect them and their time more. For academics, if you don't respect your own time (e.g. being available for everything) then why should anyone else?]
## When to say no
As an academic - even for early graduate students - there is a growing number of things you're asked to do: teach classes, attend class, serve on committees, do research many different research projects with many different people, give lectures to other people's classes, present at conferences, review papers, etc. Doing everything is unfeasible - so you need a way to narrow down what you want to do. Some of these are mandatory - you need to, for example, write papers and teach classes as a professor. For the optional items, I think that it is important to determine your short and long term goals and use them to guide your choices. If, for example, you're a professor at a teaching university where research requirements are light, then there is no need to do a lot of research unless you like doing it. Personally I enjoy doing research and don't see the need to network much so I turn down requests to guest lecture or present my research and focus on writing papers. Even once you chose your goals, you may still have too many things you're asked or expected to do. So how do you narrow it down further? For the most part, you don't. There is no foolproof way to rank or choose the most valuable projects but below are some ways I've used that I think will be helpful.
As you become more experienced with the field you get to know what (broadly speaking) timelines are for certain types of projects and the reward you get from it (e.g. novel research is generally considered more important than replication research). So you can get a very rough sketch of where a project will go and how long it will take. Though, of course these estimates can be very off - and generally everything takes much longer than expected. This will be helpful at least in managing your time since you're be better able to estimate when you've reached maximum capacity - once you have, just say no to all future projects until you've finished these. This is something that you can really only learn through experience or by talking to someone who has more experience.
If you don't want to do something, don't do it. Really. Some unpleasant tasks are unavoidable but when given the choice between an unpleasant tasks and an enjoyable one, chose the enjoyable one. You'll be happier and work better for it.
A major part of the pleasantness of a task is who you do it with or for. There are some awful people in academia. Truly awful people - and people who may be influential in the field. These run the gamut from those who will belittle you to the sexual predators at conferences - or among their own graduate students - and everything in between.^[In academia you can - in some cases - make up data or, as a professor, sexually harass or have sexual relationships with your graduate students and you'll be rewarded with journal editorship or at least keep your job just as long as you publish well or already have tenure.] It seems obvious to say, but don't work with these people. Even if these people are on the lower end of the awful spectrum, and if they could potentially help your career in the future, don't work with them. From a work standpoint, you will do your best work with people who respect you and will build you up. From a personal standpoint, you should (I hope) want to work with smart people who are fun to work with. Don't allow yourself to live by a lower standard!
Finally, **public labor is more valuable than private labor.** This is important. Your reputation as an academic is built in large part based on what you do in public. If you spend a month writing the greatest paper ever but never publish it, you've essentially wasted a month. The question for me when a request comes is "what will I have to show for it?" And I mean show very literally. If someone can't read it (e.g. a paper) or see it (e.g. a conference talk) or use it (e.g. an R package) then I am not interested in doing it.^[Just so I don't seem entirely heartless, I've received about 150 emails from people (mostly grad students) asking me questions about the data I released and I've responded to almost all of them. There's actually a lot of good documentation on the data that I've compiled from the FBI so it's pretty easy to know who read the manual before emailing me and who didn't.] When given the choice between doing public work such as writing a paper or private work such as being on an internal committee, the public work is almost always going to be better for your career - though maybe not better for your particular goals so you need to clearly understand what your goal is. One major exception to this is in being a reviewer for a journal. Reviewing is anonymous except to the editor but is necessary for the field to function so I recommend doing it when asked and if you believe you can review the paper well. However, as this is anonymous work, keep it limited - you *don't* need to review every paper you're asked to review. And if you did, expect even more review requests since the editor will know that you'll always review.
### What is mandatory and what is optional?
A key question in deciding what to say no to is determining which requests are mandatory and which are optional. The problem is that it's often very unclear which is which because so much in academia is vague requests that you're never quite sure about, a problem exacerbated by the power differential in most relationships. For example, say you're a grad student and I email you and ask you to do a task that'll take you six hours to do. And now imagine that your adviser asks you to do the exact same task (and this task is not related to any project you're working on or a class or anything in your contract). Which is mandatory and which is optional? Obviously if I email you then it's optional since I'm just a random person with no power over you. When your advisor asks you, is it optional? Here it's much less clear. The task isn't related to a class or ongoing project or in your contract so it's not explicitly required for you to do. But your advisor also can affect your graduation and career prospects, and in academia the custom is usually that you do what your advisor says when they ask you to do something. So in this case the line between mandatory and optional is blurry.
Now, what if someone senior in your field or a funder asks you to do something - say, attend a roundtable they're putting on. These seem pretty clearly optional. However, you may know (and this is true) that some funders will ask you to do work for free and then pay you for later work. That senior person in your field may have access to resources, or may be a tenure letter writer, so it'd be better to get on their good side by saying yes. These two are certainly optional but there are, as there is with any decision, tradeoffs to saying yes or no. And, as with many things in academia, tradeoffs whose true ramifications may not be known for a long time. This is made even trickier because the costs - e.g. time to do the work - are generally immediate while any benefit is generally long term.
In cases of blurriness, how do you know if it's actually mandatory or if it's optional? One easy way is to ask. If your advisor asks you to do something like in the above example, you can ask if it's required to do (if you feel it necessary maybe say something like you have a lot of ongoing projects as a reason you're not able to do it unless it's necessary). Since that gives a lot of power to the person making the request, I prefer to just say no. If it's actually mandatory then they'll tell me. If it's optional then saying no is the end of it. For requests like in the second example, they are optional so the choice now is whether doing the work is worth it.
### What a manageable academic workload looks like
It's hard to give a definition that'll suit everyone's unique circumstances but I consider it being able to work substantially on the project in the near future without added stress or guilt.^[Near future, of course, is defined by what you consider "near" to be.] I think the ending part is really the key feature. If I ask you to do something and saying yes adds stress or guilt (say, because you will have to push something else aside to do it) to your life, you are under an unmanageable workload. In these cases, it's best to reject any added requests until you're done with something you've already started (or end a project you've started. But don't overextend yourself). This is, of course, a very simple definition but one that I think is versitile enough to be useful to a broad group of readers and easy enough to understand to be applicable.
One particularly annoying part of academia I've noticed is that people tend to do far more than they're capable of because of the quiet agreement that everything takes a very long time. If, for example, there's a yearlong break during a research project, that's totally fine according to the customs of the field. I find this to be particularly problematic as both a researcher and a criminologist (the problems we're trying to solve should have the urgency they require.). Certainly this is, in large part, a personal choice in how I approach work, but I think it goes beyond choice into ensuring good research. Consider the first research project you've done (or the most recent one). Can you remember every single decision you made in cleaning data or conducting an analysis? When you look at the code you've written for the project, does everything make sense? I'd guess the answer is no. Research is often pretty complicated so taking breaks during projects can introduce potentially large problems into your research. If, for example, you understand while examining the data that a particular variable is flawed, you may chose to not use it in your study. But if you take a six month break in the project, will you still remember that issue? Considering how many criminology papers are published, and how often authors tend to divide the research and trust that the person doing the data did it right, I believe this is a serious problem.^[I am extremely familiar with the UCR data released by the FBI and from my reading of the literature using this data, a significant chunk of papers on this topic are wrong (by how much is unclear, but their refusal to even address the limitations makes me extremely suspicious of their results.).] This problem is more that simply theoretical. Lots of sloppy work occurs in criminology research, partially due to how people decide to allocate their time. So for this reason I'd go a step further in defining a manageable academic workload. If this project cannot be a priority of yours, it is something you should pass on - for the good of the research in our field.
## How to say no
This seems obvious. If you don't want to do something - or don't have the time to do it well - just decline an offer. Be polite, thank them for the offer and then say no. If you feel the need to explain yourself - you don't! - then say something like you have too many projects at the moment and can't do this new thing. When you say no, just say no. Just consider it another of the many lies like "thank you to the reviewers for their helpful comments." If someone asks you to do something, they either value your work and input or are just using you since they know you'll say yes. In the first case, they won't look negatively upon you for saying no - and if they do, they aren't someone you want to work with.^[Personally, I'd be much more likely to work with someone if I knew they prioritized a few key projects rather than work a tiny bit on many projects and took forever to finish any of them.] In the second case, not working with them is certainly the good choice.
If any of this - that the way to say no is to say no - seems facetious, it isn't. Saying no simply, promptly, and politely is, in my opinion, the best way to do it. Doing so will also reduce the level of uncertainty for others since they will have a clear - and importantly, prompt - decision from you and can ask someone else.
### Ending ongoing projects
While this chapter focuses on saying no when initially asked, it is occasionally important to end participation in ongoing projects. In general I'd advise again doing this without a good reason - and the best reason is that you don't have time to do the project well or quickly enough for your collaborators. When you do have to end your involvement in these projects I'd recommend doing so the same as saying no to a request: do so politely, promptly (as soon as you have made your decision) and simply. I'd probably give a reason you're quitting but there's no need for an elaborate explanation, just keep it simple. Your collaborators will appreciate knowing as soon as possible so they can proceed with the project - if they are greatly offended by your decision, they generally aren't the people you want to work with anyways. If you're involved with parts of the project that only you know (e.g. if you did some code work), I'd also recommend producing some documentation so the remaining people in the project can carry on from your work. If the project is likely to end in a published paper, this is the time to discuss authorship in the resulting product and how your leaving affects that.