New manager onboarding often delivers the employee handbook and stops there. The manager learns how to file expenses, but not who approves a staffing exception, why the team changed its release process, or which performance records they may read. An AI company brain helps only when it supplies current, permission-filtered context instead of a large folder of generic documents. People Operations, IT, and knowledge managers need to build a manager-specific path, connect it to a practical 30-60-90 day plan, and test it before the manager acts on sensitive information.
Why a standard employee checklist is not enough
Every new manager is also a new employee, so the ordinary setup still matters. They need payroll access, security training, equipment, company policies, and a clear support route. The problem starts when that checklist is treated as the whole onboarding program.
Managers inherit decisions as well as tasks. They need to understand the team's goals, recurring meetings, service commitments, budget boundaries, approval paths, and current risks. They also encounter information that should not sit in a general onboarding collection, such as individual performance records or restricted planning material. A useful program must provide enough context for sound decisions without giving the manager a convenient way to search material outside their authority.
The GitLab onboarding handbook is a practical example of explicit onboarding tasks, role details, access requests, buddies, and named support. That structure is a sound starting point. For a manager, add a second layer that covers decision authority, team operating context, confidential evidence, and verification.
A generic company brain can still fail here. If it retrieves every page containing the word "manager," the result will mix company-wide guidance, team conventions, old plans, and restricted records. The answer may sound coherent while leaving the new manager unable to tell which instruction governs the current situation.
Define the manager context pack
Build a bounded context pack before configuring prompts or assigning reading. This is not a single document. It is a set of governed sources selected for the manager's current role, team, location, and decision scope.
Include these source groups:
- Company-wide employment, security, conduct, and operating policies that apply to every employee.
- Management policies for hiring, leave, expenses, performance processes, access requests, and escalation.
- Team sources for goals, responsibilities, meeting cadence, service levels, active commitments, and known operational risks.
- Decision records that explain why current routines or constraints exist.
- A directory of accountable owners for questions the company brain must not resolve by itself.
For each source, record a canonical identifier, owner, effective date or review state, intended audience, confidentiality class, and replacement source when retired. A page without an owner or reliable review state can remain discoverable for background, but it should not support a consequential instruction.
Do not import private notes merely because the new manager may eventually need them. Start with the minimum evidence required for current responsibilities. Add restricted sources through an approved entitlement, not through a broader index or a special prompt.
Map decision rights before generating answers
A manager cannot use context well if the system never says what they are allowed to decide. Create a decision-rights map that names the action, accountable owner, required evidence, approval threshold, and escalation route.
A simple record can look like this:
decision: approve_customer_credit
manager_scope: regional_support_manager
required_sources:
- credit-policy-current
- customer-risk-summary
approval_rule: finance_review_above_documented_threshold
fallback_owner: finance_operations
verification: approval_record_exists_before_customer_notificationThe company brain should use this map to distinguish guidance from authority. It may explain the current policy and collect the evidence for a request. It should not claim that an approval exists until the authoritative workflow records it.
This separation matters during the first weeks, when a manager may not know which team custom is optional and which company rule is binding. Answers should name the governing source, the manager's scope, any required approval, and the person who owns an exception.
The NIST AI Risk Management Framework organizes AI risk work around governance, context mapping, measurement, and management. Apply that discipline to the manager workflow: name the owner, state the use boundary, test expected behavior, and define what happens when the evidence is missing.
Enforce permissions before retrieval
Manager onboarding creates an obvious access trap. The title "manager" does not authorize someone to read every management document. A sales manager should not retrieve another department's performance records, and a newly hired team lead should not inherit the former manager's access by default.
NIST SP 800-207 rejects implicit trust and calls for access decisions based on current identity and resource context. Build the manager's knowledge access from the authoritative employee record, approved role rules, team membership, location, and any time-bounded assignments. Previous titles and copied group memberships are not authorization.
Filter documents before passages reach the model. Microsoft's document-level access guidance describes retrieval patterns based on the current user's permissions or groups. Post-generation redaction is too late because restricted text may already have shaped the answer.
Use separate collections only when they simplify administration. Separation does not replace authorization checks. Every retrieval request should carry the current identity context, and the search layer should return only sources that identity may inspect.
Run negative tests with the same care as successful searches. Ask for another team's compensation discussion, a former manager's private notes, and a record outside the manager's location. The system should reveal neither the passage nor a summary that confirms sensitive details. Then test required management policies and team sources to prove that legitimate filtering is not overly restrictive.
Turn the 30-60-90 plan into verified work
A calendar full of reading does not establish management readiness. Organize the plan around decisions and operating capability. The company brain should deliver information when the manager needs to use it, while keeping mandatory changes visible.
First 30 days: establish context and boundaries
The manager should learn the team's purpose, current commitments, decision rights, recurring operating rhythm, and named support routes. Assign company and management policies that require acknowledgment. Give the manager access to current team sources, then test that restricted material remains unavailable.
Schedule structured conversations with the hiring leader, direct reports, key partners, and process owners. The company brain can prepare source-linked questions, but it should not replace those conversations or summarize private employee views as established fact.
End this stage with a context review. Ask the manager to explain where they would find the governing source for a common people decision, an operational exception, and a customer commitment. Correct the source path, not just the final answer.
Days 31 to 60: make bounded decisions
Move from reading to realistic work. Give the manager scenarios that match their authority: approving routine work, routing an exception, finding the current team commitment, or escalating an unclear policy. Each scenario should require a source and identify whether the manager can decide, recommend, or only collect evidence.
The company brain should explain why a source applies. A good response includes the source owner, effective state, audience scope, and next action. If two current sources conflict, the assistant should stop and route the case to the named owner rather than choosing whichever passage ranks first.
Review failed scenarios for a specific cause. The manager may lack knowledge, the access rule may be wrong, the source may be stale, or the decision map may be incomplete. Those causes need different fixes.
Days 61 to 90: operate and improve the system
By this point, the manager should handle routine work within the documented boundary and recognize exceptions. Have them run one recurring team process, verify its source trail, and propose a correction for one genuine knowledge gap.
Do not reward the creation of extra pages. A useful improvement might merge duplicate instructions, assign an owner, retire an old procedure, or clarify a decision threshold. The goal is a more reliable operating path, not a larger wiki.
Complete the stage with the hiring leader's review of decision quality, access, unresolved gaps, and handoffs. Keep outstanding exceptions visible after day 90 instead of marking the plan complete because the date arrived.
Define an answer contract for new managers
The assistant needs a consistent response shape for management questions. For a material instruction, require:
- the current answer in plain language;
- the canonical source and relevant section;
- the source owner and review state;
- why the rule applies to this manager and team;
- whether the manager may decide or needs approval;
- the next action or named handoff.
Withhold a definitive answer when the source is unverified, the employee lacks permission to inspect the evidence, current sources conflict, or the action exceeds recorded authority. A refusal should still be useful. It should state what evidence is missing and route the manager to the correct owner.
The Kipwise employee onboarding workflow distinguishes assigned onboarding material from searchable company knowledge. Preserve that distinction. Assign policies, changed operating rules, and decision boundaries that the manager must understand. Keep stable reference material searchable so the plan does not become a reading dump.
Fix the failures that show up most often
Copying the previous manager's access is quick, but it can preserve temporary projects, private records, or permissions from another role. Provision access from current attributes. Send exceptions through explicit approval.
Team chat creates a different problem. It contains useful questions and vocabulary, but an isolated message should not govern a people or customer decision. The company brain must link the answer to an owned source or route the question for confirmation.
A polished summary can also conceal weak evidence. Before acting, the manager needs to inspect the source, its scope, and any approval rule. Brevity is not a substitute for that evidence.
Avoid loading all available material into the first month. Assign what the manager needs for current decisions, keep background material searchable, and introduce later sources when the work requires them.
Do not hide uncertainty. When a policy and team procedure disagree, record the conflict and identify the accountable owner. The assistant should withhold a consequential instruction until that owner resolves it.
Page views are a poor completion test. A ready manager can retrieve the right source, stay within permission boundaries, make a bounded decision, and escalate an exception.
Verify the workflow before launch
Create a synthetic manager identity with the target role, team, location, and approved groups. Seed the test with a current management policy, an old team procedure, one restricted record, a decision requiring approval, a routine decision within scope, and two conflicting sources.
Run these checks:
- Current team and management sources are retrievable with accurate citations.
- The old procedure is retired or points to its replacement.
- Restricted material does not appear in passages, answers, or summaries.
- A routine decision returns the correct source and authority.
- A threshold decision requires the documented approval.
- Conflicting sources trigger a handoff to the named owner.
- A realistic scenario records the source used and resulting action.
- Removing a group immediately changes what the manager can retrieve.
Repeat the suite when identity rules, source ownership, retrieval filters, or decision thresholds change. Content checks cannot compensate for a failed permission test, and a secure search result cannot compensate for an obsolete policy.
Start with one management path
Choose one newly hired manager role with clear recurring decisions. Build its context pack, map five decision rights, and configure the current access rules. Turn those items into a 30-60-90 plan with source-linked scenarios. Ask the hiring leader and each source owner to review the mandatory material, excluded sources, and handoff rules.
Then test both valid and forbidden retrieval with a synthetic identity. Release the workflow only after the manager can find current evidence, act within recorded authority, and route exceptions without guessing. That gives the new manager something more useful than another checklist: a safe operating map for the team they are expected to lead.
References
- GitLab onboarding handbook supports explicit onboarding tasks, role details, access requests, buddies, and named support paths.
- Microsoft document-level access control supports filtering searchable evidence using current user or group access.
- NIST SP 800-207 supports access decisions based on current identity, resource, and policy context rather than implicit trust.
- NIST AI Risk Management Framework supports governed context mapping, measurement, and management of AI risks.
- Kipwise employee onboarding supports the product context of assigned reading, searchable company knowledge, and onboarding progress.
