This module builds the skills and frameworks for working in effective, diverse, and interdisciplinary research teams. Through real case studies from science and engineering, you’ll learn evidence-based strategies for collaboration, practice peer evaluation with CATME, and develop a Team Charter that addresses the actual challenges interdisciplinary teams face.
Primary Reference: Bennett, L.M. & Gadlin, H. Collaboration and Team Science Field Guide, NIH.
| # | Lecture | Case Study | Field Guide Ch. | Deliverable |
|---|---|---|---|---|
| 1 | CATME & Peer Evaluation | — | — | CATME Rater Practice |
| 2 | Team Formation & Shared Standards | Apollo 13 | 4–5 | Team Charter Draft |
| 3 | When the Tools Change the Work | AI detection failure | 7 | Team Charter — extended draft |
| 4 | Cross-Disciplinary Communication | AlphaFold | 6–7 | Skills Inventory |
| 5 | Credit, Conflict & Accountability | Transistor + BCS Theory | 8, 10 | Contribution Plan |
| 6 | Trust Under Pressure | Challenger + COVID Vaccine | 5, 9, 12 | Final Team Charter |
Two threads build across the module:
Team Charter (evolves across 3 lectures)
| Lecture | Milestone |
|---|---|
| 2 | Draft: communication protocols, roles, meeting schedule, problem-raising process |
| 3 | Extension: tooling decisions (knowledge management, AI use norms, coordination tools, version control) |
| 4 | Revision: updated with skills inventory and communication needs |
| 6 | Final: comprehensive document incorporating CATME insights, contribution plan, workflow design, and tooling commitments |
CATME Peer Evaluation (4 cycles across the semester)
| Evaluation | Timing | Grade Impact |
|---|---|---|
| Rater Practice | Lecture 1 | None |
| Evaluation 1 | After Module 1 | None — formative |
| Evaluation 2 | After Module 2 | None — formative |
| Evaluation 3 | After Module 3 | None — formative |
| Evaluation 4 | End of semester | Multiplier applied |
Research and teaching experience consistently show that teams of 3 produce the best dynamics in project-based courses. With teams of 4, one person often disengages; with teams of 5, the problem compounds. Three is large enough for genuine collaboration and diverse perspectives but small enough that everyone must contribute — there’s nowhere to hide.
For a class of ~25 students, this means approximately 8 teams of 3 (with one team of 4 if enrollment doesn’t divide evenly). Teams stay together for the full semester. Continuity matters: the investment you make in learning to work together pays off only if you stick with it through the difficult middle phase.
Lecture 1: CATME & Peer Evaluation</summary>
This lecture introduces CATME as both a practical tool you’ll use this semester and a window into how peer accountability works in professional research teams.
The biggest effect of peer evaluation isn’t the grade adjustment — it’s that you know it’s coming. Research consistently shows that the anticipation of peer evaluation changes team behavior more than the evaluation itself. When you know your teammates will independently rate you on specific observable behaviors, the social cost of free-riding becomes concrete.
CATME evaluates teams across five behaviorally anchored dimensions. Each dimension describes specific, observable behaviors at each level — you’re not rating how much you “like” a teammate, but whether their actions match particular descriptions.
The Five CATME Teamwork Dimensions:
In a perfectly functioning team, each member is expected to be at the middle description. Save the higher ratings for teammates who truly exceeded expectations, and the lower ratings for when expectations genuinely were not met.
A rating of 3 means: “This person did their job well. They met deadlines, contributed their share, and communicated effectively.” That is a good rating. It describes a competent, reliable teammate.
A rating of 5 means: “This person did something exceptional — they architected the core approach, resolved a critical problem that stalled the team, or contributed far beyond their share.” This should be rare.
A rating of 1–2 means: “This person’s work required others to redo it, or they didn’t engage meaningfully.” This should also be rare — and if you’re giving it, you should leave specific comments explaining why.
If you rate everyone a 4 or 5, you’re not providing useful information. You’re making it impossible for the instructor to identify teams that need help, and you’re robbing teammates of honest feedback that could help them grow.
CATME allows peer-to-peer comments that are released anonymously to teammates. Good feedback is:
Consider the compliment sandwich for written feedback: acknowledge something positive, suggest an area for improvement, and end with encouragement or confidence in future work.
Generative AI tools are now part of many research environments. In this course, one basic principle applies: AI use in team settings must be transparent to teammates.
The key question is not whether you used AI, but how you used it and whether that use changed the nature of your contribution. Using AI to brainstorm, reorganize notes, or clean up prose after doing the underlying thinking is different from using AI to produce a draft that the rest of the team must verify, rewrite, or repair.
Peer evaluation is based on observable contribution, communication, accountability, and quality control. AI does not remove those responsibilities. When you share work with your team, you are expected to:
This course does not ban AI in teamwork. The goal is to prevent AI from becoming a source of hidden labor, unequal contribution, or confusion about authorship and responsibility. You will revisit these questions in later modules as writing, peer review, and research ethics issues.
| Evaluation | Timing | Purpose | Grade Impact |
|---|---|---|---|
| Rater Practice | Lecture 1 | Learn the system; practice with hypothetical teammates | None |
| Evaluation 1 | After Module 1 presentations | Early formative feedback; establish baseline | None — purely feedback |
| Evaluation 2 | After Module 2 deliverable | Mid-semester check; identify issues while there’s time to change | None — purely feedback |
| Evaluation 3 | After Module 3 deliverable | Late formative; final chance to adjust | None — purely feedback |
| Evaluation 4 | End of semester | Full-semester summative evaluation | Grade multiplier applied |
Why only the final evaluation affects grades: Early evaluations are about learning and improving — not punishment. If you receive lower ratings early on, that’s useful information, not a penalty. The system is designed so you can act on feedback and improve before it matters for your grade.
Completion is mandatory. Every team member must complete each evaluation by the deadline. Late submissions receive a 5-point deduction on the associated project grade — because your teammates’ grade adjustments cannot be calculated until everyone has submitted.
After receiving your CATME feedback, you’ll answer three questions (submitted individually on Blackboard):
These reflections are private (only the instructor sees them) and are designed to help you process feedback constructively rather than defensively.
CATME automatically flags unusual rating patterns for the instructor:
These flags trigger instructor review and conversation, not automatic penalties.
The final CATME evaluation produces a grade multiplier applied to team project scores. Here’s how it works in practice:
The multiplier drops self-evaluations from the calculation. Your grade adjustment is based entirely on how your teammates rated you, not on how you rated yourself.
Example: If your team earns 90 on a project and your multiplier is 1.02, your individual score is 91.8. If your multiplier is 0.95, your score is 85.5.
CATME walkthrough (~15 min): Demonstration of the system, five dimensions, and rating scales. Key message: the middle is the expectation, not the floor.
Rater Practice (~20 min): Complete CATME’s game-based rating simulation with hypothetical teammates. Pay attention to where the system tells you your ratings were too generous or too harsh.
Rater Practice debrief and free-rider scenario discussion (~18 min): Brief debrief on Rater Practice patterns (~3 min): where did your ratings diverge from the “correct” answers, and why is the middle so hard to use? Then turn to the free-rider scenario you read before class. The scenario is meant to make the rater practice harder: real teammates do not come with correct answers. Walk through the five CATME dimensions for the character “Alex” based only on the scenario evidence, and identify the assumptions you are making to assign each rating. Discussion connects to Field Guide Ch. 11 (“One Bad Apple”) and to the Team Charter norms students will draft in Lecture 2.
AI and team accountability scenario (~12 min): Small groups discuss a short scenario: one teammate uses AI to draft a section quickly, but the draft includes unsupported claims and fabricated references that others must fix. Which CATME dimensions are affected? What should that teammate have disclosed? Does “working fast” count as contribution if it creates hidden verification labor for others?
Discussion: Giving honest feedback (~15 min): Practice writing one positive and one constructive comment for a hypothetical teammate. Include one version of the exercise involving AI-assisted work. Workshop the comments in pairs: Is it specific? Is it actionable? Is it respectful? Connection to peer review in Module 2 (scientific writing).
Complete CATME Rater Practice before next class. Come to Lecture 3 prepared to propose one provisional team norm for transparent AI use that can be incorporated into your Team Charter revision. First formative peer evaluation opens after Module 1 presentations.
</details>
Lecture 2: Team Formation & Shared Standards</summary>
Case Study: Apollo 13 (April 1970) — Fifty-five hours into the mission, an oxygen tank in the service module exploded. The mission was 200,000 miles from Earth. Mission Control structured the response around four flight directors rotating through 12-hour shifts; multiple parallel “tiger teams” working specific problems (oxygen, power, trajectory, CO2 scrubbing); explicit norms about not making the situation worse through guesswork; and empowered individual controllers making real-time calls within their domains of authority. All three crew members returned alive on April 17, 1970.
Case discussion: Apollo 13 (~20 min): Brief instructor note: students may bring assumptions from the 1995 film. “Failure is not an option” was a screenwriter’s line, not a real quote from the mission. The actual recordings show calmer, more procedural language. The teamwork lessons are in the structure — flight director rotation, tiger teams, controller authority — not in the dramatic moments. What about the structure made fast, distributed decision-making possible without descending into chaos?
Team formation & ice-breaker (~20 min): Teams are announced. Interview exercise: each team member interviews another for 5 minutes about their background, why they chose this program, their research interests, and something unexpected about themselves (favorite breakfast cereal, hidden talent, etc.). Then introduce your partner to the group.
“Unit conversion” exercise (~15 min): Each team member identifies one disciplinary assumption they hold that teammates from other fields might not share. (e.g., What does “validated” mean in your field? What counts as a “complete” deliverable?) Then, connecting to the case: What does “unsafe” mean in your field? What evidence would you need to see before telling your advisor you don’t think an experiment, analysis, or submission should proceed?
Team Charter drafting (~25 min): Begin drafting your charter with specific protocols for communication tools, response time expectations, meeting schedule, and a process for raising concerns. Include a specific protocol for what happens when one team member raises a serious concern that others initially disagree with. The protocol should specify: how the concern gets documented, who needs to be informed, and what consensus or escalation looks like before the team proceeds.
Team Charter Draft (due next week) — Must include: communication tools and response time expectations, role assignments, meeting schedule, and a specific protocol for raising and resolving concerns.
</details>
Lecture 3: When the Tools Change the Work</summary>
Case Study: The Frontiers Retracted Figure (February 2024) — A peer-reviewed paper passed through three authors, two reviewers, and one editor before publication. The figure it contained was generated by AI, was disclosed as AI-generated in the figure caption, and was anatomically impossible — an absurdly proportioned rat with nonsense labels formed by AI hallucination. The figure was published anyway. Public mockery on social media within hours forced retraction within two days. The case is sometimes told as “AI made up an image and got published.” It is more usefully told as “AI use was disclosed correctly and the verification chain failed at every layer.” That distinction is the point of this lecture.
Tool decisions are team governance decisions. Most graduate teams make those decisions by accident — by which member happens to know which tool, by inertia from a previous project, by following whoever speaks first. The cost of accidental tool decisions is rarely visible until the team is several months in and the asymmetries have hardened. This lecture’s job is making the underlying decisions explicit before that happens.
Framing: tools as team governance (~5 min): Five failure modes that follow from implicit tool decisions: asymmetric tool fluency, verification labor, documentation choices, coordination friction, and tool selection as governance. Each is a teamwork problem, not a technology problem.
Tool category survey with team implications (~12 min): Brief walk through four categories — knowledge management (shared notes, lab notebooks), literature management (reference managers, shared annotations), meeting coordination (calendaring, agenda-keeping, follow-up tracking), and version control on conceptual documents (proposals, papers, shared writing). For each: what does the team’s choice determine? Specific products mentioned where relevant, but the discussion is about what the team commits to documenting, sharing, and tracking.
Case discussion: the Frontiers retraction (~13 min): Walk through the five-layer verification failure. The figure was disclosed as AI-generated. The disclosure was followed correctly. And it did not prevent the failure. Discussion prompt: what is the difference between a team having a disclosure norm and a team having a verification protocol? Connect to the deference pattern — “someone else upstream or downstream will catch it” — and to the Challenger case students will see in Lecture 6, where review existed but did not function.
AI detection: the classroom evidence (~10 min): Present the empirical data from this course’s prior cohort. Three AI models — Claude, DeepSeek, and Qwen — were tested on their ability to distinguish AI-written peer reviews from human-written ones. Detection accuracy: 0–20% across all three models. Discussion prompt: You will not reliably know when your teammates are using AI. Given that, what must your team’s norms be? The norms cannot be “we will detect and flag AI use” because detection does not work. The norms have to be about disclosure, about verification, and about what the team commits to checking regardless of whether AI was disclosed.
Team tool audit activity (~15 min): Each team identifies its current implicit tool stack. Where is knowledge being stored? Where is literature being tracked? How are meetings being coordinated? Then: where is the asymmetry? Which teammate is doing more of which kind of coordination labor without the rest of the team noticing? Which tool decisions has the team made without realizing it was a decision?
Drafting tooling section of Team Charter (~20 min): The Team Charter draft from Lecture 2 is extended in this lecture with a tooling section covering: knowledge management decisions, literature management norms, meeting coordination practices, version control commitments, AI use disclosure norms, the team’s verification protocol for AI-assisted work, and a mid-semester tool-revision checkpoint — the process by which the team will reconsider any tool decision that stops working. Static inventories age badly; living protocols do not. The charter section ends with: who has authority to call the team to revisit a tool decision, what triggers a revision discussion, and how the team decides whether to switch.
Buffer (~5 min) — for discussion that runs over.
Team Charter — extended draft. The charter draft from Lecture 2, extended with the tooling section described above. Single document, not a separate addendum. The full charter continues to evolve through Lectures 4, 5, and 6, with this lecture establishing the infrastructure layer.
The skills inventory exercise in Lecture 4 (AlphaFold) presupposes that teams have an infrastructure for sharing knowledge, tracking decisions, and making cross-disciplinary discussion legible. Lecture 3 establishes that infrastructure. Teams that have committed to specific knowledge management and literature management practices in their charter will produce a substantively better Skills Inventory in Lecture 4 because they will have a place to put it.
</details>
Lecture 4: Cross-Disciplinary Communication</summary>
Case Study: AlphaFold (2016–2024) — DeepMind built a small interdisciplinary team of structural biologists, physicists, and machine learning researchers to solve the protein folding problem. The team won the 2024 Nobel Prize in Chemistry after predicting structures for over 200 million proteins. The popular narrative treats AlphaFold as a clean success of “genuine interdisciplinary integration.” The actual record is more interesting and more useful as a teaching case, because the team’s path was not straight.
Three tensions in the historical record matter for understanding how the integration actually worked:
Case discussion: where the team almost failed (~20 min): What did the AlphaFold 1 → AlphaFold 2 redesign require of the team — both technically and in terms of internal trust? Most teams iterate when their first attempt only narrowly succeeds; this team rebuilt. What conditions allow a team to make that decision? Discussion connects to Field Guide Ch. 6 on shared vision: a team that does not share a vision cannot make a decision like this, because half of them will see it as failure and half as a fresh start.
Case discussion: what “integration” actually meant (~15 min): The popular framing — “they built biological knowledge into the architecture” — is a conclusion, not a description of how it happened. The actual integration required ML researchers to develop biological intuition, biologists to develop comfort with neural-network architecture decisions, and multiple internal reorganizations of how the disciplines related. Pull this apart: what does “integration” demand of individual team members, beyond just “communicating across disciplines”?
Skills inventory exercise (~25 min): Each team member presents (3 min each): What methods, tools, and frameworks do you bring? What are you not comfortable leading? What terminology from your field might confuse others? Then a second pass (1 min each): What is one thing from another teammate’s discipline that you would need to develop genuine intuition for, not just understand at a surface level, to do excellent integrated work with them?
“Translation” exercise (~15 min): Pick one concept from the team’s project. Each member explains how they’d approach it from their discipline. Identify overlaps and gaps. Connect to the AlphaFold case: where in your team’s integration would you face the same kind of decision DeepMind faced — biologists provide constraints vs. everyone develops cross-disciplinary intuition?
Team Charter revision (~5 min): Briefly note what should be added to the charter based on today’s discussion. Full revision happens between lectures.
Skills Inventory (one page per team) — Lists each member’s expertise, tools, blind spots, preferred communication style, and one cross-disciplinary skill the team will commit to building together. Submitted via Blackboard.
</details>
Lecture 5: Credit, Conflict & Accountability</summary>
Paired Case Studies: Same Lead Scientist, Two Different Teams
This lecture uses an unusual pairing: John Bardeen led both teams, separated by ten years and one Nobel Prize. The teams produced very different outcomes. The pairing forces students to identify what changed — leadership style, institutional setting, role clarity, or something deeper.
Case 1 — Bardeen, Brattain, and Shockley (Bell Labs, 1947–1948). A three-person team produced the first transistor and shared the 1956 Nobel Prize. The team also dissolved within four years. The breakthrough happened while Shockley, the group leader, was away from the lab; the patent listed only Bardeen and Brattain. Shockley spent the following weeks working alone in a Chicago hotel room, developed a competing design, and afterward redirected the work in ways that pushed his teammates to the periphery. The team had no early agreement on attribution and no process for handling the question once it became urgent.
Case 2 — Bardeen, Cooper, and Schrieffer (University of Illinois, 1955–1957). After leaving Bell Labs, Bardeen assembled a new three-person team — himself, postdoctoral fellow Leon Cooper, and graduate student J. Robert Schrieffer — to attack superconductivity. They produced the BCS theory and shared the 1972 Nobel. The collaboration is remembered for the opposite reasons: Bardeen’s quiet, collegial leadership; alphabetical authorship with no senior author designation; and a famous moment when Schrieffer wanted to quit and Bardeen told him to take a month and think without the senior author looking over his shoulder.
Framing the pairing (~5 min): Same scientist, ten years apart, two very different team outcomes. What changed?
Case 1 discussion: the Shockley team (~18 min): Open with a brief framing for the cohort: “You don’t need to understand semiconductors to analyze this case. The technical question is just whether the team had a process for deciding who was an inventor — they didn’t.” Was the failure that Shockley behaved badly, or that the team had no process for deciding attribution? What should the team have agreed on in 1945, before any breakthrough? How does the patent system’s binary “inventor / not inventor” decision interact with the gradient nature of actual scientific contribution?
Case 2 discussion: the BCS team (~13 min): Similar framing: “The physics detail does not matter. This case is about how a professor responded when his graduate student wanted to quit.” Bardeen could have insisted Schrieffer keep working, or taken the project over himself. He did neither. What does that decision say about how he understood his role on the team?
Comparative analysis (~8 min): Same Bardeen. Bell Labs in 1947, Illinois in 1957. Where did the difference come from — leadership style, institutional setting, role clarity, the personalities of the other team members, or something else? Connect the answer to your own team.
CATME midterm reflection (~10 min): By this point, students have completed 1–2 formative CATME evaluations. Brief team huddle: where did your self-rating differ from peer ratings? What specific change will you make for the second half of the semester?
Drafting the Contribution Plan (~20 min): Using the Field Guide’s “Prenup for Scientists” template, teams draft a contribution and authorship plan for the final project. Specify: who leads each section, how to handle unequal contributions, and how to resolve credit disagreements before they happen.
Contribution and Authorship Plan (one page per team) — Specifies individual responsibilities, credit allocation principles, and a specific process for resolving disputes.
The CRISPR patent dispute (Doudna/Charpentier vs. Broad) is treated in Module 4 (Ethics) as a case about institutional credit, IP, and the divergence between scientific and legal recognition. That case raises the same vocabulary — “credit,” “first,” “inventor” — but operates at a different scale and asks different questions. Holding the two cases in different modules lets students see that team credit problems and institutional/ethical credit problems are distinct, even when they look similar.
</details>
Lecture 6: Trust Under Pressure</summary>
Paired Case Studies: When Trust Holds Under Pressure, and When It Breaks
Two crises, fifteen years apart. In one, a team carrying €400 million in debt extended unprecedented trust to a corporate partner before the legal agreement was finalized — and produced the first mRNA vaccine for COVID-19 in eleven months. In the other, an engineering team’s documented concerns were overridden by managers in a five-minute caucus, and seven astronauts died seventy-three seconds after launch.
The cases sit at opposite ends of a single spectrum: when stakes are high and the clock is running, what conditions allow trust to expand, and what conditions make it collapse?
Case 1 — Challenger and the Night-Before Teleconference (January 27, 1986). Roger Boisjoly and Arnie Thompson, engineers at Morton Thiokol, presented data showing the SRB O-rings were likely to fail at the forecast launch temperature. Thiokol’s initial recommendation was not to launch. NASA managers pushed back. In a five-minute caucus, Senior VP Jerald Mason told VP of Engineering Bob Lund, “Take off your engineering hat and put on your management hat.” Lund changed his recommendation. The engineers were not asked to sign. Trust between the engineering and management sides of the same organization collapsed, and trust between Thiokol and NASA Marshall was revealed never to have rested on shared standards in the first place.
Case 2 — BioNTech and Pfizer (2020). Project Lightspeed launched in March 2020. BioNTech (1,300 employees, headquartered in Germany) needed a manufacturing and distribution partner; Pfizer (70,000 employees) had global capacity. Uğur Şahin, BioNTech’s co-founder, instructed his team to share everything — preliminary data, scientific approaches, manufacturing details — with Pfizer before the legal agreement was finalized. BioNTech was carrying €400 million in debt at the time. The vaccine received FDA emergency authorization on December 11, 2020.
Framing parable — HGP and Celera (1990–2003). A $3 billion public Human Genome Project committed to releasing all data freely within 24 hours under the Bermuda Agreement. Craig Venter’s privately funded Celera Genomics used the public data while keeping its own proprietary. Both projects claimed to finish at roughly the same time. Five minutes of framing, used as a bridge into the student-scale open-science activity below.
Memorial framing for Challenger (~3 min): Brief framing before Case 1 discussion. Seven astronauts died on Challenger — Francis Scobee, Michael Smith, Ronald McNair, Ellison Onizuka, Judith Resnik, Gregory Jarvis, and Christa McAuliffe. Their families and colleagues have spent four decades examining how the decision to launch was made. We study this case to understand what their experience teaches about how teams handle dissent, hierarchy, and pressure under time constraint — not to extract neat lessons from a tragedy.
Case 1 discussion: Challenger (~15 min): Boisjoly raised the concern. The concern was heard. The concern was overridden in a private caucus. At what point in that sequence did trust fail — and was it trust between the engineers and Thiokol management, between Thiokol and NASA, or something more fundamental about whether shared standards existed at all? Discussion prompt for the second half: in your own field, what would an advisor need to say to override your concern about an experiment, analysis, or submission? Would you accept the override? At week five, you’ve been working with your team long enough to answer this concretely rather than abstractly.
Case 2 discussion: BioNTech and Pfizer (~15 min): What conditions made Şahin’s “share everything” instruction possible? What would have made it irresponsible? When is radical pre-legal-agreement transparency visionary, and when is it negligent? Carrying €400 million in debt while extending unilateral trust to a 70,000-employee partner is, on its face, the kind of decision that gets a CEO fired. Why did it work?
Comparative beat (~7 min): Both teams faced extreme pressure with non-negotiable deadlines. Both teams’ decisions were essentially irreversible once made. One produced a vaccine; one produced a disaster. What structural conditions — not personality, not luck — separated the two outcomes? Identify two or three concrete structural elements present in one case and absent in the other.
HGP framing parable + student-scale open-science activity (~10 min): Brief instructor framing on HGP/Celera (~3 min): the Bermuda Agreement’s 24-hour data release rule, Celera’s mixed strategy, the open-science debate that followed. Then teams discuss (~7 min): Should our team share our preliminary proposal draft with another team for feedback before submission? Should we share our final draft as a preprint before formal review? What would each decision require of us, and of the team we’re sharing with? This is the trust-and-openness question at student scale.
Final Team Charter revision (~25 min): Revise and finalize your charter incorporating everything from the module: communication protocols (Lecture 2), CATME insights (Lectures 1 & 5), skills inventory (Lecture 4), contribution and authorship plan (Lecture 5), and now — informed by both Challenger and BioNTech — explicit team norms about trust under pressure. What does your team commit to when stakes get high and the clock is running? Specifically: when one of you raises a serious concern under deadline pressure, what process does the team follow before proceeding?
Final Team Charter — Comprehensive document incorporating all revisions from the module. Submitted via Blackboard.
</details>
When the instructor creates the class and uploads the roster, CATME automatically creates your account using your .edu email. You’ll receive an email with instructions to set your password. If you don’t receive it, check spam, then use the “Forgot your password?” link at catme.org. The most common issue is using a different email address than the one your instructor uploaded.
When entering your schedule in the Team-Maker survey, mark the times you are BUSY and unavailable — not the times you are free. This is the opposite of how tools like When2Meet work, and it’s the most common mistake. Make sure to mark your class meeting times as busy.
The survey also asks about leadership preferences (shared leadership, prefer to lead, prefer to follow). Be honest — this information helps form more balanced teams.
| Rating | What It Means | When to Use It |
|---|---|---|
| 5 — Exceptional | Went far beyond expectations; led critical aspects of the work; resolved problems others couldn’t | Rare — reserve for truly outstanding contributions |
| 4 — Above expectations | Consistently exceeded what was asked; proactively improved the team’s work | When someone genuinely did more than their share |
| 3 — Meets expectations | Did their job well; met deadlines; contributed their fair share; communicated effectively | This is the baseline for a functioning team |
| 2 — Below expectations | Needed reminders; work required significant revision by others; inconsistent participation | When someone consistently fell short |
| 1 — Did not contribute | Work had to be completely redone; did not engage meaningfully | Rare — and should be accompanied by specific comments |
| Evaluation | Opens | Purpose | Grade Impact |
|---|---|---|---|
| Rater Practice | Lecture 1 | Learn the system | None |
| Evaluation 1 | After Module 1 | Early formative feedback | None |
| Evaluation 2 | After Module 2 | Mid-semester check | None |
| Evaluation 3 | After Module 3 | Late formative | None |
| Evaluation 4 | End of semester | Full-semester summative | Multiplier applied |
After each evaluation, complete the individual reflection on Blackboard (3 questions, ~10 minutes).
| If your team is experiencing… | Read this |
|---|---|
| Communication breakdowns | Field Guide Ch. 7; AlphaFold case study |
| One person doing all the work | Field Guide Ch. 11 (One Bad Apple); CATME midterm data |
| Difficulty finding meeting times | Baumgartner et al., section on tools and infrastructure |
| Disagreements about direction | Field Guide Ch. 10 (Conflict is Normal); HGP framing parable (Lecture 6) |
| Unclear credit or contributions | Field Guide Ch. 8 and Appendix; Transistor + BCS Theory cases |
| Incompatible writing styles | Baumgartner et al., section on collaborative writing |
| Lack of trust or psychological safety | Field Guide Ch. 5; COVID vaccine case study |
By the end of this module, students will be able to:
» Detailed assignment instructions, rubrics, and submission portals are available on the course Blackboard site.