New hire roles and responsibilities often look clear in a job description and collapse during the first real decision. The employee knows they "own operations" but cannot tell whether that includes changing a workflow, approving an exception, or only preparing a recommendation. An AI company brain can repeat the vague wording faster without resolving it. A useful role charter connects each expected outcome to a decision boundary, governing source, required collaborator, escalation route, effective date, and practical test. This guide gives People Operations and hiring managers a concrete workflow for building that charter, serving it through the company brain, and verifying that a new employee can act without guessing.
Why job descriptions fail after hiring
A job description supports recruiting. It describes scope, qualifications, and broad duties well enough for candidates and interviewers to evaluate fit. Work starts at a different level of detail. A new hire needs to know what result they own, which decisions are theirs, which decisions require approval, where the current procedure lives, and who can resolve a conflict.
Role design also includes relationships and autonomy, not only a task list. The CIPD job design factsheet describes job design through responsibilities, work organization, relationships, and the needs of both the organization and employee. That wider frame explains why copying recruiting text into onboarding leaves gaps.
The gaps create predictable failure modes:
* Two people assume the other owns the same outcome. * A new employee waits for approval they already have authority to give. * The employee acts alone where a legal, security, finance, or customer owner must approve. * A manager explains one expectation in a meeting while the company brain retrieves an older document. * A reorganization changes the manager or team boundary without changing the role material. * Progress gets judged against expectations the employee never saw or confirmed.
The company brain should expose the approved operating agreement and its evidence. It should never infer decision authority from a job title, an org chart, or similar documents.
Define the role charter record
Treat the charter as structured knowledge with a readable page, not a paragraph hidden in an offer letter. Each responsibility needs enough data to answer a work question safely.
A minimal record can use this shape:
charter_id: customer-operations-manager-v3
employee_id: worker-1842
role_family: customer_operations
version: 3
effective_from: 2026-09-03
review_due_at: 2026-10-03
manager_id: worker-0911
outcomes:
- outcome_id: renewal-risk-review
expected_result: Renewal risks have an owner and next action before forecast review.
evidence_source: /knowledge/renewal-risk-process
decision_right: recommend
approval_owner: revenue-director
consulted_teams:
- customer_success
- finance
escalation_route: revenue-operations-help
verification_task: Route one synthetic renewal-risk case.
status: confirmed
confirmed_by:
- worker-1842
- worker-0911Keep the fields operational:
* expected_result states an observable outcome instead of a loose activity such as "support renewals." * evidence_source points to the maintained process, policy, service catalog, or standard that governs the work. * decision_right uses a small controlled vocabulary such as decide, recommend, execute, review, or observe. * approval_owner identifies accountable authority when the employee cannot decide alone. * consulted_teams records required inputs without turning every colleague into an approver. * escalation_route remains valid when one person is absent. * verification_task proves that the employee can apply the boundary to a realistic case. * version and dates make changes visible instead of silently rewriting prior expectations.
Resolve the current manager from an authoritative directory when possible. Microsoft's List manager API documentation shows how a directory can supply the current manager relationship. Use that relationship as one input. A manager link does not establish every approval or process owner in the charter.
Build the charter before the employee starts
1. Collect the sources that make the role real
Start with the approved job description, current team goals, process pages, service ownership records, policy documents, and delegation rules. Include the manager and one or two people whose work depends on the role. Ask each person which outcomes they expect and which decisions routinely cross team boundaries.
Use onboarding tasks to locate the material a new hire will actually encounter. The GitLab onboarding handbook provides a practitioner example built around explicit tasks, managers, buddies, owners, access requests, and support routes. Each instruction in that handbook sits in an owned process.
Reject unsupported expectations. If the manager cannot point to an approved source or accountable owner, record an unresolved item. Do not let the company brain turn a repeated chat opinion into policy.
2. Convert activities into outcomes
"Attend customer meetings" describes activity. "Customer risks are recorded with an owner and due date within one business day" describes an outcome. The second statement gives the new hire a result they can inspect and discuss.
For each broad duty, ask four questions:
- What observable state should exist when the work is done?
- Which source defines acceptable work?
- Who is affected by the decision?
- What evidence shows that the outcome happened?
Keep the first charter small. Five to eight meaningful outcomes are easier to confirm and test than thirty copied bullet points. Link supporting procedures rather than pasting them into the charter, so a process update does not leave duplicate instructions behind.
3. Assign one decision boundary per outcome
Use a controlled set of decision rights across the company. A practical set is:
* Decide: the employee can make and record the decision within the stated scope. * Recommend: the employee prepares the choice and evidence; the approval owner decides. * Execute: the decision is already authorized, and the employee performs the defined steps. * Review: the employee checks quality or compliance but does not own the final choice. * Observe: the employee needs context but has no action or approval role.
Avoid free text such as "owns with support." It forces each new hire to interpret the boundary again. Add conditions where authority changes by amount, customer tier, region, data sensitivity, or risk level.
Atlassian's roles and responsibilities play recommends identifying responsibilities, assigning owners, and discussing unassigned or overlapping work as a team. Use that discussion to resolve collisions before the charter reaches the employee.
4. Attach sources and escalation routes
Every consequential boundary needs a source that the new hire can open. Store the source identifier, owner, current version or review date, and permission rule with the charter record. The company brain should cite that source beside its answer.
Give each outcome a team route as well as named people. A queue, help channel, or service desk route survives leave and personnel changes better than a person's name alone. If the source and a manager instruction disagree, show the conflict and route it to the source owner. Do not choose whichever text ranks highest in search.
5. Limit what the company brain can retrieve
A role charter can contain sensitive context about customers, internal investigations, compensation authority, or team changes. The NIST Privacy Framework provides a governance structure for identifying and controlling privacy risk. Apply that principle through a field allowlist and retrieval permissions.
The new employee should see their own confirmed charter and the sources required for their work. Peers may need the role's public outcomes and contact route without seeing private employee notes. People Operations may need confirmation history without receiving restricted operational content. Never index interview notes, manager impressions, accommodation details, or performance commentary into the charter.
Filter eligible records before semantic search. A model prompt that says "do not reveal private fields" is weaker than excluding those fields from retrieval.
6. Confirm the charter with the new hire
Schedule a working session during the first week. The manager presents each outcome and asks the employee to explain the decision boundary in their own words. The employee should be able to flag unclear wording, missing sources, inaccessible pages, and conflicting expectations.
Confirmation means both people reviewed a specific version. It is not a blanket acknowledgment that every expectation is fair or permanent. Record unresolved items separately, assign owners and due dates, and keep the affected boundary in a restricted state until the question is settled.
Kipwise's employee onboarding page describes assigning onboarding material, making company knowledge searchable, and tracking progress. Place the charter inside that flow, linked to the tasks and sources where the employee will use it.
Serve role answers with explicit rules
A company brain can answer charter questions only after deterministic eligibility checks. The resolver should select the employee's active charter, filter its outcomes by permissions and effective date, and return the approved boundary with its source.
def answer_role_question(employee, question, now):
charter = charters.active_for(employee.id, now)
if not charter or charter.status != "confirmed":
return escalate("No confirmed role charter")
outcomes = enforce_permissions(employee, charter.outcomes)
matches = semantic_rank(question, outcomes)
if len(matches) != 1 or matches[0].confidence < ACCEPT_THRESHOLD:
return escalate("Role boundary is ambiguous")
outcome = matches[0]
source = knowledge.open_current(outcome.evidence_source, employee)
if not source:
return escalate("Governing source is unavailable")
return explain_boundary(
expected_result=outcome.expected_result,
decision_right=outcome.decision_right,
approval_owner=outcome.approval_owner,
consulted_teams=outcome.consulted_teams,
source=source,
effective_from=charter.effective_from,
escalation_route=outcome.escalation_route,
)A useful response says what the employee owns, what authority applies, who else participates, which source governs, when the charter took effect, and where to escalate. If any required fact is missing, the answer should identify the missing field and open a repair task.
For example: "You own preparation of the renewal risk recommendation. The Revenue Director approves the final response for strategic accounts. Consult Customer Success and Finance, then record the decision in the renewal process. This boundary comes from role charter version 3 and the current renewal risk procedure. Use Revenue Operations Help if the customer tier or approver is unclear."
Handle role charter failures
Design exception behavior before launch:
* No confirmed charter: show the employee the manager and People Operations route. Do not synthesize responsibilities from the job title. * Two active versions: block a definitive answer and ask the charter owner to close the version conflict. * Missing source access: report the inaccessible source and route an access request or source repair. Do not paraphrase hidden content. * Manager changed: refresh the directory relationship and require review of open approval fields. * Owner is absent: use the maintained team route or delegate instead of guessing from the org chart. * Expectation changed: create a new effective version, explain the change to the employee, and preserve the previous confirmation record. * Employee disputes the boundary: record the question and accountable reviewer. Keep private discussion outside the searchable charter. * Source became stale: mark affected outcomes for review and avoid consequential instructions until the owner confirms them.
These paths keep role clarity separate from performance surveillance. The charter records approved expectations and work routes. It should not score how often the employee asks questions or treat clarification as evidence of poor performance.
Verify the charter with real work scenarios
Verification must prove that a new hire can connect an outcome to authority, evidence, collaborators, and escalation. A signed page does not prove that connection.
Build one low risk scenario for each high consequence outcome. Use synthetic data and actions that cannot affect a customer, payment, production system, or employee record. Ask the new hire to use the company brain and explain:
- the expected result;
- their decision right;
- the required approver or consulted team;
- the governing source;
- the escalation path if one fact changes.
Test negative cases as well. Remove source access, activate a second charter version, mark an owner absent, and ask a question that crosses two outcomes. The system should escalate each condition without inventing authority.
Use this launch checklist:
* one active, confirmed charter exists for the employee; * every outcome states an observable result; * every decision right uses the controlled vocabulary; * every consequential instruction has an accessible current source; * manager and approval identities resolve to active directory records; * team escalation routes exist for named owners; * permission filters run before retrieval; * unresolved items stay visible with owners and due dates; * positive and negative scenario tests pass; * confirmation history records versions without performance commentary.
Review the charter after the first month, after a manager or role change, and when an attached source changes materially. The review should update the work agreement, not merely extend its date.
Start with one disputed responsibility
Choose the responsibility that currently causes the most handoffs or conflicting instructions. Rewrite it as an observable outcome, assign one decision right, attach the governing source, name the approver and team route, and create one synthetic scenario. Have the manager and new hire test the answer together. Expand the charter only after the company brain can return that boundary with evidence, protect restricted context, and escalate a missing or conflicting field without guessing.
References
* CIPD job design factsheet supports the treatment of responsibilities, work organization, relationships, and autonomy as parts of role design. * Atlassian roles and responsibilities play supports the team process for surfacing unassigned and overlapping responsibilities and assigning owners. * Microsoft Graph List manager API supports resolving the employee's current manager relationship from an authoritative directory. * NIST Privacy Framework supports privacy governance and data minimization around employee and team context. * GitLab onboarding handbook provides a practitioner example of explicit onboarding tasks, owners, managers, and support routes. * Kipwise employee onboarding provides product context for assigned onboarding knowledge, searchable company information, and progress tracking.
