Working with teams

Adding a team

You add a team when a class of work is becoming permanent enough to deserve durable ownership. Ask yourself:

• Is the same kind of work coming up repeatedly — Across different teams, or showing up in your Inbox often. Repeated similar work without a stable owner is the canonical sign.
• Does it have a measurable outcome — A team needs outcome pressure — something the company can tell whether it’s succeeding at. If you can’t name the outcome, the team won’t have anything to optimize against.
• Does it need durable memory — Some work benefits from accumulated context that a persistent team builds up over time. Other work is one-off enough that a temporary owner is fine.

To propose a team, tell the CEO. Something like: “We need a customer support team. Mandate: handle inbound questions, prioritize by severity, escalate anything that needs my judgment. Budget: $X / month. Outcome metric: first-response time under Y hours.”

The CEO will propose a concrete shape: which persistent agents the team should have, what skills they should be attached to, what authority the team gets. You approve (or revise) before it’s real. After approval, the team starts admitting work.

Writing a good mandate

The mandate is the single most important thing about a team. A vague mandate produces a team that accepts work it shouldn’t, refuses work it should take, and can’t be measured against any outcome. Things a good mandate captures:

• What the team owns — Concrete, scoped. “Inbound customer questions across email and chat,” not “customer stuff.”
• What it’s allowed to do — Authority limits. Can it issue refunds up to $X? Can it commit to feature requests? Can it pull in another team?
• What outcomes it’s on the hook for — The team’s KPIs — the measurable things you can hold the team accountable for.
• What stays outside its scope — What it should explicitly refuse to admit, or escalate to another team. Stops scope creep.

Changing a mandate

Mandates aren’t set in stone. When the work the team is doing has drifted, or you want it to focus differently, you change the mandate. Tell the CEO what should change and why. The CEO will:

• Surface affected in-flight work — Work items the team is currently driving that may no longer fit. You decide: complete them, cancel them, or transfer to a different team.
• Update authority and outcome metrics — If the new mandate carries different authority or different KPIs, those get updated.
• Record the change — The mandate change goes into the company’s memory with rationale. The team knows what it used to be responsible for and what changed.

Pausing a team

Pause a team when you need it to stop without losing what it has. Pausing stops new work admission and prevents the team’s agents from waking. Existing in-flight runs may complete depending on policy. State, memory, and configuration are preserved.

Common reasons to pause:

• You’re rethinking the team’s mandate and don’t want it to keep operating on the old one.
• The team is consistently failing and you need time to diagnose before it does more damage.
• A budget overrun and you want to halt spending until you’ve adjusted limits.
• A strategic shift means the team’s area isn’t a priority right now.

Pausing requires a reason text — it’s recorded in the team’s history so the next person to look (you, the CEO, another team) knows why.

Resuming brings the team back into normal operation. Pause and resume are reversible.

Retiring a team

Retiring is stronger than pausing. A retired team doesn’t come back. Before retiring, the team’s mandate needs closure: existing work items need to be completed, transferred, or canceled; any external promises tied to the team need explicit handling; the team’s memory either rolls up into the broader company knowledgebase or gets archived.

When you decide to retire a team, tell the CEO. The CEO will surface what needs closure and propose how to handle each piece. You approve, the closures happen, then the team retires.