# Learning Team Charter: [Team name, programme and term]

> A charter for an MBA study group or assigned learning team: purpose and goals, working norms, roles, meeting
> cadence, decision rules, a workload ledger, a conflict and escalation process, a psychological safety agreement and
> a review schedule. It is for teams of four to seven students who will share cases, problem sets and graded projects
> for a term or a whole core year. Teams that agree these points in week one spend less time later on avoidable
> friction, and have a fair process ready when something does go wrong.
> Source basis: team development stages (Tuckman 1965; Tuckman and Jensen 1977), team psychological safety
> (Edmondson 1999), the conditions for team effectiveness (Hackman 2002), and research on social loafing and team
> conflict, written in our own words. The worked example uses a fictional team.
> Replace every [bracketed] value and every row marked *Example*.

<!--
Guidance: How to use this template
- Draft the charter together in the first or second meeting, before the first graded deliverable. A charter written by one person and signed by the rest is a weaker commitment.
- Fill Sections 1 to 4 first (purpose, members, goals, norms). Then roles, decision rules and the conflict process, which are the parts people skip and later need.
- Keep it short enough to read in five minutes. Add detail only where the team actually disagrees.
- Review it at the scheduled checkpoints (Section 11), not only when there is a problem.
- If your programme gives its own team contract or peer evaluation form, use that and treat this template as the discussion guide. Check your course's current instructions.
- Related templates: mba/mba-peer-feedback, mba/mba-group-project-report, mba/mba-team-dynamics-card, mba/mba-case-prep-sheet, mba/mba-class-participation-log, mba/mba-learning-journal, mba/mba-interpersonal-dynamics-journal, mba/mba-ai-use-policy-check, business/project-charter, business/raci, product/sprint-retro
-->

## Document control

<!-- Guidance: One charter per team per term. If membership changes, start a new version and re-sign. -->

| Field | Value |
|---|---|
| Document ID | [LT-CH-01] |
| Team name or number | [Learning Team 7] |
| Programme, section and term | [MBA core, Section B, Term 1] |
| Course(s) covered | [All core courses / Finance and Strategy only] |
| Team members | [Names] |
| Charter owner (keeps it current) | [Name] |
| Version | [1.0] |
| Agreed on | YYYY-MM-DD |
| Next review | YYYY-MM-DD |
| Reviewed by | [Section coach, faculty adviser or second-year mentor, if any] |

### Approvals

| Member | Signature or initials | Date |
|---|---|---|
| [Name] | [ ] | YYYY-MM-DD |
| [Name] | [ ] | YYYY-MM-DD |
| [Name] | [ ] | YYYY-MM-DD |
| [Name] | [ ] | YYYY-MM-DD |
| [Name] | [ ] | YYYY-MM-DD |

## Why a charter works

<!-- Guidance: Read this together in the first meeting. It explains why each section exists so the team does not treat the charter as paperwork. -->

MBA learning teams are usually assigned rather than chosen, and they are deliberately mixed by industry, function,
nationality and quantitative background. That mix is the point: the accountant explains deferred revenue, the
engineer builds the model, the consultant structures the slide deck, and everyone learns faster than alone. The same
mix also brings different assumptions about how hard to work, how direct to be, when a draft is "done" and who decides.
Most team conflict in a core year is not about personality. It is about unstated expectations colliding under deadline
pressure.

Three bodies of research explain why writing the expectations down early helps.

**Teams move through stages.** Tuckman (1965), reviewing studies of small groups, described a developmental sequence
whose stages he labelled forming, storming, norming and performing; Tuckman and Jensen (1977) added adjourning. The
stages are a description of tendencies, not a fixed timetable, and Gersick (1988) showed that project teams often work
in a long first phase and change approach sharply around the midpoint of their time. The practical lesson is that the
"storming" disagreements about goals and norms will happen anyway. A charter brings them forward to week one, when
the stakes are low and nobody is yet tired or resentful, and it gives the team a planned midpoint review.

**Learning needs psychological safety.** Edmondson (1999) studied work teams in a manufacturing company and found that
team psychological safety, a shared belief that the team is safe for interpersonal risk taking, was associated with
learning behaviour such as asking questions, seeking feedback, admitting errors and discussing problems; learning
behaviour in turn was associated with team performance. In an MBA team the learning behaviours are exactly what you
need: the student who does not understand the WACC calculation must feel able to say so before the problem set is due,
not after the grade.

**Effective teams have the right conditions.** Hackman (2002) argued that a leader's style matters less than whether
the team has five conditions: it is a real team (clear membership, interdependent work, some stability), it has a
compelling direction, an enabling structure (task design, size, norms of conduct), a supportive context (resources,
information, rewards that recognise team work) and expert coaching available at the right times. A charter is how a
self-managing student team builds the second and third conditions for itself.

Two further findings shape specific sections. Social loafing, the tendency to exert less effort when individual
contributions are hard to identify (Latané, Williams and Harkins 1979), is why the charter makes contributions
visible in a workload ledger. Research on intragroup conflict distinguishes task conflict (disagreement about the
work) from relationship conflict (personal friction); relationship conflict is consistently harmful, and task conflict
is not reliably helpful either (Jehn 1995; De Dreu and Weingart 2003). The charter therefore separates "how we argue
about the work" from "how we raise a problem with a person".

```mermaid
flowchart LR
  F["Forming: charter drafted, roles agreed"] --> S["Storming: first deadline, norms tested"]
  S --> N["Norming: charter revised at checkpoint 1"]
  N --> P["Performing: routines run, roles rotate"]
  P --> M["Midpoint review: reset goals and workload"]
  M --> P
  P --> A["Adjourning: final review, peer feedback, lessons"]
```

## 1. Purpose and context

<!-- Guidance: One paragraph. Why does this team exist, for which courses, and what is in and out of scope? Pitfall: copying the course description instead of stating what the team will actually do together. -->

| Item | Our answer |
|---|---|
| Why this team exists | [Assigned learning team for the core year: we prepare cases together and deliver graded team assignments] |
| Courses and deliverables in scope | [Financial accounting problem sets, strategy case write-ups, operations simulation, marketing project] |
| Out of scope | [Individual exams and individual write-ups: we may discuss concepts but not share answers] |
| Graded team deliverables this term | [List with due dates] |
| Course rules on collaboration and AI use | [Paste the link or a one-line summary of each course's rule, dated YYYY-MM-DD] |

Collaboration rules differ by course and by assignment, and many schools now publish course-level rules on the use of
generative AI. As of October 2026 these rules vary widely between programmes and even between instructors in the same
programme, so record each course's current rule here and check it again before each deliverable; see
mba/mba-ai-use-policy-check for a worksheet.

## 2. Members, strengths and learning goals

<!-- Guidance: Each member fills one row in the first meeting. "Wants to learn" is as important as "can teach": it is how roles get rotated later. -->

| Member | Background (industry, function) | Can teach the team | Wants to learn | Time zone and constraints | Preferred contact |
|---|---|---|---|---|---|
| [Name] | [ ] | [ ] | [ ] | [ ] | [ ] |
| [Name] | [ ] | [ ] | [ ] | [ ] | [ ] |
| [Name] | [ ] | [ ] | [ ] | [ ] | [ ] |
| [Name] | [ ] | [ ] | [ ] | [ ] | [ ] |
| [Name] | [ ] | [ ] | [ ] | [ ] | [ ] |

Constraints worth stating openly: caring responsibilities, recruiting travel weeks, religious observances, a part-time
job, a disability adjustment the member chooses to share, or a commute. Stating them in week one prevents later
assumptions that someone is "not committed".

## 3. Team goals

<!-- Guidance: Agree two or three goals for the term. Include at least one learning goal and one process goal, not only a grade goal. Pitfall: "get an A" is an outcome the team does not fully control; pair it with goals it does control. -->

| ID | Goal | Type | How we will know | Owner |
|---|---|---|---|---|
| G-01 | [ ] | Performance | [ ] | [ ] |
| G-02 | [ ] | Learning | [ ] | [ ] |
| G-03 | [ ] | Process | [ ] | [ ] |

Disagreement about ambition is common and legitimate. Some members want the top grade in every course; others are
prioritising recruiting or a specific concentration. Agree the level of quality the team will aim for on each graded
deliverable (for example "strong pass on problem sets, top-quality effort on the strategy project") so that nobody
reads a different priority as laziness or perfectionism.

## 4. Working norms

<!-- Guidance: Write norms as observable behaviours, not values. "We respect each other" cannot be checked; "we reply to team messages within 12 hours on weekdays" can. Aim for 8 to 12 norms. -->

| Area | Norm (observable behaviour) |
|---|---|
| Preparation | [Everyone reads the case and attempts the questions before the meeting] |
| Attendance | [ ] |
| Punctuality | [ ] |
| Communication channel | [ ] |
| Response time | [ ] |
| Drafts and version control | [ ] |
| Quality check before submission | [ ] |
| Speaking time in meetings | [ ] |
| Devices in meetings | [ ] |
| Late or missed work | [ ] |
| Academic integrity and AI use | [ ] |
| Celebrating and resting | [ ] |

A useful test for each norm: if a member broke it, would everyone agree that it had been broken? If not, rewrite it.

## 5. Roles

<!-- Guidance: Separate process roles (facilitator, timekeeper, note-taker) from content roles (lead on a deliverable). Rotate process roles weekly and content leads by deliverable so that everyone practises the skills they listed under "wants to learn". -->

| Role | Responsibilities | Rotation | Current holder |
|---|---|---|---|
| Facilitator | Sets the agenda, keeps discussion on topic, makes sure quieter members are heard | Weekly | [ ] |
| Timekeeper | Keeps the agenda times, calls the decision point | Weekly | [ ] |
| Note-taker | Records decisions, owners and dates in the shared log | Weekly | [ ] |
| Deliverable lead | Owns the plan, integration and final quality check for one deliverable | Per deliverable | [ ] |
| Devil's advocate | Argues the strongest case against the emerging answer | Per meeting | [ ] |
| Charter owner | Keeps this document current and calls the checkpoint reviews | Term | [ ] |

A deliverable lead is not the person who does most of the work. The lead plans the split, integrates the pieces,
checks consistency (numbers, terminology, formatting) and submits. Use business/raci if a deliverable has many
contributors.

## 6. Meeting cadence and format

<!-- Guidance: Decide the default rhythm, then the agenda shape. Record decisions in one place. Pitfall: long meetings with no agenda that rebuild the analysis together instead of reviewing pre-work. -->

| Meeting | When | Length | Purpose |
|---|---|---|---|
| Case and problem-set prep | [ ] | [90 min] | [Compare individual answers, resolve disagreements, agree speaking points] |
| Deliverable work session | [ ] | [90 min] | [Integrate drafts, decide structure and recommendation] |
| Weekly check-in | [ ] | [30 min] | [Plan the week, workload ledger, raise issues early] |

Default agenda for a 90-minute session:

1. Check-in and agenda (5 minutes).
2. Each member's headline answer in one minute, without interruption (10 minutes).
3. Disagreements: list them, then resolve the largest first (40 minutes).
4. Decisions, owners and dates read back by the note-taker (10 minutes).
5. Open questions to bring to class or office hours (10 minutes).
6. Process check: one thing that worked, one thing to change (5 minutes).
7. Buffer (10 minutes).

Taking turns for the headline answer before any discussion protects independent thinking: groups that discuss before
everyone has stated a view tend to converge on whoever speaks first.

## 7. Decision rules

<!-- Guidance: Agree which decisions use which rule before you need them. The worst time to decide how to decide is the night before a deadline. -->

| Decision type | Rule | Fallback if no agreement by the deadline |
|---|---|---|
| Recommendation in a graded deliverable | [Consensus: everyone can live with it and will defend it] | [Majority vote, dissent noted in the team's notes] |
| Analysis method or assumption | [Deliverable lead decides after hearing views] | [Use the more conservative assumption and show a sensitivity] |
| Split of work | [Proposed by the lead, agreed by the team] | [Equal split by estimated hours] |
| Meeting time changes | [Majority with 24 hours' notice] | [Keep the default time] |
| Changes to this charter | [Unanimous] | [Keep the current version] |

"Consensus" here means that every member can support the decision, not that every member thinks it is the best
option. Ask explicitly: "Can everyone live with this and defend it in class?" Silence is not agreement.

## 8. Workload and contribution ledger

<!-- Guidance: Estimate hours for each deliverable at the start, then record actual hours each week. The purpose is early visibility, not surveillance. Agree the review trigger in advance. -->

Planned versus actual hours make contributions visible, which reduces social loafing and also protects the member
who is quietly doing more than a fair share. Agree a trigger: for example, a member whose share of total hours is more
than 5 percentage points away from an equal share over two weeks is raised at the weekly check-in as a planning
question, not as an accusation. Hours are an imperfect measure (a skilled modeller may need fewer hours), so the
discussion is about whether the split still feels fair.

| Member | Planned hours | Actual hours | Share of actual | Note |
|---|---|---|---|---|
| [Name] | [ ] | [ ] | [ ]% | [ ] |
| [Name] | [ ] | [ ] | [ ]% | [ ] |
| [Name] | [ ] | [ ] | [ ]% | [ ] |
| [Name] | [ ] | [ ] | [ ]% | [ ] |
| [Name] | [ ] | [ ] | [ ]% | [ ] |
| Total | [ ] | [ ] | 100% | |

Excel set-up: share in column D is `=C2/SUM($C$2:$C$6)`; the flag is `=IF(ABS(D2-1/COUNT($C$2:$C$6))>0.05,"review","ok")`.

## 9. Conflict and escalation process

<!-- Guidance: Agree the steps now, in order. Most problems end at step 1 or 2 if they are raised early. Pitfall: skipping straight to the instructor, or saying nothing until the peer evaluation. -->

| Step | Who | What | Time limit |
|---|---|---|---|
| 1. Direct conversation | The two people involved | Raise it privately using Situation, Behaviour, Impact (see mba/mba-peer-feedback); ask about intent; agree one change | Within [3] days of noticing |
| 2. Team discussion | Whole team, facilitated by a member not involved | Review the relevant norm or ledger; agree a specific change, owner and date | At the next check-in |
| 3. Written agreement | Whole team | Record the agreed change and a review date in this charter's change log | Within [1] week |
| 4. Coach or faculty | Team with the section coach, teaching assistant or instructor | Follow the course's published process for team problems | When steps 1 to 3 have not worked, or immediately for integrity, harassment or safety issues |

Separate the two kinds of conflict. Task conflict ("I think the discount rate is too low") is handled in the meeting
with evidence and the decision rules of Section 7. Relationship conflict ("you keep dismissing my points") is handled
privately first, with specific behaviour and its impact, not with labels about personality.

Some issues bypass the steps entirely: suspected academic integrity breaches, harassment or discrimination, threats to
anyone's safety or wellbeing. Go to the school's designated office or the instructor directly, using the process your
programme publishes.

## 10. Psychological safety agreement

<!-- Guidance: Discuss and adapt these commitments. Then name the specific moments when the team will practise them (for example, the "I am not sure about this" round before every problem set). -->

We agree to the following behaviours, which make it easier for every member to ask, admit and challenge:

- Anyone can say "I do not understand this yet" without explanation or judgement, and the team treats it as useful.
- We critique ideas and analysis, not people. We say "this assumption looks high" rather than "your model is wrong".
- The person who finds a mistake in their own work and says so is thanked.
- We ask the quietest member for their view before closing a discussion.
- We do not share a teammate's mistakes, struggles or personal information outside the team.
- Before every graded deliverable we run a two-minute round: "What part of this are you least sure about?"
- Disagreement with the facilitator or with a majority view is expected, especially from the devil's advocate.

Edmondson's construct is about the team climate, not about being comfortable or lowering standards. A psychologically
safe team can be highly demanding; members simply do not fear humiliation or punishment for raising questions,
concerns or errors.

## 11. Review checkpoints

<!-- Guidance: Put the dates in the calendar now. Each review takes 20 to 30 minutes and ends with a revised charter version. -->

| Checkpoint | When | Questions |
|---|---|---|
| CP-1 After the first graded deliverable | [Week 3] | Which norms did we actually follow? What surprised us? Change at most three things |
| CP-2 Midpoint review | [Week 6 or 7] | Are the goals still right? Is workload fair (ledger)? Run a round of peer feedback |
| CP-3 Before the final project | [Week 10] | Roles for the final push, quality standard, contingency if someone is ill |
| CP-4 Adjourning | [Final week] | What will each of us take into the next team? Formal peer evaluation |

## 12. Filled example

<!-- Guidance: A compact filled charter for a fictional team. Use it to calibrate the level of detail, then delete it. -->

*Example.* Learning Team 4 at a fictional programme ("School A") has five members: Hana (supply-chain analyst),
Kwame (army logistics officer), Lucia (marketing at a consumer-goods firm), Mateo (software engineer) and Priya
(audit associate). Kwame is in a time zone eight hours behind for the first two weeks while finishing a posting.

| Section | *Example* entry |
|---|---|
| Purpose | Prepare all core cases together; deliver four graded team assignments in Term 1 |
| G-01 Performance | Every team deliverable submitted 12 hours before the deadline with a full read-through |
| G-02 Learning | Every member builds one financial model and leads one strategy deck during the term |
| G-03 Process | Weekly check-in held every week; ledger updated every Friday |
| Norm: preparation | Individual answers posted in the shared folder by 20:00 the night before the prep meeting |
| Norm: response time | Weekday messages answered within 12 hours; no messages expected 22:00 to 07:00 local time |
| Norm: AI use | Follow each course's rule, recorded in Section 1; any AI assistance noted in the draft's comments for the team to see |
| Roles | Facilitator, timekeeper, note-taker rotate alphabetically each week; Mateo leads the operations simulation, Priya the accounting problem set |
| Decision rule | Consensus on recommendations; fallback majority vote with dissent noted |
| Conflict step 1 | Private conversation within three days, using SBI |
| Meetings | Prep sessions Monday and Wednesday 18:00 to 19:30, check-in Friday 12:30 to 13:00 |

The cadence of two 90-minute sessions and one 30-minute check-in a week amounts to 3.5 hours of meetings per member per
week, or 42 hours over a 12-week term. The team agreed this was the maximum and that sessions would end on time.

Workload ledger after week 4 (planned 14 hours each, 70 in total):

| Member | Planned hours | Actual hours | Share of actual | Flag (more than 5 points from 20%) |
|---|---|---|---|---|
| Hana *(Example)* | 14 | 16 | 22.9% | no |
| Kwame *(Example)* | 14 | 9 | 12.9% | review |
| Lucia *(Example)* | 14 | 15 | 21.4% | no |
| Mateo *(Example)* | 14 | 13 | 18.6% | no |
| Priya *(Example)* | 14 | 17 | 24.3% | no |
| Total | 70 | 70 | 100% | |

At the week-4 check-in the facilitator raised Kwame's share as a planning question. Kwame explained that the time-zone
gap had kept him out of two work sessions; the team moved one session to a time that suited both time zones and gave
him the lead on the next case write-up, where asynchronous work suits his situation. The flag was cleared at the
midpoint review. Nobody waited for the end-of-term peer evaluation to raise it.

## 13. Change log

<!-- Guidance: Record every agreed change with the reason, so the charter shows how the team learned. -->

| Date | Section | Change | Reason | Agreed by |
|---|---|---|---|---|
| YYYY-MM-DD *(Example)* | 6 | Friday check-in moved to 12:30 | Fits both time zones | All |
| YYYY-MM-DD | [ ] | [ ] | [ ] | [ ] |

## Common mistakes

<!-- Guidance: Read before your first checkpoint review. -->

1. Writing values instead of behaviours ("we respect each other"), so nobody can tell when a norm is broken.
2. Letting one member write the charter alone; others sign without owning it.
3. Never reviewing the charter, so it describes the team of week one, not the team of week eight.
4. Making the most experienced member the permanent lead on every deliverable, which blocks everyone else's learning
   goals and overloads that member.
5. Dividing a deliverable into pieces that nobody integrates, producing a report with four styles and inconsistent numbers.
6. Treating silence in a meeting as agreement.
7. Avoiding all disagreement to keep the peace; unresolved task issues return later as relationship conflict.
8. Raising contribution problems for the first time in the final peer evaluation.
9. Ignoring course-specific collaboration and AI rules, or assuming one course's rule applies to all.
10. Letting meetings rebuild the analysis together instead of reviewing work prepared in advance.

## Self-test

<!-- Guidance: Answer from memory, then check the Answer key. -->

1. Name the five stages in Tuckman's sequence as extended by Tuckman and Jensen (1977).
2. What did Edmondson (1999) find about the relationship between team psychological safety and learning behaviour?
3. List Hackman's (2002) five conditions for team effectiveness.
4. Why does a workload ledger reduce social loafing?
5. What is the difference between task conflict and relationship conflict, and how does this charter handle each?
6. Rewrite the norm "we are responsive" as an observable behaviour.
7. In the filled example, why was Kwame's share flagged, and what is the computation behind the flag?
8. Which issues should bypass the team's escalation steps?

## My notes and next steps

<!-- Guidance: Each member writes one line after the first meeting and after each checkpoint. -->

What I will do differently in this team: [ ]. One norm I find hard to keep: [ ]. Next checkpoint date: YYYY-MM-DD.

## Sources and further reading

<!-- Guidance: Primary works first; textbooks by name only. -->

- Tuckman, B. W. (1965). Developmental sequence in small groups. *Psychological Bulletin*, 63(6), 384-399.
- Tuckman, B. W., and Jensen, M. A. C. (1977). Stages of small-group development revisited. *Group and Organization
  Studies*, 2(4), 419-427.
- Gersick, C. J. G. (1988). Time and transition in work teams: toward a new model of group development. *Academy of
  Management Journal*, 31(1), 9-41.
- Edmondson, A. (1999). Psychological safety and learning behavior in work teams. *Administrative Science Quarterly*,
  44(2), 350-383.
- Hackman, J. R. (2002). *Leading Teams: Setting the Stage for Great Performances*. Harvard Business School Press.
- Latané, B., Williams, K., and Harkins, S. (1979). Many hands make light the work: the causes and consequences of
  social loafing. *Journal of Personality and Social Psychology*, 37(6), 822-832.
- Jehn, K. A. (1995). A multimethod examination of the benefits and detriments of intragroup conflict.
  *Administrative Science Quarterly*, 40(2), 256-282.
- De Dreu, C. K. W., and Weingart, L. R. (2003). Task versus relationship conflict, team performance, and team member
  satisfaction: a meta-analysis. *Journal of Applied Psychology*, 88(4), 741-749.
- Further reading (by name only): Edmondson, *The Fearless Organization* (2018); Robbins and Judge, *Organizational
  Behavior*; OpenStax, *Principles of Management* (CC BY-NC-SA 4.0), chapter on teamwork.

## Answer key

<!-- Guidance: Check after attempting the self-test. -->

1. Forming, storming, norming, performing, adjourning.
2. Team psychological safety was associated with learning behaviour (asking for help, seeking feedback, discussing
   errors), and learning behaviour was associated with team performance.
3. A real team, a compelling direction, an enabling structure, a supportive context and expert coaching.
4. Social loafing increases when individual contributions cannot be identified; the ledger makes each member's
   contribution visible every week.
5. Task conflict is disagreement about the work (assumptions, methods, recommendations); relationship conflict is
   personal friction. Task conflict is resolved in meetings with evidence and the decision rules; relationship conflict
   is raised privately first with specific behaviour and impact, then through the escalation steps.
6. For example: "We reply to team messages within 12 hours on weekdays."
7. His actual hours were 9 of 70, a share of 12.9%, which is 7.1 percentage points below an equal share of 20%,
   beyond the agreed 5-point trigger. Excel: `=9/70` and `=ABS(9/70-1/5)>0.05`.
8. Suspected academic integrity breaches, harassment or discrimination, and threats to safety or wellbeing.

## Revision history

<!-- Guidance: Update at every checkpoint review. -->

| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 | YYYY-MM-DD | [Team] | First charter agreed |
| [1.1] | YYYY-MM-DD | [Team] | [Changes after checkpoint 1] |

## Standard and licence note

Based on published research on team development (Tuckman 1965; Tuckman and Jensen 1977; Gersick 1988), team
psychological safety (Edmondson 1999), team effectiveness conditions (Hackman 2002), social loafing and intragroup
conflict, summarised in original wording. The Situation-Behavior-Impact model referenced in the conflict process is a
trademark of the Center for Creative Leadership and is named only to identify the method. This template is original
text written for this collection; it is not a school's official team contract and is not affiliated with or endorsed
by any business school or publisher. Check your programme's current rules on teamwork, peer evaluation, collaboration
and AI use before relying on it. All people and teams in the example are fictional. Template licence: MIT.