Onboarding a new teammate into a running system
The seventh person starts on a Monday. By Wednesday somebody notices they have been quietly stuck since lunchtime on their first day, and nobody can say exactly what on.
Small companies are good at hiring and bad at the fortnight afterwards. Not through carelessness, but through a specific and forgivable mistake: the people already inside cannot see the system any more. They have been living in it for two years. It looks to them like the way things obviously are.
What onboarding usually looks like
Here is the honest version of what most small companies hand a new person.
A list of links, assembled the night before. Three or four tool invitations, one of which will not arrive. A document that was accurate eleven months ago. A short conversation about what the company does, from whoever had a free hour. And then the sentence that does all the real work: ask me if you have questions.
That sentence sounds generous. In practice it puts the whole burden of onboarding on the person who knows the least. To ask a question you have to know a question exists, and the new person does not know what they do not know. So they ask about the small, visible, low-stakes things, while what will actually cost them a month goes unasked.
Joining something that is already moving
It helps to say plainly what a new person is walking into. Not a blank project. A system already running, with commitments made, dates set, and half a dozen conversations in progress that they are now somehow responsible for parts of.
That is not a bad thing. It is the whole value of joining a company rather than starting one. But it means the first question is not “what should you do?” It is “what is already true, and which parts of it are yours?”
Answering that well means being precise about two lists: what they can see, and what they cannot.
What they can see on the first day
A new person should be able to open the system on day one and find four things without asking anybody.
Their own messages, the direct ones addressed to them and the groups they have been put into. This is the fastest way to learn how a company actually talks: not the tone in the handbook, the tone in the threads.
Their own todos. Whatever has already been assigned to them, in the same place everybody else keeps theirs. An empty list is fine and honest; a list that lives somewhere else is not.
The dates attached to those todos, laid out on a calendar by due date. A new person’s biggest fear in week one is being late to something nobody told them about. A calendar of deadlines answers that fear before it has formed.
The company’s quarterly goals. Small companies chronically under-explain the quarter to new people, because everyone else absorbed it over six weeks of conversation. Ten minutes on the first afternoon saves a month of slightly wrong work.
What access checks still need evidence
Just as important, and less often said out loud: verify archive access with production administrator and non-member requests before describing it as settled.
A new teammate should be told which access boundaries have been checked and which remain open. The deployed revision is unknown, and production administrator/non-member checks across all private-message read paths remain pending.
Say what has been tested explicitly on the first day. New people often assume everyone senior sees everything; a production administrator/non-member comparison is still needed to answer that question.
The shape of the first week
Weeks one through four are not one undifferentiated blur, and it is worth having a shape rather than an aspiration.
The first two days are for reading and for one real task. Not a fake one. Something small, genuinely needed, with a real due date, finished by the end of day two. Nothing teaches a system like having to use it once under mild time pressure.
The rest of the first week is for the second and third tasks, and for being told who to ask about what: not a directory, a short mapping. Three names, three areas. Small companies have this knowledge and almost never write it down.
By the end of week two, the new person should have made one commitment with a date on it that somebody else is relying on. That is the real threshold. Before it they are learning. After it they are in the system.
A chief of staff that starts empty
There is one asymmetry worth planning for. Product materials describe a chief of staff for each person, but the current production revision and model context have not been verified. A per-person interface does not prove that earlier company context is excluded.
Explain what is known and what remains open rather than promising an empty start, a complete history search, or that every saved Memory item requires separate confirmation. Ask the product owner for the current behavior before making those promises.
Which means week one is quieter than week six will be, and that is fine. Tell them so. A new person who expects an empty start will use it. One who expects an oracle will ask two questions, get two shrugs, and never open it again.
What the administrator actually has to do
Strip it down and there are three jobs, none of which takes long.
Invite them on the first morning, before they arrive if possible. An account that exists at nine o’clock is worth more than a well-written welcome document at eleven.
Assign them something real. One todo with a date on it. Put them in the groups they belong in, and not in the ones they do not.
Explain what access has and has not been verified. Do not present the administrator boundary for private messages as settled.
Do not onboard by making them read everything
The most common well-intentioned mistake is handing a new person the archive and telling them to catch up.
It does not work, for a plain reason: context is not in the record, it is in what people chose not to write down. Reading six months of threads gives the surface of every decision and the substance of none, and costs a week that would have taught them more.
Give them the current quarter, the threads they are actually in, and one real task. Let the history arrive the way it arrives for everyone, which is in pieces, when it becomes relevant, usually in the middle of a conversation about something else.
Where Opitor fits
Opitor is an AI-native operating system for small companies, with messages, todos, deadlines, quarterly goals and a Memory feature in its product materials. Production administrator/non-member comparisons and checks across all private-message, todo and memory read paths remain pending. The current review also does not establish the memory creation or approval flow, model access, or deletion and retention behavior. Review those boundaries with a new teammate instead of promising a personal-only workspace. More on the current evidence is on what is an AI chief of staff and the questions and answers page.
Updated 2026-09-25