Use cases · A software team
A software team
A small team where every assistant knows what is theirs to do. The people decide what gets built, how it is split, and when it is done.
The situation
Larkspur makes invoicing software, with five people: Jo looks after the product, Theo leads the engineering, and Ana, Ben and Sam build it. Everyone already works with an assistant. Each one is good at the task in front of it and knows nothing about the rest of the team, so the team does the connecting by hand: pasting the ticket into the chat, explaining the spec again, asking who is reviewing what, copying results back into the tracker.
They keep their tools: the code stays on GitHub, the tickets in Linear. What changes is that the team’s work, and how they do it, is now somewhere every assistant can find it.
One way of working, written down once
Theo asked an assistant to set it up. The team’s roles are written down: what product decides, what a review checks, what “done” means for a piece of work, and who it goes to next. Each role has a place where its work arrives and a page showing what is waiting. When someone finishes their part, the work moves on to the next person. Theo’s assistant does that twice a day, and anyone can ask for it sooner.
Jo decides what gets built
You: Three customers have asked support for their invoices in a spreadsheet. Log it.
Assistant: Before I do: a similar request, bulk PDF download of invoices, was dropped in June because the accounting integrations covered it. Is this the same thing?
You: No. These customers don’t use an accounting tool. They just want a CSV.
Assistant: Logged as “Invoice CSV export”, linked to the June request, and opened in Linear. Accept it now?
You: Yes, priority two. Let’s write the spec tomorrow.
The assistant checked first whether this had been asked for before, and why it was dropped. Jo still made the call. The next day Jo wrote the spec with the assistant while Theo added notes to the same document, and neither of them overwrote the other.
Theo decides how it is split
Theo’s page shows what is waiting, already prepared:
Waiting on you: three things
All three are prepared. The spec for the invoice CSV export was approved by Jo yesterday.
- Split up: Invoice CSV exportDecide
Spec approved. Ben’s work on invoice queries in August looks related.
- Review: invoice CSV APIReview
Ben’s change. A first read is ready, with one question about large date ranges.
- Notes on our instructionsRead
Two this week, both about how reviews are handed back.
One click hands the request to Theo’s assistant. It reads the spec, finds Ben’s earlier work on the same part of the code, and proposes two pieces: the API and the screen. Theo approves. Ben gets the API, because billing is Ben’s area; the screen goes to whoever takes it first.
Ana’s assistant picks it up, already briefed
You: What’s waiting for me?
Assistant: The screen for the invoice CSV export. Theo split the work yesterday; the API half is Ben’s. One thing changed since then: Jo added a date-range filter to the spec this morning. The reports page already has a date-range picker we can reuse.
You: Good. Start it, and use that picker.
Nobody briefed it. It knew what the work was, which version of the spec it is judged against, and that the spec had changed since the work was split. When Ben’s change landed first and clashed with Ana’s, the assistant reconciled the two, which is ordinary work for an assistant and needed nobody to plan around it.
People decide; assistants prepare
Ben reviewed the screen with an assistant’s first read beside it and asked for one change. Sam tested it against the spec and caught a time-zone problem. Jo accepted the finished work after Jo’s assistant checked it against what the spec promised. At each step the work arrived ready, and a person made the call. Linear was kept up to date along the way, as part of the work.
Two weeks later
Two weeks later, a new chat, on a phone
You: Where did the CSV export end up?
Assistant: Released last Thursday. It took two pieces of work, one round of review changes on the screen, and a fix for time zones that testing caught. Three customers asked for it; support has the release notes.
One place holds the whole story of every piece of work: who had it, what they decided, what it is waiting on. So the answer is there in any conversation, for anyone on the team, and on one page for anyone who would rather look:
Where everything stands
Four pieces of work in progress. One is waiting on a decision from Jo.
- Invoice CSV exportDone
- Bulk refundsIn review
- Date ranges on reportsBuilding
- Single sign-on for teamsWaiting on Jo
Better every week
Every session leaves a short note on how the team’s instructions held up. Theo reads them, and the changes are reviewed like any other change to the code. When Ana’s note said the build instructions should point at the components that already exist, every assistant on the team started doing that from the next morning.
More stories
- Candidate search Hands over a job description, reviews the shortlist, and their feedback steers the next round.
- What to post about The assistant keeps track of the topics in their area and what they have posted on, and drafts on what is worth posting today. They approve, edit or discard.
- Relationships at scale Says who counts. The assistant finds the people, writes each a personal note, and keeps track of every conversation. Nothing is sent without them.
- Looking for a job Says once what they want. The assistant finds and screens openings, drafts what each one asks for, and applies to the ones they approve.
- Watching competitors Names the products and the competitors. The assistant matches them across sites, checks every week, and shows what changed.
- Every page, reviewed Sets the goal and the rules once. The assistant goes over every page, records what it found and fixed, and brings back only what needs them.