Bioinspired Communication & Ethics

Module 1: Foundations of Teamwork

This module builds practical skills for working in diverse, interdisciplinary research teams. Through documented cases, short decision scenarios, CATME peer evaluation, and repeated application to your own team, you will learn strategies informed by research, interviews, workshops, cases, and professional experience. The central product is a living Team Charter that your team will test and revise—not a document written once and forgotten.

Primary reference: L. Michelle Bennett, Howard Gadlin, and Christophe Marchand, Collaboration and Team Science: A Field Guide, 2nd ed. (NCI/NIH, 2018).

Current evidence update: The Field Guide remains the accessible foundation. Selected contemporary practices are informed by the National Academies’ The Science and Practice of Team Science (2025) and current NIH intramural guidance. These supplements update rather than replace the Guide.


Module Structure: 6 Lectures (80 min each)

# Lecture Case Study Field Guide Ch. Deliverable
1 CATME & Peer Evaluation Free-rider + feedback microcases 2, 11 (selected pages) Rating practice (paper) + feedback exit ticket
2 Team Formation & Shared Standards Apollo 13 4–5 (selected pages) Team Charter core draft
3 When the Tools Change the Work Frontiers retraction 4–5 (selected pages) Tooling & verification appendix
4 Cross-Disciplinary Communication AlphaFold 6–7, 9 (selected pages) Skills & integration appendix
5 Credit, Conflict & Accountability Transistor + BCS Theory 8, 10 + Appendix A Provisional Contribution & Credit Plan
6 Trust Under Pressure Challenger + BioNTech/Pfizer 5, 12 Final practice-trio Charter package

The short prompts are not additional historical claims. They are explicitly fictional composites collected in Module 1 Microcases: Charter Decisions in Practice, with timing, required outputs, and instructor cautions.

📝 Running Assignments

Two threads build across the module:

Team Charter — Module 1 practice trio (evolves across Lectures 2–6)

Lecture Milestone
2 Core draft: purpose, outputs, roles, decision rights, meeting/communication norms, provisional data and credit expectations, concern process
3 Appendix A: tooling, records, access, AI disclosure, verification, version control, and fallback procedures
4 Appendix B: skills, blind spots, shared terminology, cross-disciplinary learning, and inclusive discussion norms
5 Appendix C: provisional contributions, recognition/credit principles, review dates, change contingencies, and dispute process
6 Final package: stress-tested core Charter and appendices, version history, all-member review, and sign-off

Module 1’s Charter is written and submitted by your practice trio, not by your semester team. Practice trios are announced in Lecture 2 and stay fixed through Lecture 6 so that the Charter can accumulate without a membership change. CATME Team-Maker forms semester teams after Module 1 and announces them September 14 — the same day this package is due.

Format: The final package uses a two-page core Charter plus structured appendices. The core contains the norms the team needs during ordinary work; appendices hold the detail needed for tools and verification, skills and integration, and contribution/credit planning. A useful clause identifies a trigger, responsible person, required action, timeframe, escalation route, and revision rule. Specific, workable commitments matter more than polished but vague prose.

The Charter is a framework for a working relationship, not a substitute for one. After each formative CATME cycle and major deliverable, teams will conduct a short debrief and revise or reaffirm at least one Charter clause using aggregated patterns—not another member’s confidential comments.

Final quality check: A complete package (1) includes every required core and appendix element; (2) uses procedures another team could follow without guessing; (3) gives high-consequence integrity or safety concerns a pause, record, response, and escalation route rather than relying only on majority vote; (4) accounts for access, capacity, role visibility, backups, and change; and (5) shows revision through a dated version history. The instructor will state point values and appendix length limits on Blackboard before the assignment begins.

CATME Peer Evaluation (3 evaluations after team formation)

Evaluation Timing Grade Impact
Rater Practice Module 1 practice None
Evaluation 1 After the final Module 2 team concept note (Oct 14) None — formative
Evaluation 2 After Module 3 None — formative
Evaluation 3 End of semester Multiplier applied to team assignments

Only the final evaluation affects team-assignment grades. The multiplier may increase a team score by up to 5% or reduce it by up to 100%; any multiplier below 0.85 receives instructor review before it is applied.


A Note on Team Size

For this course, teams of three are used to increase participation, make individual responsibilities visible, and keep coordination manageable. This is a course-design choice, not a claim that three is the universally optimal size for research teams; the Field Guide explicitly covers teams ranging from two-person collaborations to large international networks.

For a class of approximately 25 students, this means about eight teams, with one team of four when enrollment does not divide evenly. Module 1 uses a fixed practice trio of three so that the Team Charter can accumulate, unbroken, across Lectures 2–6. Semester teams are formed with CATME Team-Maker after Module 1 and announced September 14. Teams normally stay together for the semester so that members can practice repair and revision through the difficult middle phase. The instructor may intervene when safety, accessibility, sustained nonparticipation, or another serious condition makes continuity inappropriate.


Lecture 1: CATME & Peer Evaluation

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.

Why Peer Evaluation Matters

Peer evaluation makes expectations visible and gives teams a structured way to discuss contribution, interaction, coordination, quality, and relevant expertise. Repeated formative cycles create time to change behavior before the summative evaluation. Peer ratings are still judgments: they can be affected by incomplete visibility, disciplinary expectations, power, and bias. For that reason, ratings and comments must be tied to specific observed behavior and unusual patterns receive instructor review rather than automatic punishment.

CATME: How It Works

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:

  1. Contributing to the Team’s Work — Completing assignments on time with quality; doing a fair share
  2. Interacting with Teammates — Communicating effectively and respectfully; listening to others
  3. Keeping the Team on Track — Maintaining focus, managing deadlines, monitoring progress
  4. Expecting Quality — Holding the team to high standards; reviewing work carefully
  5. Having Relevant Knowledge/Skills — Bringing and applying appropriate expertise

The Most Important Thing: Normalize the Middle

For this course, a rating of 3 represents meeting the team’s stated expectations well. Save higher ratings for behavior that exceeded those expectations and lower ratings for specific expectations that were not met.

A rating of 3 on a dimension means the observed behavior most closely matches CATME’s Level 3 anchor for that dimension. In course shorthand, the teammate met the relevant expectation well. This is a good rating, not a weak one.

A rating of 5 on a dimension means the behavior matches that dimension’s highest anchor—not simply that the teammate was generally strong or performed one memorable act.

A rating of 1–2 on a dimension means the behavior matches one of that dimension’s lower anchors. If you select it, identify the specific observed behavior and impact in the comments.

Ratings are not a forced curve: a team may genuinely perform very well. The important requirement is that the rating match the behavioral anchors and the evidence, not a desire to be generous, punitive, or consistent with everyone else.

How to Give Constructive Feedback

CATME allows peer-to-peer comments that the instructor releases without names. The comments are confidential, but in a team of three the writer may still be inferable from content or style. Write feedback you could stand behind in a respectful conversation.

Use the Field Guide’s Situation–Behavior–Impact–Future (SBIF) structure:

  • Situation: Identify when and where the behavior occurred.
  • Behavior: Describe an observable action, not a personality judgment or presumed motive.
  • Impact: Explain the effect on the work or team.
  • Future: Request or propose a concrete next action.

Good feedback is:

  • Specific: “The literature review section you drafted needed significant restructuring before we could integrate it” — not “needs improvement”
  • Actionable: “Starting your portion earlier would give the team time to integrate and revise” — not “be more responsible”
  • Respectful, especially when critical: Frame suggestions around improvement, not blame for past actions
  • About the team when appropriate: “Our team struggled with starting tasks early enough” is sometimes more constructive than targeting one person

Receiving feedback is also a team skill. Begin with a sincere “thank you”; ask a clarifying question if needed; and do not immediately rebut, explain, or infer hostile intent. You can reflect and respond later after understanding the observation and impact.

AI, Contribution, and Transparency in Teamwork

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, accountable, and open to appropriate human oversight.

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.

As AI becomes increasingly integrated into scientific research, another question becomes equally important: can your teammates understand and evaluate how AI contributed to the work? Effective collaboration depends upon observability—the ability for collaborators to understand the decisions, assumptions, and human judgment that shaped a research product. Responsible AI use therefore requires transparency not simply about whether AI was used, but how it informed the research process and where human expertise remained essential.

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:

  • Advance the work, not create cleanup. Verify claims, references, reasoning, and AI-generated outputs before sharing. Do not hand the team unverified material that others must correct or validate.
  • Disclose AI use honestly. Tell teammates what you used AI for, where it contributed, and what still requires human review.
  • Meet deadlines responsibly. AI should help you manage time, not create last-minute surprises or hidden risks.
  • Apply your own judgment. Use AI as a support tool, not a replacement for your expertise, disciplinary knowledge, or critical thinking.
  • Maintain accountability. Regardless of how much AI assisted your work, you remain responsible for the accuracy, integrity, and quality of everything you contribute to the team.

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. More broadly, the goal is to help you develop the habits of responsible AI stewardship that increasingly define effective interdisciplinary research. Throughout the semester, we will revisit these ideas through writing, proposal development, peer review, and research ethics as we explore how transparency, observability, governance, and human judgment remain central to trustworthy scientific collaboration.

Asynchronous Activity: AI-Assisted Reflection and Source Verification

Assigned today; due August 31. Watch the two required videos below and complete the reflection activity. The purpose of this assignment is not simply to use generative AI, but to critically evaluate how AI can support—and sometimes undermine—scientific communication and scholarly work.

Required Video 1 — “Why AI Is Incredibly Smart and Shockingly Stupid,” Dr. Yejin Choi (TED), ~15 min. Explores both the remarkable capabilities and the fundamental limitations of modern generative AI systems. As you watch, consider how AI influences trust, accountability, transparency, and human judgment within interdisciplinary research teams.

Required Video 2 — “Why Large Language Models Hallucinate,” IBM Technology, ~10 min. Explains why generative AI systems sometimes generate fabricated facts, misleading summaries, or nonexistent citations. As you watch, think about why researchers must verify AI-generated information before sharing it with collaborators and how unverified AI output can create hidden labor for research teams.

Together, these videos introduce one of the central themes of the lecture: responsible AI use is not determined by whether AI was used, but by whether it was used transparently, critically, and responsibly.

Part 1 — AI-Assisted Reflection. Using a generative AI tool of your choice, develop an initial reflection on each video (brainstorming, bullet points, an outline, a rough narrative, or summarizing major themes are all acceptable uses). Your final submission should reflect your own thinking and judgment, even if AI assisted in developing the initial draft.

Part 2 — Citation Verification. Ask your AI assistant for at least three scholarly or authoritative sources supporting claims made in your reflection. For each citation, verify that it actually exists, confirm it accurately supports the claim it’s cited for, and identify any inaccuracies, fabricated citations (“hallucinations”), misleading summaries, or unsupported claims. Revise your reflection as necessary after completing your verification, and briefly describe how you verified each citation (e.g., Google Scholar, publisher website, university library database).

Part 3 — AI Use and Ethical Reflection. Include a short appendix describing your interaction with AI: which tool(s) you used, what prompts or workflow you developed, which portions of your reflection were AI-assisted, what edits you made after reviewing the AI output, any factual errors/fabricated citations/biased responses the AI produced, how using AI changed your approach to learning or critical thinking, and what you believe are the ethical responsibilities of researchers using generative AI.

How We’ll Use CATME This Semester

Evaluation Timing Purpose Grade Impact
Rater Practice Inside the Team-Maker survey (opens Sep 9) Learn the system; practice with hypothetical teammates None
Evaluation 1 After Module 1 ends Early formative feedback; establish baseline Ratings do not affect grades
Evaluation 2 After the final Module 2 team concept note (Oct 14) 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 ratings are for learning and improvement. A lower early rating is information to investigate, not a grade penalty. Teams have time to discuss patterns, revise one Charter clause, and change behavior before the summative cycle.

Completion is mandatory. The ratings in Evaluations 1–3 do not adjust grades, but submitting each evaluation is a separate course responsibility. Under the syllabus late-completion policy, a late CATME submission receives a 5-point deduction on the associated project grade unless an extension was arranged. This is a completion consequence, not a consequence of the ratings given or received.

After Each Evaluation: Reflection

After receiving your CATME feedback, you’ll answer three questions (submitted individually on Blackboard):

  1. What is one thing your team did well this cycle?
  2. What is one thing your team (or teammates) suggested you could improve?
  3. What is one specific goal you’re setting for yourself before the next evaluation?

These reflections are private (only the instructor sees them) and are designed to help you process feedback constructively rather than defensively.

CATME Flags

CATME can flag patterns such as unusually low contribution ratings, disagreement among raters, self/peer discrepancies, or possible subgroup effects. A flag is a prompt to examine evidence and context; it is not a finding of misconduct or an automatic penalty. Team size, role visibility, workload changes, access needs, bias, and other circumstances may affect a pattern.

The Grade Multiplier

Only Evaluation 4 produces the course grade multiplier. Per the syllabus, peer evaluation scales each individual’s grade on team assignments up by as much as 5% and down by as much as 100%. For example, a team grade of 90 could be increased to 94.5 for a member who receives outstanding peer evaluations, or reduced to 0 for a member who contributes no effort and receives very low peer evaluations.

Because peer ratings may have a large effect, any grade multiplier below 0.85 is investigated further before it is assigned—it is not applied automatically. The instructor reviews the behavioral evidence, written comments, role visibility, workload and access circumstances, possible bias, and the student’s response before finalizing it. A CATME flag or raw score alone does not determine the adjustment. Students may ask for the calculation and request review before the multiplier is finalized.

Reading

  • Field Guide pp. 16–18 and 21–23: self-reflection, disciplinary lenses, the Maxim/Lao vignette, psychological safety in feedback, and SBIF
  • Field Guide p. 26: “Am I Ready to Participate?” self-check
  • Field Guide pp. 118–120: Case Study 23 and indicators of indirect communication, disengagement, and gossip
  • CATME: How We Form Teams, and How You’ll Evaluate Them — course deck walking through the five behaviorally anchored dimensions, why a 3 is a good rating, and how to write feedback teammates can act on.
  • CATME Overview
  • CATME Peer Evaluation
  • Free-rider scenario: Mid-Project, Four Weeks In

In-Class Activities (80 min)

CATME purpose and walkthrough: Demonstrate the five dimensions and behavioral anchors. Distinguish observed behavior from assumptions, popularity, and personality judgments.

Rating practice on paper: Assign ten described behaviors to the five dimensions and rate each one, individually and without discussion. Compare answers as a class. The two distinctions that matter are completing assigned work versus having the ability to do it, and giving feedback as track-keeping rather than interaction.

Free-rider scenario and evidence audit: Rate Alex on each dimension using only the scenario. Mark each statement as observation, inference, or missing information. Compare Jordan’s proposed private conversation with Field Guide Case Study 23 and the Chapter 11 “When It’s Not Working” indicators on indirect communication and gossip.

AI and hidden-verification-labor scenario: One teammate uses AI to draft a section quickly, but unsupported claims and fabricated references create repair work for the others. Which CATME dimensions are implicated? What behavior and impact—not assumed intent—should appear in feedback?

SBIF giving-and-receiving role-play: Adapt the Field Guide’s Maxim/Lao vignette. Partners separate the observed question from the story each scientist constructs, write one SBIF comment, and practice receiving it with thanks and one clarifying question before responding.

Individual reflection and provisional norm: Write one evidence rule for future CATME ratings and one provisional team norm for feedback or transparent AI use. These become inputs to the Lecture 2 Charter draft.

Buffer and exit check.

Deliverable

Submit the feedback/Charter-norm exit ticket before leaving. CATME Rater Practice is completed inside the Team-Maker survey, which opens September 9. The AI-Assisted Reflection and Source Verification assignment (Parts 1–3, above) is due August 31.


Lecture 2: Team Formation & Shared Standards

Case Study: Apollo 13 (April 1970) — An oxygen tank in the service module failed about 56 hours into the mission. The crew, Mission Control, contractors, and support teams had to preserve power and consumables, adapt the lunar module as a lifeboat, improvise a carbon-dioxide removal solution, and plan a safe return. The three astronauts returned on April 17. The case is useful because the response depended on role clarity, specialized expertise, disciplined communication, simulation, and coordination across organizational boundaries. It is not a model of a newly formed student team: Mission Control was a mature, trained, hierarchical system with extensive infrastructure. See NASA’s Apollo 13 mission overview.

Reading (before class)

In-Class Activities (80 min)

Trust retrieval prompt: Identify one example each of competence-based, swift, identity-based, or calculus-based trust from the reading. Which kinds can a new course team reasonably possess in week one?

Apollo 13 discussion: Instructor note: “Failure is not an option” was created for the 1995 film, not spoken during the mission. What roles, authority, communication routines, and verification resources supported distributed decisions? Which practices can a three-person student team adopt, and which depended on years of training, hierarchy, redundancy, simulation, and institutional infrastructure?

Team interviews: Practice trios for Module 1 are announced today. These are not your semester teams—CATME Team-Maker forms those after Module 1, and they are announced September 14. Interview a partner about their research interests, a strength they enjoy contributing, work they do not yet feel ready to lead, what helps them respond to disagreement, one access or scheduling condition relevant to teamwork, and one light personal question. Introduce the partner without disclosing information they did not agree to share.

“Unit conversion” exercise: Each member names one disciplinary assumption teammates may not share—for example, what “validated,” “significant,” “safe,” or “complete” means. Write an operational definition and identify what evidence would justify pausing an experiment, analysis, or submission.

Core Charter drafting: Draft the team’s shared purpose and expected outputs; definition of complete/high-quality work; roles, backups, and decision rights; meeting and communication routines; procedure for missed commitments and workload reset; provisional data/file access and credit expectations; and Charter review process. Add a concern protocol that records the issue, identifies who must respond, defines temporary pause conditions, and provides an escalation route when consensus is inappropriate or unavailable.

Micro-scenario—“Friday at 4:52”: Eight minutes before submission, the member responsible for quantitative validation finds a unit mismatch that may reverse the conclusion. The coordinator proposes a two-to-one vote to submit. Apply the draft Charter: Does work pause? Who has authority? What is documented? When is the instructor contacted? What happens if no answer arrives before the deadline?

Revise one clause and exit check: Rewrite the concern clause so another team could follow it without guessing.

Deliverable

Team Charter core draft — Drafted in class and completed before Lecture 3. The core is a maximum of two pages and contains the elements above. Each procedure must identify the trigger, responsible person, action, timeframe, and escalation or revision route. Appendices are added in Lectures 3–5.


Lecture 3: When the Tools Change the Work

Case Study: The Frontiers Retracted Figure (February 2024) — A review article published on February 13 contained disclosed Midjourney-generated figures with impossible anatomy and nonsense labels. According to Frontiers, one reviewer had raised valid concerns about the figures and requested revisions; the authors did not respond to those requests, yet the article proceeded to publication. Frontiers retracted it on February 16 and investigated why its process had failed to act. The case is therefore not simply “AI made an image and no one noticed.” A warning existed, but the workflow did not ensure that it was resolved before publication.

Tool decisions are team governance decisions. Teams can make those decisions implicitly—by adopting the tool one member already knows, continuing a previous workflow, or following the first confident suggestion. Access, labor, and record-keeping consequences may not become visible until the workflow is established. This lecture makes those decisions explicit early enough to revise them.

Reading (before class)

  • Field Guide p. 53: decide in advance how analysis, review, submission, and publication will be handled. Published in 2018, the Field Guide predates generative AI tools and does not address them directly—use it for the general practice of deciding tool governance in advance, not for AI-specific guidance.
  • Case brief: The Frontiers Retracted Figure, including the official publisher statement and retraction notice
  • NIH Office of Intramural Research, Guidelines and Policies for the Conduct of Research, pp. 61–65, “Responsible Use of AI and Documenting its Utilization.” This is current NIH intramural guidance, not a universal policy for every institution.
  • Pre-class reflection prompt: Identify one tool you currently use heavily for research work and one tool you have considered using but have not adopted. Bring both to class.

In-Class Activities (80 min)

Framing: tools as team governance: 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: Briefly examine knowledge management, literature management, meeting coordination, collaborative writing/version control, analysis/code, and generative AI. For each category, ask what the choice determines about access, records, labor, privacy, reproducibility, and responsibility.

Case workflow reconstruction: Separate the documented record from assumptions. Map author preparation, peer review, editorial control, and production/publication. Mark where evidence is known, where it is missing, and where a blocking reviewer request should have remained open. What is the difference between disclosing a tool and closing a verification concern?

Rules that address the wrong failure: Test whether last year’s rule—“never use AI to write content; always disclose its use”—would have prevented the Frontiers retraction. It would not: the figures were generated, not written, and the AI use was already disclosed; the unresolved failure was an unclosed reviewer request. Then revisit the prior-course AI-detection demonstration (0–20% accuracy) as a small local exercise that cannot be interpreted without knowing the prompts, samples, scoring, and models used—not a benchmark or proof about detection systems generally. Close with four norms that do not depend on reliably guessing whether AI was used: verify the claim, not the author; require the record, not the confession; assign a verifier before the work starts; and make the unresolved concern visible. These four become the spine of Appendix A.

Team tool-and-labor audit: Complete the five-column worksheet—challenge, root cause, process solution, tool solution, and owner/timing/failure—for at least two problems drawn from different areas (scheduling, communication and coordination, collective writing, references and literature, or analysis and code). Fill the process column before the tool column: if you cannot name a process rule, you have an unmade decision, not a tool problem. Then map who pays, configures, documents, verifies, troubleshoots, and onboards for the team’s current stack, putting a name in every box. A name in four or more boxes marks a single point of failure and an unrecorded contribution—both belong in Appendix A, and the contribution belongs in Appendix C later.

Microcase—“The inaccessible workspace”: A team adopts a paid, visually dense workspace because two members already use it; the system does not work reliably with the third member’s access setup, and they miss decisions recorded there. Apply the Charter’s concern and decision rules without asking for private medical information. What must be changed now, and what selection rule would have prevented the problem?

Drafting Appendix A: tooling and verification: For each important tool or output, specify the record to retain, disclosure requirement, primary verifier, evidence/source check, second-review trigger, sign-off authority, and what blocks submission. Add access/cost, privacy/security, accessibility, onboarding, version-control, fallback, and revision procedures. An unresolved high-consequence concern must have an owner and deadline and must remain visible until it is closed or escalated.

Buffer and submission check.

Deliverable

Team Charter Appendix A: Tooling & Verification — Drafted in class and completed before Lecture 5. This structured appendix must be usable as a procedure, not merely list preferred products.

Connection to Lecture 4 (Cross-Disciplinary Communication)

The skills-and-limits inventory in Lecture 4 presupposes infrastructure for sharing knowledge, tracking decisions, and making cross-disciplinary discussion legible. Lecture 3 establishes that infrastructure; Lecture 4 then adds people, terminology, learning, and integration procedures to it.


Lecture 4: Cross-Disciplinary Communication

Case Study: AlphaFold (2018–2024) — AlphaFold’s first system led the CASP13 blind assessment decisively: it produced high-accuracy structures for 24 of 43 free-modelling domains, compared with 14 for the next method. AlphaFold 2 was then described by its authors as an “entirely redesigned” and “completely different” model. Its architecture coupled evolutionary, geometric, physical, biological, and machine-learning ideas; DeepMind and EMBL-EBI later collaborated to turn predictions into a public database. These products document interdisciplinary integration, but the cited public record does not establish presumed internal debates, reorganizations, “near failures,” or negotiations with funders. Those must not be narrated as facts.

The 2024 Nobel Prize in Chemistry previews a question the course returns to in Lecture 5: one half went to David Baker for computational protein design, a separate line of work, while the other half went jointly to Demis Hassabis and John Jumper for protein structure prediction. For the half that concerns AlphaFold, the prize recognized two individuals, not “the AlphaFold team,” while the papers and database document many contributors and an institutional partnership—the credit-and-recognition question Appendix C asks you to work through.

Reading (before class)

Reading: Field Guide pp. 58–62, 64–70, and 90–96, plus the AlphaFold case brief on the course site. Wednesday’s session works directly from the brief rather than summarizing it, so read that one properly.

In-Class Activities (80 min)

Shared-vision retrieval and “validated” microcase: Compare three disciplinary meanings of “validated.” Write a two-sentence project vision that states both the shared outcome and the evidence needed to claim success.

AlphaFold evidence/inference audit: Examine the CASP13 result, the documented redesign, the architecture, author-contribution statements, database partnership, limitations, and Nobel recognition. Classify claims as documented, reasonable teaching inference, or unsupported history. What team processes could support this result, and what additional evidence would show that AlphaFold used them?

Integration architecture: Map how domain concepts, model design, engineering, evaluation, and database stewardship depend on one another. Distinguish integration, reciprocal translation, and handoff. Where would a designated connector between disciplines or a redundant communication path reduce risk?

Skills-and-limits inventory: Each member identifies the expertise, methods, tools, and relationships they can contribute; work they are not yet ready to lead; a term teammates may interpret differently; a skill they want to learn; and the kind of challenge or support that helps them participate. Record backups for single points of expertise.

Reciprocal translation exercise: Apply each discipline’s lens to one project concept. Build a small shared glossary containing operational definitions, evidence standards, and “ask before assuming” terms. Identify one point where the team needs integration rather than sequential handoff.

Appendix B revision and exit check: Add the inventory, glossary, learning commitment, integration point, and a norm for inclusive scientific disagreement.

Deliverable

Team Charter Appendix B: Skills & Integration — Completed before Lecture 5. It includes the two-sentence vision, member skills and limits, backups, shared glossary, cross-disciplinary learning commitment, integration point, and discussion norm.


Lecture 5: Credit, Conflict & Accountability

Paired Case Studies: The Same Scientist in Two Different Collaborations

John Bardeen contributed to both the transistor work at Bell Labs and BCS theory at the University of Illinois. The cases are not controlled experiments in leadership, and the record does not justify treating one as a simple “failed team” and the other as its opposite. The pairing instead lets students compare how contributions, authority, and recognition are recorded and narrated in different institutional and disciplinary settings.

Case 1 — Bardeen, Brattain, and Shockley (Bell Labs, 1947–1948). Bardeen’s Nobel lecture describes a semiconductor group under William Shockley’s general direction, Bardeen’s theoretical work, Walter Brattain’s experimental work on surface effects, and an amplifier produced by Bardeen and Brattain and further developed by Shockley. The three later shared the 1956 Nobel Prize in Physics. Rather than asking students to assign personality-based blame from anecdotes, the class asks what contemporaneous records and decision rules could distinguish scientific contribution, leadership, patent inventorship, and later prize recognition.

Case 2 — Bardeen, Cooper, and Schrieffer (University of Illinois, 1955–1957). Bardeen, postdoctoral fellow Leon Cooper, and graduate student J. Robert Schrieffer developed BCS theory and shared the 1972 Nobel Prize in Physics. Their 1957 paper listed authors alphabetically. Alphabetical order is a documented fact; without a source establishing the authors’ intent, it is not proof that they selected the order as a fairness intervention. Bardeen later emphasized their close collaboration and said that each member was essential.

Reading (before class)

In-Class Activities (80 min)

Framing the pairing: The same scientist appears in two different collaborations. What can the available records establish, and what would be an interpretation rather than a fact?

Evidence-packet jigsaw: Groups examine Nobel lectures, paper metadata, and short institutional histories. Identify each source’s claim, perspective, and limit. Do not infer motives or the absence of a process merely because a surviving source does not describe one.

Comparative analysis: Compare contribution recording, formal authority, career stage, publication order, and later recognition. Which explanations are supported, plausible but unproven, or contradicted?

Microcase—“Two first authors”: Two trainees have both led major parts of a project, but their fields interpret first-author order differently. Separate contribution, author eligibility, order, corresponding responsibility, patent inventorship, ownership, and prize recognition. What must be recorded now, and what remains provisional?

Conflict-protocol drill: One member believes invisible verification work has been omitted from the contribution record; another says the plan has already been agreed. Use Field Guide Chapter 10 to specify the first conversation, documentation, neutral consultation, decision authority, and escalation point.

Drafting Appendix C: Create a provisional contribution matrix, record both intellectual and coordination/verification labor, state recognition and credit principles, and set review dates. Add procedures for changing scope, unequal or missing contributions, new or departing members, non-author recognition, disagreement, and escalation.

Peer stress test and exit check: Another team applies one change scenario and identifies any clause that cannot be executed.

Deliverable

Team Charter Appendix C: Provisional Contribution & Credit Plan — Completed before Lecture 6. This is a living planning document, not a final authorship determination or guaranteed author order. It records current expectations and a process for revisiting them as the work changes.

Bridge to Module 4

This lecture introduces early conversation and record-keeping. Module 4 returns to the ethical and policy questions: author eligibility and order, CRediT roles, accountability, honorary and ghost authorship, power, disputes, AI assistance, patent inventorship, ownership, and intellectual property. “Author,” “contributor,” “inventor,” “owner,” “rightsholder,” and “prize recipient” are not interchangeable categories.


Lecture 6: Trust Under Pressure

Paired Case Studies: Trust, Dissent, and Decision Authority Under Pressure

The cases are deliberately contrasting, but not moral mirror images. Challenger involved a launch decision in a hierarchical, safety-critical system; the vaccine partnership unfolded over months with legal agreements, independent monitoring, clinical-trial rules, and regulatory gates. Compare how each setting handled expertise, uncertainty, dissent, decision authority, and redundant checks while resisting outcome bias.

Case 1 — Challenger and the Night-Before Teleconference (January 27, 1986). Morton Thiokol initially recommended against launch below 53°F. NASA participants challenged the basis for the recommendation. Thiokol requested about five minutes off the communication loop; Rogers Commission testimony indicates that the private caucus actually lasted approximately 30–35 minutes before management returned with a recommendation to launch. The final recommendation was signed by management. The case supports close analysis of how an institutional recommendation can change while technical dissent remains, how that change is documented, and whether unresolved concerns reach the people with decision authority; it should not be reduced to a mistaken “five-minute decision.”

Case 2 — BioNTech and Pfizer (2020). BioNTech dates the start of Project Lightspeed to January 27. The companies announced a letter of intent and an executed material-transfer and collaboration agreement on March 17, while fuller commercial terms remained under negotiation; those terms were announced April 9. The partners combined distinct capabilities, shared development costs, overlapped work, and manufactured at financial risk, while independent monitoring, evidentiary requirements, and regulatory gates remained in place. A retrospective insider account reports an instruction to “share everything,” but the documented interim legal scaffolding and prior relationship make this a case of staged or bounded trust—not trust without agreements or controls.

Reading (before class)

  • Field Guide pp. 53 and 56–57: Case Studies 8 and 9 — one collaboration governed by an explicit authorship and data-analysis committee, one with no advance agreement that ended in escalation to senior leadership, a formal investigation, and collapsed trust — followed by the trust working/not-working check and the chapter take-aways. Re-read pp. 50–52 and 54–55 from Lecture 2 (forms of trust, psychological safety) — note that the psychological-safety example there is Columbia (2003), a different accident from the Challenger launch decision we analyze today.
  • Field Guide pp. 124–125: why an organization chart does not show how information actually flows, and the four networks — Knowledge, Access, Source Receptive, and Energy — including building redundancy so the team does not halt when one person is unavailable
  • Evidence packet: Challenger and the Night-Before Teleconference, with selected Rogers Commission records and an authority map
  • Case brief: BioNTech and Pfizer—Project Lightspeed, including primary company, journal, and regulatory sources

In-Class Activities (80 min)

Memorial framing for Challenger: Brief framing before Case 1 discussion. Challenger and its crew were lost 73 seconds after liftoff on January 28, 1986. The seven crew members were Francis Scobee, Michael Smith, Ronald McNair, Ellison Onizuka, Judith Resnik, Gregory Jarvis, and Christa McAuliffe. NASA commemorates them through its Day of Remembrance, and their families established the Challenger Center as an educational legacy. We study the launch-decision record to improve how teams handle uncertain evidence, dissent, authority, and escalation — not to turn a tragedy into a simple morality tale.

Challenger evidence and decision map: Trace the initial recommendation, NASA challenge, request to caucus, actual caucus duration, changed recommendation, signature, and launch decision. Who could raise a concern, advise, define Thiokol’s institutional position, escalate, and decide? Was any formal veto authority actually documented? Which statements are documented and which are later interpretations?

BioNTech/Pfizer decision map: Identify the prior relationship, provisional agreements, different capabilities, cost sharing, information exchange, independent monitoring, evidentiary standards, and regulatory gates. Which risks were accepted, allocated, retained, or independently checked?

Outcome-bias comparison: Imagine that the vaccine had failed despite the same process, or that Challenger had launched without an accident despite the same decision process. Which judgments about process quality remain? Which differences make direct comparison misleading?

Chapter 12 network map: Map the team’s Knowledge, Access, Source Receptive, and Energy Networks, using the Guide’s four labels. Add a redundant path for one critical resource. Drawing on Chapter 8, identify any member functioning as a boundary spanner and avoid making that person a single point of failure.

Deadline-dissent microcase: A senior member says a concern has been heard and the team must now submit. Apply the Charter: what evidence triggers a pause, who records the concern, who can close it, when is voting inappropriate, and where does escalation go?

Final Charter stress test and revision: Exchange packages and apply two new variants: an external collaborator asks for a draft and underlying data when sharing permission is unclear; then a member leaves after making significant contributions while still holding the only editable source files and one service credential. Revise clauses that rely on goodwill, an unnamed actor, inaccessible records, unresolved ownership/permission, or a decision rule that cannot handle membership change.

All-member review and exit check: Confirm that each member understands the core and appendices and record unresolved items.

Deliverable

Final Module 1 practice-trio Charter package — The two-page core, Appendices A–C, version history, and all-member review/sign-off. Complete the stress test in class and submit by the Blackboard deadline on September 14. This is your practice trio’s Charter; the semester teams announced the same day are a separate team formed after Module 1. A signature indicates that the member reviewed the package and can raise future revisions; it does not waive the right to dissent or report a concern.


CATME Quick Reference

Setting Up Your Account

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.

Team-Maker Survey Tips

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 Guidelines

Rating Course Interpretation How to Use It
5 Highest behavior anchor for the dimension Use only when the observed behavior best matches CATME’s Level 5 description
4 Above the course’s meets-expectations anchor Use when the observed behavior best matches that dimension’s Level 4 description
3 Course standard for meeting the relevant expectation well Use when the observed behavior best matches that dimension’s Level 3 description
2 Below the meets-expectations anchor for the dimension Use when specific observed behavior best matches that dimension’s Level 2 description
1 Lowest behavior anchor for the dimension Use when specific observed behavior best matches that dimension’s Level 1 description; explain the evidence and impact

CATME’s descriptions differ by dimension. Do not apply one global label such as “did not contribute” to all five dimensions; read the behavior anchor displayed for the dimension you are rating.

Understanding Your Results

Semester CATME Calendar

Evaluation Opens Purpose Grade Impact
Rater Practice Inside the Team-Maker survey (opens Sep 9) Learn the system None
Evaluation 1 After Module 1 Early formative feedback None
Evaluation 2 After the final Module 2 team concept note (Oct 14) 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).

CATME Resources


Core References

Primary Text (Assigned Chapters)

Case Study Source Document

Supplementary References (Consult as Needed)

Problem-Based Quick Reference

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; CATME patterns and Charter workload-reset procedure
Difficulty finding meeting times Baumgartner et al., section on tools and infrastructure
Disagreements about direction Field Guide Ch. 10; Charter concern and decision-rights procedures
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

Module Learning Objectives

By the end of this module, students will be able to:

  1. Analyze documented team cases by separating evidence, interpretation, process quality, and outcome
  2. Prepare to evaluate their own team’s dynamics by practicing CATME’s behavioral anchors and establishing a reflection-and-revision procedure
  3. Develop a Team Charter that addresses coordination, communication, credit, and conflict with specific, actionable protocols
  4. Articulate the unique challenges of interdisciplinary collaboration and strategies for bridging disciplinary differences
  5. Develop a concrete plan for using future aggregated CATME feedback to revise one behavior and one Charter clause before summative evaluation
  6. Give and receive constructive peer feedback using CATME’s behaviorally anchored dimensions

» Detailed assignment instructions, rubrics, and submission portals are available on the course Blackboard site.


← Course Home Proposal Communication →