A Researcher’s Guide to Successful Teamwork

AUTHORS:

Katie-Coral Sicora

Katie-Coral leads all marketing and customer engagement efforts, focusing on providing valuable resources to all current and prospective Dedoosers. Before Dedoose, Katie-Coral worked in communication strategy at a market research firm.

Eli Lieber

Dr. Eli Lieber is the Co-Founder and CEO of Dedoose. As a quantitative Psychologist and mixed methods expert, Eli runs a methods lab out of UCLA where he advises researchers on best practices with Dedoose Co-Founder Dr. Thomas Weisner.

But, what if it looked more like this…

Here’s how…

INTRODUCTION:

Teamwork. It often brings to mind motivational posters hanging in old high school locker rooms…

…this quintessential image:

…or the adage

We are raised on quotes that praise working together. Margaret Mead said, ‘Never doubt that a small group of dedicated citizens can change the world. Indeed it is the only thing that ever has.’ At the same time, we often chuckle at Milton Berle’s comment that ‘A committee is a group that takes minutes, but loses hours.’

It’s funny because for so many of us…well, it’s true.

Teamwork: ...ugh!

There is no denying that teamwork is important and necessary for project success the world over. Distributing the load often allows us to accomplish so much more.

So why do we so often find stress abound when working in teams? Is it that this idea of teams runs counter culturally to our rugged individualism? Is it that we fear the freeloader? Is it that we generally worry that how we will be perceived will jeopardize our future with the higher ups? Or is it maybe that we simply do not want to manage people and all the dramatic conflicts that can arise.

Wait:

Now, some of you out there are thinking, ‘Teamwork is my middle name!’ These ‘team players’ are real people – they are not mythical creatures as popular belief would have it. However, even the greatest team players are at risk of conflicts and meltdowns when their team faces a difficult task.

Regardless of whether you are a team player or a negative Nancy, teamwork is the reality of academic research today. In a recent poll of our users, we found that 89% of them are working with or as part of a team to conduct their research.

Before we go further—what is teamwork anyway? For the purpose of this discussion, teamwork will be defined as a group coming together for a common purpose, each with individual tasks that are dependent on other team members for success and for the team to succeed overall. Let’s run with that.

CHAPTER 1:

Evaluation & Planning

When it comes to putting together a plan, it is always easier said than done.

Ultimately, you want to find the right balance between what you have and what you need so that you and your team can produce as much as possible, on time and on budget.

So…how? It all starts with a solid understanding of what you are trying to accomplish, evaluating what you have and what you will need to get there, and then working up a plan to make it happen. Let’s get started!

If you do not have a focused end goal, you will have a very difficult time building and executing an efficient plan with the most effective team. When we advise academic research teams, we find that those who struggle in the middle of projects often did not take the time to properly prepare. They did not think through their goals and resources and fairly assess what they could really expect to accomplish.

Evaluation

Every project team is different because every study is unique, but when teams start their research with us, we ask a couple questions to assess the situation:

• What are the research questions?
• What do we want to have accomplished at the end of the study?
• Who will be the audience to whom we will be presenting our results?

Once you have a better idea of what you want, you can ask two more tough questions that will help you decide a plan of action:

• What is the timeline?
• What resources do I have?

NOTE: Resources here can include: time, money, experience/past knowledge, team/partner skills, team/partner aptitude, etc.

Planning

The variety of mixed methods and qualitative research studies can run the gambit. We will not identify or outline specific plans here, but wanted to take a moment to offer one GIANT piece of advice and a few reminders that we think are critical to the process of crafting a solid plan.

In your plan, you should include the 30,000 foot view, all starting with the research question and other issues outlined on the evaluation page in mind:

1. The kinds of data that will allow you to present the strongest case in supporting your arguments.
2. Sampling—who should I be collecting data from to push your best case forward?
3. Your method of collecting, organizing, integrating, and analyzing your data.
4. Data collection and/or analysis software. Remember that if you are not using a cloud based solution for your software you need to add additional budget to ensure that all team members have the right software and the right EDITION of the software.

And don't forget about your

Timeline & Budget

• Hiring
• Training
• Data collection
• Data management
• Code book creation & inter-rater reliability testing
• Excerpting/code application
• Data analysis
• Writing your paper or crafting your presentation
• Grant reporting, if necessary
• Last, but not least – FUN and teambuilding!

CHAPTER 2:

Hiring and Training Your Team

Who do you want to hire? You must first start by evaluating your current skills and/or the skills of any team members or partners you already have on board. Then you can set clearly set expectations and goals, distribute the workload, and measure individual and team success.

Evaluating Your Current Team

If you have a team in place, it is time to take a lock, stock, and barrel evaluation of your staff. Where will each member be most effective? This evaluation will effect far more than you might realize.

__For example,__ make sure that you consider the data collection structure. If you have a team that is more experienced, open ended interview questions could yield more fruitful responses. Yet, it is harder to train a researcher to capture data with open ended and free flowing conversation. It is by far easier to have a structured dialogue where uniform questions are created ahead of time, albeit the data from such an approach do not allow research participants to respond in more natural and free-flowing ways. Yet, __having this structure will make it easier to break in new team members.__

Think about your team set-up, experience, training costs, data needs, and then make the decision that is best for the project.

Setting Clear Expectations:

While flexibility is necessary for a team to run smoothly, there should be a general understanding of what is needed so that team members can better understand what their roles are and how to succeed.

If there are no such measures, there is no way for any team member to anticipate how their contributions will be assessed. This absence of information or confusion often leads to unnecessary stress in the lower ranks of the team and increased stress often translates to poorer performance.

Distribute the Work

So, it is time to distribute the work!

When giving assignments, make sure that team members understand their role and build in checks and balances to ensure that work is done properly. As you establish protocols, processes, code books, etc. you want to make sure that these checks and balances are working to guarantee that everyone is keeping a high level of agreement. Use Cohen’s Kappa, for example, to help you track the code application agreement between team members. Dedoose offers Cohen’s Kappa in the Training Center so that you can assess and continually monitor your team’s coding performance.

Continuing to Evaluate Your Team

If you are on a longer project, it is particularly helpful to keep evaluating your team. Keep thinking about the strengths and weaknesses of each team member as the team reaches certain milestones.

How you mentor each member will often help them rise above where they were and provide even more value to your team and project—and they’ll love the way that feels too.

CHAPTER 3:

Building a Culture

When objectivity is a goal—and it should be wherever you want to argue that you’ve implemented systematic scientific rigor in your work—it is paramount that your team will speak up with their thoughts and concerns throughout the research process. That kind of team culture does not come automatically. Rather, its growth is facilitated by the team leader, project manager, principal investigator, etc., and it is brought to life by the team as a whole.

Fostering a culture of open communication requires that everyone on the team gets to know each other on a deep, authentic level.

Our experience has shown that team cultures with clear and open communication show the greatest success.

‘R.E.S.P.E.C.T. Find out what it means to me.’ ~ Aretha Franklin

Creating an Environment of Trust & Respect

When doing collaborative work, trying to include everyone’s voice at an equal level can be a challenge. Everyone has to feel comfortable speaking up.

Because of the hierarchy that exists in many academic teams, there will undoubtedly be a situation where those on the lower end of the totem pole will be quiet when it might be in the best interest of the research project to speak up.

Fostering this ‘equal voice’ idea is tough enough for teams in Western cultures (leaning more toward individualism) and if you are working internationally in countries where the social structures can be more hierarchical (leaning toward more collectivism), it can be worse.

Our users often share that they work with researchers in cultures where it is uncouth or socially dangerous to speak against those in power. So, some members due to cultural predisposition will not make a peep.

You must actively work to correct this to have an effective team that collaborates in an effective way or the whole effort to develop objectivity will look suspiciously like the idiosyncratic or subjective views of just the few ‘powerful’ characters in the room.

In the end, it takes communicating the idea that respect will go both ways and this respect is expected, valued, and critical for the success of the project. There will be respect given to those higher on the totem pole, but they will also trust the opinions and findings of those lower on the totem pole. Once this trust and respect balance is in place, your team members will be able to use their voices in the best interest of the team.

It might feel a bit forced when you start out, but you will be on your way to creating this culture if you consider the following tips:

• Talk about the rules – respect, trust, and hard work.
• Expect that the team is ‘in it to win it.’
• Conduct team meetings where everyone shares.
• Conduct team meetings where everyone listens.
• Have someone take notes so that key goals and findings discussed are available for everyone to help ensures proper communication should someone miss the meeting.

CHAPTER 4:

Communicating – Codes & Excerpts

One of the top areas where we see teams face a great deal of trouble is when it comes to creating and sticking to how everyone uses a code system.

While we will not go into too much depth on developing the code system and code book with all the rules and guides here (we will save that for a later publication), we can offer some key advice.

Communicating excerpting and coding guidelines is vital to a successful research team.

When you set out to create your code book, and periodically once the code book is created, check in on the following topics:

1. Style: Chunking vs. Splitting: Teach/discuss excerpting and code application styles. Will you excerpt chunks of text and apply multiple codes or will you excerpt only a handful of words and apply only one or few codes at a time?
2. Code Application Criteria: One great practice is to start building your code book by having each team member build codes on their own and then comparing everyone’s efforts. You might find that certain labels work better than others. Once the code tree is established, continue to re-visit what should be included and what should be excluded when thinking about where each code should be applied (or not).
3. Documenting Examples: Create definitions of each code using memos and link these using your software tool to the excerpts themselves so that team members have a solid idea of how a code should be used and some real examples from the data to see what it looks like in the context of the research participants’ voices. You might have some turn over on a team, so having all this documented will help get new people up to speed.
4. Work Distribution: It can be a great strategy to have one part of your team master one part of the code book.

NOTE: Team Code Application Agreement Matters

One of the biggest mistakes teams make when it checks and balances on consistency:

It’s not enough to say that work is valid – you will be expected to provide evidence that it is. Working in a team is a great way to validate and ‘objectify’ your findings. If each person on the team has helped to objectively create the code book and there has been a code application test applied such as Cohen’s Kappa Coefficient, the findings carry more weight and credibility.

When our staff reviews journal submissions for example, if there is no clear documentation of the code system application criteria and some indexing for levels of agreement across team members (i.e., Cohen’s Kappa or Krippendorf’s Alpha), there is no way that a paper will be recommended for publication.

CHAPTER 5:

Keep it FUN

Teams that truly get to know one another are more successful over all. It is especially important to build time into your schedule for getting to know your team outside of research project-land.

That means team-building activities.

Teams that truly get to know one another are more successful over all. It is especially important to build time into your schedule for getting to know your team outside of research project-land.

Create opportunities to let team members share who they are with the rest of the team. We are not suggesting a show-and-tell session (though that could be pretty fun). Simply hold activities outside of the work space. Go to lunch once a month and have a different team member pick the restaurant. If you have a team member with a particularly extensive knowledge of local architecture, go on a campus walk. If you have a surfer, brave the shoreline together.

Working Remotely...

Now, some of you may work remotely too. Fun team building activities are not limited to being in one physical location together. Connection is even more important when we work in different locations and use research tools like Dedoose to connect.

Our staff here at Dedoose work from all over the place – from the office, to our living rooms or home offices, to hotels around the country (or…yikes… airport lounges) when we are travelling to conferences. We keep it fun with Google Hangout. You can put funny hats and glasses on the image of yourself using this platform that leads to a good chuckle and keeps the conversation lively.

We spoke to some of our users about what they do to keep their teams whistling while they work.

Check out these ideas to keep teamwork rundown from affecting your team:

• Hold a happy hour –- this works virtually too! L&M Policy Research (we love this user group), hold ‘Dedoose Happy Hours.’ The team logs into Dedoose to ‘have drink together’ over Skype or Google Hangout.
• Hold a book club –- Pick a book or series that is FUN to read such as Harry Potter or Hunger Games. We’ve seen users that have gone with a research methods book and found (surprisingly…) that teams found it to be less appealing.
• Make team shirts –- T-shirts can bring groups together and remind them they share a common identity in working together towards the same goal.
• Check out these team building games:

http://www.teachmeteamwork.com/teachmeteamwork/free.html

Note:

Team building, ice breakers, and getting to know you games are not always that fun. It’s true. Sometimes people would even call them a waste of time, lame, or stupid. Yet, they work. They get teams to get to know one other in a deeper more authentic way. And, it is a risk. You might not have a great idea, but go after doing something fun anyway. You might be surprised.

Sometimes the bonding comes from the communal feeling of not wanting to do the activity.

Staff Story:

Naming the Friday Meeting

We had a contest to name our Friday meeting which all staff were required to attend for team building activities. We each emailed in our ideas to one person on staff who organized a vote. No one wanted to do this at all…mostly because calling the only team meeting on Friday the ‘Friday Meeting’ seemed to be good enough for us. While we understood that some e-book out there somewhere told our boss to do something ‘fun’ and let the team name the meeting, we gave him a hard time. The winner ended up being: ‘TimTimmity’s-Super-Fragalistic-Awesome-Pretty-Cool-Fun-Time-Meeting.’ Looking back, this ridiculous contest worked… because it was an idea that we all thought it to be totally lame. We were being brats, but we were brats together. Even though we continued to call it the ‘Friday Meeting,” every time I saw that silly calendar reminder pop up with the outrageous name it brightened my day. In retrospect, it was fun, it did bring us closer as a team, and I am still sharing the story today.