First Nations Management & Leadership · Arcus perspective
Policies vs. Procedures: What First Nation Governments Actually Need
Start with the decision, not the document
A recurring service problem often produces a request for a new policy. Yet the missing piece may be an application checklist, a clear approval route or time to complete work already required. Writing another policy can leave the actual cause untouched while adding a further document for employees to interpret.
Arcus’s central proposition is that a useful policy system separates decisions about acceptable outcomes and boundaries from the practical instructions needed to deliver them. The distinction is functional: a document’s title does not establish its authority, and a detailed procedure should not quietly create a new entitlement or restrict an existing one.
The goal is a coherent set of instructions people can use. This article considers how to choose, connect and maintain those instructions. The Nation’s own laws, institutions and valid delegations determine who can approve them; a generic policy template cannot settle that question.
Two primary examples clarify the distinction
Tsawwassen First Nation’s policy overview describes policies as decision-guiding principles and distinguishes administrative, governance and member-benefit purposes. Its categories demonstrate that policies do different work: some organize government activity, while others frame public decisions or access to benefits. This is a Nation-specific description, not a universal classification.1
The FNESC/FNSA school-governance handbook distinguishes governing-authority policy boundaries from school-level procedures typically developed by the principal. That sector-specific example illustrates how implementation can be assigned while remaining consistent with higher-level direction.2
Neither source establishes that a larger manual improves services. Arcus’s inference is that the quality of the connection between authority, rule and daily work matters more than the number of documents approved. A small government may need concise instruments; a complex program may require more detailed controls.
Classify the problem before commissioning new writing
A policy question concerns a consequential choice: the purpose of a service, criteria for access, acceptable risk, required controls or the limits of discretion. A procedure question concerns execution: what happens first, who checks the information, how a decision moves forward and what record must be kept.
A job aid makes an existing requirement easier to perform. A checklist, process map or plain-language applicant guide can be valuable without introducing a new rule. A management action may be enough where the instructions are already clear but a queue lacks an owner or an employee needs training.
Consider a hypothetical grant program with inconsistent application decisions. If eligibility is unclear, a policy decision may be needed. If eligibility is clear but different staff request different documents, a common procedure and applicant checklist may be the better response. If only one reviewer is overloaded, revising the manual will not create capacity.
Find the authority and the existing rule
Before drafting, identify the governing instruments and the people or bodies authorized to act. Check related policies, funding commitments, service arrangements and applicable requirements. Where interpretation is consequential or uncertain, obtain appropriate advice. Do not assume that Council approves every operating detail or that management can change every document labelled a procedure.
Record the relationship between instruments in language users can understand. A procedure should identify the policy it implements and the role that maintains it. A policy should make its approval authority, scope and intended effect visible. Where two instruments conflict, resolve the conflict through the proper authority rather than leaving employees to choose.
This work can reveal that the organization already has the required rule but cannot locate the authoritative version. In that case, retrieval, communication and version control deserve attention before another drafting project. Preserve the history needed to understand earlier decisions while clearly identifying what applies now.
Keep policy stable enough to guide judgment
A policy should explain its purpose and the decisions it governs. Define the important boundaries and the discretion that remains. If exceptions are permitted, specify who may authorize them, what considerations apply and how they are recorded. An exception route should not become an informal parallel program available only to people who know whom to contact.
Avoid embedding every software screen, employee name or routine sequence in a policy unless there is a specific reason. Such details may change more often than the underlying rule. If changing a form requires reopening the entire policy, the approval process can become a source of avoidable delay.
Conversely, excessive generality can leave staff without enough direction. A statement that decisions must be fair does not explain how competing eligible requests will be prioritized when resources are limited. Material choices should be made openly by the authorized body rather than concealed inside an administrative checklist.
Design procedures around real work and handovers
Map the work from the user’s first request to a completed decision or service. Identify required inputs, responsible roles, approvals, records and communication. Pay particular attention to transfers between departments, where work can disappear into an assumed responsibility.
Use the level of detail the task requires. A familiar, low-risk activity may need a short checklist. An infrequent task with serious consequences may require more explicit steps and specialist review. The same format need not be imposed on every function merely to make the manual look consistent.
Walk through ordinary and difficult cases with the employees who do the work. Test missing information, an absent approver, a time-sensitive request and an exception. If a procedure cannot explain what happens when a normal condition fails, staff will create their own workaround. Capture a legitimate escalation route before that becomes routine.
Choose among repair, consolidation and replacement
A targeted repair is appropriate when the underlying rule remains sound and the failure is specific. It can reduce disruption and preserve familiar practice. Its limitation is that repeated patches may leave the overall system inconsistent.
Consolidation is useful where overlapping instruments create competing requirements or duplicate approvals. It requires careful mapping so that a meaningful protection is not removed as apparent duplication. Explain which document takes over each function and obtain the approvals required for any substantive change.
A full redesign may be justified by a changed mandate, a new service or widespread contradictions. It also requires more staff time, consultation, training and transition planning. Compare those costs with the risk of continuing the present arrangement. The size of the document project should follow the decision problem, not the availability of a template library.
Count the cost of compliance and maintenance
Every required approval, record and review consumes capacity. Estimate the recurring work created by a proposed rule, including the time applicants spend supplying information. A control that appears inexpensive in a policy meeting may create a large burden across many service transactions.
Consider whether the same protection can be achieved through a clearer decision boundary, a better-designed form or a proportionate review of cases. Do not remove necessary controls simply to reduce steps. Make the trade-off explicit: what risk is being addressed, how much protection is needed and who will carry the work?
Budget beyond drafting. Translation or accessible presentation, staff orientation, system changes, supervisor support and scheduled maintenance may all be needed. Assign an accountable owner for these tasks. A policy that requires an unavailable system or unfunded role is not ready for dependable implementation.
Introduce changes without creating two competing systems
Set an effective date and decide how work already in progress will be handled through the proper authority. Identify the documents and forms being replaced, update public instructions where relevant and communicate the change to affected people. Staff should not have to infer whether an old application is governed by a new rule.
Provide short, role-specific guidance. Front-line employees need to know what changes in their work; supervisors need to know which decisions and exceptions they oversee; members need clear information about the service and how to seek clarification or review. Sending the complete manual to everyone is rarely enough.
Use a limited, authorized trial of the operating procedure where appropriate, without informally changing rights or requirements. Record problems and fix them before wider implementation. A test should establish usability, not create an unapproved experiment with service eligibility.
Judge the system by consistent decisions and usable service
Review a proportionate sample of cases after implementation. Look for contradictory instructions, avoidable returns, unexplained exceptions and differences in how comparable requests are handled. Also ask whether employees can find the current rule and explain the reason for a decision.
If delays persist, consider workload, approval availability, information quality and system limitations as well as the written instructions. A policy can be clear while its implementation remains under-resourced. Equally, additional staff will not resolve a rule that gives two people conflicting authority.
Use review findings to maintain the instruments through their proper approval routes. Completion of the manual is an output. The intended result is a service in which expectations are understandable, decisions are consistent with valid authority and employees can carry out the work.
The Arcus rule-to-work framework
This original Arcus decision framework is a management aid for local adaptation. It is not a validated assessment instrument or a substitute for the Nation’s authority and relevant professional requirements.
Purpose
Question: What problem requires a common decision?
Decision evidence: A defined outcome or risk, rather than a general request for another document.
Authority
Question: Who may establish or change the requirement?
Decision evidence: A verified approval route and alignment with governing instruments.
Instrument
Question: What level of instruction is needed?
Decision evidence: Policy boundaries, operating procedure, job aid or a management action.
Usability
Question: Can people carry it out in real conditions?
Decision evidence: Tested handovers, exception routes, tools, capacity and clear communication.
Maintenance
Question: How will the instruction remain reliable?
Decision evidence: An owner, authoritative version, review triggers and evidence from actual cases.
Turn the design into an operating commitment
Select one recurring service problem and gather its current rules, forms and case examples. Identify whether the principal gap concerns the policy choice, the operating sequence or the capacity to perform it.
Confirm authority, prepare the smallest coherent change and walk through ordinary and difficult cases with the people affected. Cost the implementation and obtain the approvals required before changing practice.
Introduce the change with clear ownership, an effective date and usable instructions. Review early cases for consistency and burden, then correct the instrument or operating arrangement that the evidence shows is failing.
Sources and limits of the evidence
- Tsawwassen First Nation, Policies overview. Primary description of TFN policy purposes and categories; used illustratively, without assuming another Nation has the same authority structure.
- FNESC and FNSA, A Handbook for First Nation School Governing Authorities, June 2024, p. 77. Sector-specific policy/procedure distinction. No handbook templates or instruments reproduced.
Research reviewed October 18, 2026. Decision frameworks, options and hypothetical illustrations are Arcus management synthesis. No client outcomes or universal savings or impact benchmarks are claimed.
Governance & Leadership collection · Clarifying delegated authorities · Organization design services · Arcus consultant directory