Use case
Project onboarding
New joiners do not need everything. They need the current state, the people, and permission to ask basic questions without feeling slow.
How do you onboard someone onto an existing project?
Give them a Brief instead of a reading list. It carries the current status, the decisions already made, who owns what, and the open items — and it answers the obvious questions privately, as many times as they need, without costing anyone else an hour.
Why onboarding drags
- A reading list of forty documents, most of them historical.
- The same five questions asked of five different people, answered five different ways.
- Nobody wants to ask the obvious question in week three.
- The onboarding doc was written for the last project shape.
A one-week onboarding
- Step 1
Scope to current state
Include what is true now. Archive the history unless it explains a live constraint.
- Step 2
Name the people
Roles and ownership are the single highest-value thing a new joiner cannot infer.
- Step 3
Let them ask privately
They can ask the basic question ten times. Nobody is counting.
- Step 4
Watch what they ask
Repeated 'unknown' answers show you exactly where your project documentation is thin.
What a new joiner needs first
Orientation
- What this project is for
- Where it currently stands
- What ships next
People
- Who owns which area
- Who approves
- Who to ask about the codebase, the client, the budget
Constraints
- Fixed dates
- Decisions that are closed
- Known risks
The questions new joiners are afraid to ask
These are the ones that cost a week when they go unasked.
- What does this project actually deliver?
- Who decides when we disagree?
- Why was it built this way?
- What is the deadline that cannot move?
- What should I not touch yet?
Why it beats a wiki
- It is built from the live material, not maintained separately.
- Answers cite the source, so a new joiner learns where things live.
- Gaps are visible: 'unknown' tells them what to ask a person.
Onboarding Brief checklist
- Current status update.
- Ownership map.
- The two or three decisions that constrain everything else.
- Live risks.
- A note on team norms that no document states.
Common questions
- How does a Brief work?
- You add sources, Brieflin extracts the structure, you review and correct what it understood, then you publish one link. Recipients open the link without an account and ask questions in plain language. Each answer is generated only from your sources and cites the passage behind it. You can revoke the link at any time.
- How is Brieflin different from a knowledge base?
- A knowledge base is maintained for an ongoing audience and decays when nobody curates it. A Brief is scoped to one project or engagement and one transfer moment. It is built from the material that already exists rather than written from scratch, and it is meant to be handed over rather than maintained forever.
Stop onboarding by meeting
Build one Brief per project and reuse it for every joiner.