LearnMoore

 

 

Moore

Accuracy

Lab

at Berkeley-Haas




Home
People
Research
Press
Opportunities
Teaching

Blog

Book



Google Scholar
Open Science Framework
ORCID
Haas webpage

Tips for Successful Collaboration with Don

 

1          Joining the lab

 

See answers to Frequently Asked Questions about joining the lab here.

 

 

2          While working with me

2.1          The point of everything

The overarching goal of everything we do is to better understand human and organizational decision making. In the day-to-day life of academia, our dedication to this big goal may sometimes be difficult to discern: it may look like we’re engaging in idle academic discussions about minutiae, getting hung up on mundane methodological details, spending a lot of time battling red tape, and chasing publications. But we do all of these things because they are the most effective way we have discovered to further our overarching goal of pursuing the truth. It helps to remind yourself of this whenever the demands of everyday work are a source of frustration.

2.2       Communication

I value prompt communication, and my favorite communications medium is email.  I will endeavor to respond to your emails within a day.  If I ask you something via email, I will be grateful if you respond within a day.  If you need more time to accomplish what I have asked, please reply promptly with a forecast of time to completion.  I value accuracy far more than optimism—your forecast should accurately anticipate how long it will take you to complete the assignment. 

If it turns out that your original forecast was overly optimistic and you need longer than you originally forecast, please update your forecast.  Do not just let the project slide and hope that I will not notice your failure to deliver. 

If you have asked me something via email and I have failed to respond within a couple of days, you should feel free to remind me that you are waiting for a response from me.  I will be grateful for your reminder. 

An email auto-response message is helpful if you expect to be away from email for some time. 

 

2.3          Respecting participants

The people who participate in our research are essential to the process. Our work is only made possible by their participation. They are generous in giving their time; we are therefore grateful to them and want to treat them with respect and courtesy: be nice to them and treat them as the smart, interesting, kind, and generous people they are. If a participant wants to speak to a member of the research team with a comment or concern, we want to always give them that opportunity. Serious concerns and any adverse events (e.g. angry participants) should be brought to my attention immediately.

2.4          Being healthy and happy

Your health and happiness are more important than any research project. I expect you to work hard, but whenever work gets in the way of you being healthy and happy, please let me know. If you are aware of specific things that you want to change, I’m eager to discuss with you whether and how we can make those changes; if you are dissatisfied but don’t know what you want to change, I am eager to brainstorm with you about possibilities. I will also always be supportive of you seeking health care--physical or mental.

This also applies to vacations; you’re entitled to your vacation time and need not be shy about asking for it. I ask you to let me know in advance when and for how long you want to take vacations, and to have project needs in mind when making those plans. I’m happy to discuss possibilities for making things work if you want to go away during crunch-time.

Relatedly, family and close relationships are also more important than research. If you need to take time off unexpectedly for reasons related to family matters, please let me know.

2.5       Being honest

The most important principles governing our work together are honesty, trust, and communication. Working together in our lab implies that we will get to know each other’s quirks. This might be scary if it reveals our foibles. At the same time, it may be liberating, because it means that you might as well just be yourself from the start. This has a number of implications.

First, it means that nobody can make themselves seem more or less smart than they really are. The rest of the group knows it already, for better or worse. I hope this frees you up to put genuine understanding at the center of your interactions: you don’t have to pretend to understand when you don’t, and you should ask questions.

A second, related implication is that we can own up to our mistakes. All of us get things wrong all the time; coding errors are the most common incarnation, but it ranges from forgetting meetings to missing deadlines. Knowing that it happens to everyone makes it less jarring to admit to it, and easier to deal with it promptly.

Putting it crudely: You will inevitably make mistakes, and I will probably find out about them. I will make mistakes, and you will find out about them. What we can control is whether we deal with them constructively: by actively identifying them, owning up to them as soon as possible, and fixing them.

Third, this honesty also makes it easier to trust each other. Our group is fortunate to operate in a high-trust equilibrium: it’s safe to assume that everyone else has your best interests at heart. When you ask them for help, they will usually be glad to give it; they expect the same of you. This also includes me: Once you are part of the group, you can trust that I will do what I can to help you complete your work, advance your career, and have good work/life balance. Conversely, I trust that you put a solid effort into completing your work and don’t free-ride off of others. One example of this is work hours: we don’t police each other in terms of how many hours we work; the crucial point is whether or not the work gets done. As long as our work is moving as expected, I won’t care much if you come in late, leave early, or decide to work elsewhere for periods of time (although this should be discussed with me in advance).

2.6        Managing back

It is difficult for me to see how hard you are working, so I ask you to tell me if you need more work or if you are working too much. I also rely on you to tell me what you think is going well or wrong with particular projects, or with our working relationship. I don’t take such feedback personally and will never blow up; if something isn’t going well, I want to work with you to fix it.

I ask the same of you when I give you feedback about your work.

2.7          Driving projects forward

When we work together on a project, my goal is to give you a lot of ownership and for us to interact as colleagues. It is more interesting and educational for both of us if you think actively and critically about what we are doing. This will also make it more likely that you make the sort of sustained intellectual contribution that could earn co-authorship. (The latter is not a guarantee.)

An important aspect of this kind of participation is driving projects forward proactively. When you think we are at the stage where input from me is needed to move the project along, please don’t wait for me to reach out; instead, set up a meeting proactively, get it on a meeting agenda, and tell me what you think the project needs in general, and what you need from me to make that happen.

2.8          Scheduling time with me

If you’re my student, postdoc, or research assistant, I will always make time to meet with you. Scheduling works best by email.

2.9         Professional development

Once we have started working together, I consider it part of my job to help you achieve your goals, and in particular, get the position of your choice after our time working together. Because it’s your life and not mine, you get to pick your goals, and I will support you whatever you decide to do. Working with me on research is most useful to those who intend an academic career path, but that is not the only path. I encourage you to share your thoughts and plans with me as early and frequently as you wish.

2.10      Reference letters

If you have worked with me for at least two semesters and we have had regular interactions during that time, I consider it part of my job description to write reference letters for you for the remainder of my career. You don’t have to apologize when asking for them.

Sometimes it will happen that we didn’t work together particularly well, and I may not be able to write a strong letter. If that’s the case, I will tell you in advance, so that you can ask others if you want to.

When you ask for a letter, please send me a CV, transcripts, SAT/GRE scores if you have them (nothing formal is required, just mentioning them is enough), and the statement of purpose or other motivational document if the application required you to write one.

I ask that you give me at least two weeks to write your letter; if you give me less time I will try to make it but can’t guarantee it. Once you have asked me for a letter and I have said that I will do it, you have license and are encouraged to remind me about getting it done. This is especially true in the days before the deadline.

It helps greatly if you send me a list of the places where you are applying, and where applicable enter me in all the relevant application systems in a single session, so that I have all the request emails in one place.

 

3          Collaboration

The very worst collaborators are those who say they will help but who do not. It doesn't matter how good their intentions were.

Terrible collaborators simply do not respond to requests for help.

Poor collaborators eventually help, but only after long delays and many reminders.

Mediocre collaborators note problems but offer no coherent solutions: "This is broken.  Fix it."

Good collaborators identify problems and tell others to fix them: "This could be better. Here's how you should improve it."

Great collaborators identify work that needs to be done and do it themselves.  "I found a problem and here's how I fixed it."

 

 

Many thanks to Johannes Haushofer for his inspiration on this document.