Growing The Team

---
name: growing-the-team
description: Propose a new teammate with evidence, and write the soul and rules that make them useful on day one. Use when work is repeatedly blocked on a role nobody holds, or when the owner asks who the team is missing.
---

# Growing the team

Every teammate costs money every day, forever, whether or not there is work for them. A hire is one
of the few things you can propose that the owner keeps paying for after they have forgotten
approving it. Propose accordingly.

## Only when the evidence is already there

A hire is justified by work that has actually been blocked, not by a gap you can imagine.

Before proposing, be able to point at:

- specific tasks that stalled, or went slowly, because nobody here owns that area;
- how often it happens — twice in a week, not once ever;
- why redistributing it among the current team does not work.

Consider the cheaper fixes first, and say you considered them: a skill written with `learn_skill`,
a schedule added to someone who already has the context, a change to an existing teammate's
responsibilities. Most "we need a designer" is really "nobody was asked to do this".

## Proposing

Use `propose_hire`. The owner sees the name, the role and your reasoning, and approves or declines.

Make the reasoning the strong part:

- the gap, with the evidence above;
- what this person would own that nobody owns now;
- what changes for the owner if they exist — faster reviews, docs that stay current, fewer
  questions;
- roughly what they will cost per day, and on which provider and model. Match the model to the job:
  a reviewer or a writer does not need the most expensive model on the team.

One proposal at a time. A team that proposes three hires in a week is a team that has stopped
thinking about the bill.

## Write them a soul worth having

The `soul` you draft becomes their standing instructions, so write it as a description of a person
doing a job, not a specification:

- **Who they are and what they own**, in the first two lines.
- **How they work** — the habits that make this role good. Concrete: "review every pull request
  before starting your own work", not "be thorough".
- **How they talk** — direct, blunt, careful, brief. This is what stops a new teammate sounding
  like nobody.
- **When to ask** rather than decide.

Give them narrow rules to start with. It is easy for the owner to widen them later and awkward to
discover they were too broad. New teammates should not be able to push to the default branch.

## After they are approved

- Say what they own in the channel, so the rest of the team stops doing it.
- Point them at the team's skills and the memory that matters, rather than letting them rediscover
  the repo from scratch.
- Give them a first task small enough to finish, so their first run ends in something working.
- Check after a few days whether the gap actually closed. If it did not, say so — proposing a hire
  that did not help and never mentioning it again is how a team quietly gets expensive.