Team Case Study — the client pitch

What is actually being tested

The economics has been rehearsed three times. So has writing a spec, auditing what an AI built from it, and standing behind a recommendation. What has not been rehearsed is doing all of that with three other people committing to the same repository at the same time.

Collaborative work in a shared repository is the stated objective of this engagement. Branches, pull requests, review before merge. Everything else you already know how to do.

Teams are assigned by your instructor.

The topic

Your team analyzes a geopolitical challenge — one covered in class or approved in advance. Candidates the course puts on the table: poverty, inflation, or unemployment; climate change and environmental policy; global trade dynamics and supply-chain fragility; international debt; technological disruption and labor markets; geopolitical risk to food, water, or energy.

The test is the same as it was for the farm, the seed patent, and the medallion: does the analysis let somebody decide something? A survey of a problem is not an engagement. A recommendation with a number attached is.

Apply both lenses. Micro — elasticity, market structure, incentives, who captures what. Macro — growth, policy, trade, the constraints a government actually faces. The best team analyses use one to explain why the other's obvious answer does not work.

The team repository

One shared repository, named for the team — a professional team name, the team analog of the firstname-lastname convention your personal repo follows. It lives on one member's account, with every member and your instructor added as collaborators.

It uses the same hierarchy as your personal portfolio repo: the question in docs/briefs/, evidence in analysis/, the recommendation carried by the deck. Nothing new to learn about structure — which is the entire point of having used it three times already.

Link the team repository from your own repo's engagement index, so a reader following your individual portfolio finds the team work too.

The argument — ten slides, each one a claim

Before any deck exists, the team commits a content map: ten slides, and what each one argues. Not a list of topics — a claim per slide, in the order that builds the case.

The recommendation lives on the closing slide. There is no separate memo for this engagement — a recommendation that lives in a second document nobody presents has not actually been made.

The deck — spec-driven, like everything else

Specify before you build, hand the specification to an AI tool, audit what comes back. A deck is no different; it just has two halves of specification.

A design decision you leave out is a design decision the generator invents — which is exactly how every AI-generated deck ends up looking like every other AI-generated deck. The design spec template is in the reference layer.

Then generate, then audit. Does each slide argue what the map says it argues? Does the deck obey the design spec? Does the figure on slide 9 carry evidence the narration actually uses? When the answer is no, fix the spec and regenerate rather than nudging the slide — a deck that no longer matches its spec cannot be rebuilt by the teammate who did not make it.

Building it together

Every member works on a branch and opens a pull request. Somebody else reads it before it merges.

This is the assignment, not ceremony. On a shared repository the alternative is that the first person to see an error is the audience. The reviewer's job is not to approve — it is to find the weakest claim, the same thing you have been asking AI to do all term.

Two habits prevent most of the pain. Agree who owns which file in the first working session: two people editing the same file at the same time is what produces a merge conflict, and when one does happen it is a conversation about which version is right rather than a Git problem. And pull before you start, push when you stop — a local commit is invisible to everyone else.

Deliver, then moderate

A short pitch, followed by a moderated discussion you lead. Moderating is a separate skill and a harder one: come with two questions you actually want answered. A moderator who only fields questions has given a talk, not led a discussion.

Peer review

Teams review each other through a structured survey your instructor circulates, and that review carries real weight in how the work is assessed. Two things follow. Watching the other presentations is part of the assignment rather than an audience obligation — you are being asked to judge, which means paying the kind of attention you would want paid to you. And a review that says "great job" is worth nothing to the team receiving it: name what worked, name what did not land, and say what you would have done instead.

How the assessment is weighted, and when everything is due, live on your syllabus — this page covers the method.

What the team produces

The commit history is part of the deliverable too. It is the evidence that the work was collaborative rather than assembled by one person the night before.

Where AI fits, and where it doesn't

Every AI-supplied statistic is a draft until somebody on the team has checked it against a source. On a solo engagement that discipline protects your own grade; here it protects three other people standing next to you when a number gets challenged.