What is a YAGNI Team, and what are its three sizes?

What does a Team carry?

The scope. A Team holds the one sentence it owns (its Responsibilities, which every line reads as grounding), the repositories it works on, the tickets it works from, the Playbook it has learned, its members and answerers, its audience, and Pause, the brake that stops every line at once. It reports to exactly one accountable person, its owner.

What a Team does not carry is the execution. Agents do that, each through lines on the Team: Bailey proposes, Reeve reads plans, Wright plans and builds to a draft pull request, Proctor reviews it, Fletcher walks it in a browser, and Harper reports. Work is credited to the Agent that did it, on the Team it served: “Wright opened this on Checkout.”

Why does a Team mirror a team, not a repository?

Because review norms and accountability live with people, not with folders. A repository has no opinion about what “ready to merge” means at your company. Your Checkout team does. So repositories attach to the Team, and a Team commonly holds several. One Team reviews a repository, first claim standing, which is what keeps two Teams from posting competing reviews on the same pull request.

What are the three sizes?

One noun, offered in this order when you create a Team:

Size	Works from	Lines on from day one
My tickets	The tickets assigned to you in Linear or Jira	Wright plans and builds, Reeve reads plans, Proctor reviews
The backlog	A Linear or Jira project or epic, or a repository’s issues	Bailey proposes, plus the three above
Pull request reviews	Every pull request opened on the repositories	Proctor alone

They differ in whose tickets the Team works from and which lines are on, and in nothing else. Growing a Team is adding a line, never migrating it. My tickets is the default, because it is the size one engineer can start alone in a few minutes and see a ticket ship from.

How do you create one?

On one screen, at Create a Team. Pick the repositories from the ones your GitHub App installation covers (a search, multi-select; they are added to the workspace on Create), choose a size, and click Create. The backlog size also asks for the project it reads and the one sentence the Team owns. The right column shows day one before you commit: which lines will be on, which are add later, and whether each waits for you or runs on its own.

The Team is named for you: “Checkout” from the repository, or “Priya’s team” for your own tickets. Any workspace member can create one, and the owner of a Team manages their own.

What does the Team page show?

The whole configuration, and nothing that is not. At the top, the name, the sentence it owns, and one scope line: “Works on acme/checkout · reads the Checkout project in Linear · posts to #checkout · asks Priya about product · seen by everyone · Edit.” Edit opens a sheet for the name, the owns sentence, the repositories, the tracker project, the Slack channel, the answerers, the audience, Pause, and Archive. There is no Team settings page.

Below that, one row per line, grouped under the six stage words a ticket walks: Proposed, Plan, Build, Review, QA, Done, then Any time for Harper’s reports. Each row is one sentence with its Authority inside it, “Proctor reviews every PR on acme/checkout, supervised by Priya”, and it opens on its own page. Lines, Rhythm, and Authority covers what is on that page. Three cards close the Team: the Playbook, the People, and This month’s spend against the ceiling.

Can Teams work in parallel?

Yes, and they should. A Checkout Team and a Platform Team run at the same time, each ticket in its own sandbox, so their builds and browser walks never collide. What they share is knowledge: the decision ledger is workspace-wide, so a question your company already answered is not re-derived by each Team in turn. Method stays local: the Playbook belongs to the Team that learned it.

When should you add a Team?

When a scope has an owner-shaped hole. If you can name the outcome, the person on the hook, and the repositories involved, it is a Team. If you cannot, it is probably work for a Team you already have, and a ticket you add to it from the tracker.

Start with the smallest size that is true for you. Every line that matters starts supervised on the Ladder, and merge is always a person’s click, so the cost of starting is a review, not a risk. Widen a line when its record earns it.