How to Onboard New Managers with an AI Company Brain

Onboard a new manager with a second layer on top of the employee checklist, built around decisions and not documents, because a checklist cannot carry what a manager inherits: commitments, approval limits and records they may or may not read. We recommend two choices most programs skip. Label every answer as a company rule, a management policy or a team custom, and say who may change it. And grant access from the manager's current attributes and a recorded acknowledgment, never from the predecessor's group memberships. The rest is a small set of governed sources, a decision-rights map and a 30-60-90 plan whose steps are scenarios the manager completes, with a company brain that refuses what exceeds the manager's authority.

The second layer

A new manager is also a new employee, so payroll access, security training, equipment and a support route still apply. What the employee checklist cannot hold is the inheritance: the team's goals and service commitments, the budget boundary, who approves a staffing exception, why the release process changed and which people records the manager may read. GitLab's onboarding handbook treats this as a separate artifact, a "Becoming a GitLab manager" issue template, listed among its supplemental onboarding issue templates and separate from the one for all team members. Do the same. A generic assistant that retrieves every page mentioning "manager" mixes company guidance, team habits, old plans and restricted records into an answer that sounds coherent and leaves the manager unable to tell which instruction governs.

Build a bounded context pack of five source groups: company-wide policies that apply to every employee, management policies for hiring, leave, expenses, performance processes, access requests and escalation, team sources for goals, cadence, service levels and active commitments, decision records that explain why a routine or constraint exists, and a directory of accountable owners for questions the assistant must not settle itself. Each source carries a canonical identifier, an owner, an effective date or review state, an audience, a confidentiality class and a replacement when retired. A page without an owner or a reliable review state can stay discoverable as background but must not support a consequential instruction. Do not import private notes because the manager may need them one day. Add restricted sources through an approved entitlement, never through a broader index or a special prompt.

Label what binds and what can change

Every answer to a manager should say which of three things it is: a company rule that binds everyone, a management policy that binds managers with a named owner, or a team custom that the manager may keep or change. We recommend one field on each source, binding_level, and a one-line "who can change this" beside the answer. A new manager's two costliest early mistakes are altering a company rule that looked like a team habit and obeying a habit they could have changed. The second is quieter: a team inherits routines nobody remembers choosing, and the new manager has both the standing and the outside view to retire them. Surface the customs in the first month as questions to ask the team, and leave any change to day 31 or later.

Map decision rights

A manager cannot use context well if the system never says what they may decide. Create a map that names the action, the accountable owner, the required evidence, the approval threshold and the escalation route:

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_notification

The company brain uses the map to separate guidance from authority. It explains the policy and collects the evidence for a request, and it never claims an approval exists until the authoritative workflow records it. NIST's voluntary AI Risk Management Framework has a companion Playbook of suggested actions, which NIST says is neither a checklist nor a set of steps to follow in its entirety. Take the same selective approach here and spend it on the individuals at risk, the manager's direct reports, whose records the assistant could expose or summarize: name an owner, state the use boundary and define what happens when the evidence is missing.

Provision from current attributes

The title "manager" does not authorize anyone to read every management document. A sales manager should not retrieve another department's performance records, and a new team lead should not inherit the former manager's access by default. NIST's zero trust architecture publication, SP 800-207, says no implicit trust should be granted to an account solely because of where it sits or who owns the asset, and that authentication and authorization are discrete functions performed before a session to a resource is established. A title is the same kind of implicit trust. Build the manager's knowledge access from the authoritative employee record, approved role rules, team membership, location and time-bounded assignments, and treat previous titles and copied group memberships as nothing.

We also recommend turning on access to individual performance and compensation records only after the manager has completed the people-data training and acknowledged the policy, with the date recorded. Until then the manager sees team-level material. Keep that gap to days, because a manager who needs a leave approval on day two cannot wait for a course, and make the training the first scheduled task so the gate stays short.

Filter documents before passages reach the model, since text redacted after generation may already have shaped the answer. In Azure AI Search the caller's token travels with each query in the x-ms-query-source-authorization header, so the check follows the identity on every request. Run negative tests as carefully as successful ones: ask for another team's compensation discussion, a former manager's private notes and a record outside the manager's location. The system must reveal neither the passage nor a summary that confirms sensitive details. Then test the required management policies and team sources, to prove the filter is not too strict.

The 30-60-90 plan as verified work

First 30 days

Learn the team's purpose, commitments, decision rights, operating rhythm and support routes, and acknowledge the policies that require it. Hold structured conversations with the hiring leader, direct reports, key partners and process owners. The assistant prepares source-linked questions and does not summarize anyone's private views as fact. Close with a context review: where would the manager find the governing source for a people decision, an operational exception and a customer commitment? Correct the source path as well as the final answer.

Days 31 to 60

Give scenarios that match the manager's authority: approving routine work, routing an exception, finding the current team commitment, escalating an unclear policy. Each requires a source and states whether the manager decides, recommends or only collects evidence. When two current sources conflict, the assistant stops and routes to the owner. Review each failed scenario for its cause, which may be missing knowledge, a wrong access rule, a stale source or an incomplete decision map, because each needs a different fix.

Days 61 to 90

The manager runs one recurring team process, verifies its source trail and proposes a correction for one real knowledge gap, such as merging duplicate instructions, assigning an owner, retiring an old procedure or clarifying a threshold. A larger wiki is not the goal. The hiring leader then reviews decision quality, access and open gaps, and unresolved exceptions stay visible after day 90 instead of closing the plan because the date arrived.

The answer contract

For a material instruction, the assistant gives the answer in plain language, the canonical source and section, the owner and review state, the binding level, why the rule applies to this manager and team, whether the manager may decide or needs approval, and the next action or named handoff. It withholds a definitive answer when the source is unverified, the manager cannot inspect the evidence, current sources conflict or the action exceeds recorded authority, and a refusal says what evidence is missing and who owns it. The Kipwise employee onboarding workflow distinguishes assigned onboarding material from searchable company knowledge. Preserve that distinction: assign the policies, changed operating rules and decision boundaries the manager must understand, and keep stable reference material searchable so the plan does not become a reading dump.

Shortcuts that backfire

• Copying the previous manager's access is quick and preserves temporary projects, private records and permissions from another role. Provision from current attributes and send exceptions through explicit approval.
• A single chat message should not govern a people or customer decision. The assistant links to an owned source or routes the question for confirmation.
• A polished summary can hide weak evidence, so the manager inspects the source, its scope and any approval rule before acting.
• Page views do not show readiness. A ready manager retrieves the right source, stays inside permission boundaries, makes a bounded decision and escalates an exception.

Before launch, create a synthetic manager with the target role, team, location and approved groups, and seed it with a current policy, an old team procedure, a restricted record, a decision that needs approval, a routine decision within scope and two conflicting sources. Current sources must come back with correct citations, the old procedure must be retired or point to its replacement, the restricted record must stay out of passages, answers and summaries, the threshold decision must require its documented approval, and the conflicting sources must go to the named owner. Then remove a group and confirm that the manager's results change. Run the suite again whenever identity rules, source ownership, retrieval filters or thresholds change.