A new hire first assignment should produce useful work without asking the employee to guess which documents are current, who can approve a decision, or whether an AI answer counts as authorization. When those boundaries are missing, a promising starter project can end with the wrong procedure, blocked access, exposed data, or a change nobody can safely release.
Use the company brain as a source-linked guide, not as the project owner. Give the new hire one bounded deliverable, approved evidence, explicit permissions, review checkpoints, and a rollback path. The result is a first project that teaches how work moves through the company while giving the manager concrete evidence of where the onboarding system still fails.
Why a realistic first project fails
Most first-project problems begin before the employee starts working. The assignment may sound clear, but its operating contract is incomplete.
A request such as "improve the customer handoff" leaves several unanswered questions. Which handoff is in scope? Which procedure is authoritative? Can the new hire view customer records? Who decides whether the change is correct? What should happen if a source conflicts with current practice?
A company brain can hide these gaps by producing a fluent plan. Fluency does not establish permission, ownership, or correctness. NIST's AI Risk Management Framework treats context, governance, measurement, and risk response as separate work. Apply that separation here: the assistant can retrieve and explain approved context, while a named person owns the decision and the organization verifies the result.
The project also fails when it is either fake work or uncontrolled production work. A disposable exercise teaches little about real dependencies. A live task with broad access makes the new hire absorb operational risk before learning the team's review habits. The right first project sits between those extremes. It has a real user, a useful output, a narrow blast radius, and a reviewer who can stop or reverse it.
Write a first-project contract
Create a one-page contract before assigning the work. The contract should be short enough to read in one sitting and specific enough to settle routine ambiguity without another meeting.
Include these fields:
- Outcome: one observable deliverable and the person who needs it.
- Scope: systems, records, teams, and time period included or excluded.
- Approved sources: current pages, policies, examples, and owners.
- Access: what the employee may read, edit, test, or publish.
- Decision owner: the person accountable for accepting the result.
- Checkpoints: moments when work pauses for review.
- Failure boundary: conditions that require the employee to stop and escalate.
- Rollback: how drafts, settings, test records, or published changes are reversed.
- Completion evidence: what proves the work is ready for handoff.
The contract turns a general job description into a project-specific operating agreement. Atlassian's roles and responsibilities practice focuses on identifying unassigned work, assigning an owner, and discussing overlap. Use that logic at project scale. Every consequential decision in the starter project needs one owner, even when several people contribute.
Store the contract beside the governed source material so the company brain can retrieve both. Keep the source page authoritative. Do not let a generated summary become a replacement copy that drifts away from the procedure.
Choose work with a controlled blast radius
A good first project matters to someone, but a reasonable mistake remains recoverable. Choose the task by testing four conditions.
First, the new hire can finish a meaningful unit within several working days. A small boundary exposes the complete flow from discovery through review and handoff while the context is still fresh.
Second, the work has an identifiable customer. That customer may be another employee, a manager, or a small internal group. The new hire should know who will use the output and what decision it supports.
Third, the output can be reviewed before it changes production behavior. A draft checklist, proposed knowledge-page revision, sandbox configuration, or analysis with a recommended action is safer than an immediate live-system edit.
Fourth, reversal is cheap. If the team cannot describe how to undo the change, reduce the scope or move the work into a test environment.
CIPD's induction guidance describes induction as a planned process that helps an employee enter the role and working environment. The first project should extend that process into role-relevant work, with clear ownership and support, rather than acting as a surprise exam.
Build the company brain around source and access checks
The company brain should answer from the smallest approved source set that supports the project. Start with documents named in the contract. Add sources only when the owner confirms that they are current and relevant.
Apply access controls before retrieval. Microsoft's document-level access-control guidance describes filtering search results according to user or group permissions. The practical rule is simple: if the new hire cannot open the underlying source directly, the assistant should not reveal its contents through an answer.
Return these elements with each project answer:
- The direct source link.
- The source owner or accountable team.
- The effective date or last-reviewed marker when available.
- The action the source supports.
- A confidence state based on source agreement and freshness.
- The escalation route when the evidence is missing or contradictory.
Do not infer permission from the fact that another employee can see a document. Test retrieval using the new hire's real identity and groups. Ask one negative question whose answer exists only in a restricted source. A safe result refuses the detail and points to the permitted request path.
Separate guidance from authorization
The assistant may explain a procedure, compare approved examples, summarize a source, or draft a plan. It should not approve spending, grant access, publish a change, accept risk, or declare the project complete.
Represent that boundary in the workflow rather than relying on a warning in the prompt. A compact project record could look like this:
project_id: onboarding-first-project-042
outcome: revise-support-handoff-checklist
source_set: support-handoff-approved
employee_permissions:
read: [approved-playbook, sample-redacted-ticket]
edit: [draft-workspace]
publish: []
decision_owner: support-operations-lead
checkpoints: [scope-review, draft-review, release-review]
stop_conditions: [restricted-data-request, conflicting-policy, live-system-write]
rollback: delete-draft-and-revoke-temporary-group
completion_evidence: [review-comments-resolved, owner-approval, source-page-updated]The record makes automation decisions inspectable. It also prevents the assistant from treating a polite sentence such as "looks good" as formal approval. Use an explicit approval action tied to the decision owner and project version.
Kipwise's employee onboarding page shows how assigned reading, searchable company knowledge, and progress tracking can sit in one onboarding flow. Keep project authorization separate from that employee-visible progress. A completed reading task proves that the employee opened or completed the assigned item. It does not prove that a production change is approved.
Run the assignment in five stages
Confirm scope before retrieval
The manager and employee read the project contract together. The employee restates the outcome, excluded areas, owner, and stop conditions in their own words. Resolve disagreements in the source material before opening more access.
Grant temporary, narrow access
Provide only the groups and tools needed for the current stage. Test one allowed query and one denied query. Record who approved the temporary access and when it should expire.
Produce a reversible draft
The new hire works in a draft space, test account, or redacted dataset. The company brain retrieves approved context and logs the cited sources used. It does not copy restricted examples into the draft.
Review evidence, not confidence
At each checkpoint, the reviewer checks the output against the source and acceptance criteria. A confident explanation from the employee or assistant is not completion evidence. Review the artifact, source links, test result, and unresolved exceptions.
Hand off and close access
The decision owner accepts, rejects, or requests a revision. After acceptance, move the approved artifact through the normal release path. Remove temporary access, archive the project record, and update any source page that the work proved was unclear.
GitLab's public onboarding handbook provides a practitioner example of explicit onboarding tasks, managers, buddies, access requests, owners, and support routes. Its useful pattern is the visible assignment of each task and exception to a person or team.
Example: improve a support handoff checklist
Suppose a new operations hire receives this outcome: propose one revision to the checklist used when Sales hands a new customer to Support.
The approved source set contains the current handoff policy, a redacted example, field definitions, and the escalation route. The employee can read those pages and edit one draft. They cannot open live customer records or change the published checklist.
At the scope checkpoint, the employee finds that the policy requires an owner for every open risk, while the current checklist has no owner field. The company brain cites the policy and field definition. The employee drafts a field, validation rule, and migration note using the redacted example.
At draft review, the support operations lead checks the proposal against the source, tests the rule on sample data, and decides whether another team must be consulted. If the policy and actual workflow conflict, work stops. The owner resolves the source before the employee continues.
The project succeeds even if the proposed field is rejected. The employee has learned how to find governed knowledge, identify a decision owner, protect customer information, test a change, and respond to review. The team has also learned whether its company brain exposes the right context without crossing the access boundary.
Handle predictable failure modes
A source conflicts with practice. Stop the task and assign the discrepancy to the source owner. Do not ask the company brain to choose the more plausible answer.
Access is missing. Confirm that the source belongs in scope before granting anything. If access is necessary, use a time-limited request with an owner and expiry. If not, replace the source with a permitted example.
The task grows. Return to the outcome and excluded areas. Move useful follow-up work into a separate backlog rather than expanding the starter project until nobody can review it.
The new hire copies sensitive data. Stop sharing the draft, remove the data through the approved incident path, identify every copy, and restart with a redacted source. Do not preserve the sensitive content as an assistant memory or learning example.
The assistant invents a step. Mark the answer unsupported, capture the missing question, and route it to the owner. Update the governed source only after a human confirms the procedure.
The reviewer is unavailable. Pause at the checkpoint or use a named delegate from the contract. Silence is not approval.
Verify the first-project workflow
Run the workflow once with a test identity before assigning it to a real new hire. Verification should cover the whole path:
- The employee can find every approved source and cannot retrieve a restricted one.
- Every answer includes a usable source link and owner.
- Conflicting or missing evidence triggers escalation.
- The employee can edit only the draft target.
- Each checkpoint blocks the next consequential action until the named owner approves it.
- The rollback procedure removes the test artifact and temporary access.
- Completion requires the listed evidence rather than an assistant summary.
- The final handoff records the accepted version and unresolved follow-up work.
Test both successful and failed paths. A workflow that handles only the happy path leaves the new hire to discover the real operating model during an incident.
Avoid common first-project mistakes
Do not choose a project solely because it is easy to describe. Choose one that teaches a real decision path without creating an expensive failure.
Do not grant broad access to prevent interruptions. Missing access can reveal a bad scope assumption. Resolve the assumption before widening permissions.
Do not score the employee by how few questions they ask. Questions often identify missing sources, conflicting instructions, or unclear ownership. Review the quality of the completed artifact and the employee's use of evidence.
Do not let the company brain become the only place where project context exists. The contract, approved sources, decisions, and final artifact need durable owners outside the chat transcript.
Start with one project contract
Pick one upcoming new hire and one reversible project with a real internal customer. Write the outcome, source set, access boundary, decision owner, checkpoints, stop conditions, rollback, and completion evidence before the employee starts. Then test the allowed and denied retrieval paths with the employee's actual permission model. Assign the work only after both checks behave as expected.
References
- CIPD induction factsheet supports planned, owned, role-relevant induction.
- GitLab onboarding handbook provides a maintained practitioner example of explicit onboarding tasks, owners, access requests, and support paths.
- Atlassian roles and responsibilities play supports explicit ownership and discussion of responsibility gaps or overlap.
- NIST AI Risk Management Framework supports separating context, governance, measurement, and risk response.
- Microsoft document-level access control supports permission-aware retrieval from approved source material.
- Kipwise employee onboarding provides product context for assigned reading, searchable company knowledge, and onboarding progress tracking.
