Free Engineering Team Charter Template

A team charter is the one-page document that defines a team's reason for existing. Not its OKRs, not its roadmap, not its values poster. Its scope, its ownership, its constraints, and the boundaries with adjacent teams. The charter is what a new hire reads to understand "what does this team do?" and what a leader reads to settle a scope dispute. Teams without one negotiate every cross-team interaction from scratch and discover during reorgs that they don't actually agree on what they own.

The template below is what useful team charters look like. It is one page on purpose. A longer charter becomes the long form of the team's marketing copy and stops being a load-bearing document. The constraint forces the writer to leave out the aspirations and keep the operationally meaningful claims.

When to use it

• Forming a new team — write the charter before you hire the third engineer.
• A team has reorganized and the scope is now unclear.
• You keep having scope arguments at the boundary with another team.
• A new manager is taking over a team and wants to inherit the scope explicitly.

The template structure

This is the structure of the template. Copy it into a Notion page, a Linear doc, or a markdown file in your repo — it works in any of them.

TEAM CHARTER — [team name]
Last reviewed: [date]   Next review: [date]
Manager:       [name]
Tech lead:     [name]

MISSION
  One sentence. What this team exists to do. Example:
    "Own the billing platform: subscription state, invoicing, and the
    third-party billing integrations."

WHAT WE OWN
  - [system / area]
  - [system / area]
  - [process / responsibility]

WHAT WE DO NOT OWN
  Explicit. Things adjacent teams or stakeholders sometimes assume
  we own and we do not.
    - [thing] — owned by [team]
    - [thing] — owned by [team]
    - [thing] — currently unowned (see ownership matrix)

KEY INTERFACES
  How other teams interact with what we own:
    - [interface]: API contract, version, ownership
    - [interface]: event schema, version
    - [interface]: SLA we provide

DEPENDENCIES
  Teams we depend on:
    - [team]: for [thing]
  Teams that depend on us:
    - [team]: for [thing]

OPERATING PRINCIPLES
  How we work, encoded as defaults:
    - Default to async; sync meetings have agendas.
    - Decisions get records (see decision authority map).
    - On-call rotation: [link].
    - Review SLA: [link].

DISCRETIONARY SCOPE
  Things we will pick up if it's the right move, even though we do
  not strictly own them:
    - [example]
    - [example]

OUT OF SCOPE
  We will not pick these up; we will route them:
    - [example] — route to [team]
    - [example] — route to [team]

SUCCESS LOOKS LIKE
  Operationally, not aspirationally. Example:
    - Billing service availability above 99.95% per quarter.
    - Time-to-first-PR for new hires under 5 business days.
    - Cross-team dependency commitments met or re-declared within
      72 hours of slipping.

REVIEW
  This charter is reviewed every six months. Disputes about scope
  go to [name] for resolution within one week.

How to use it well

• The "what we do not own" section is the most useful. Most scope disputes are about what a team is assumed to own and doesn't. Naming those things explicitly resolves a recurring class of cross-team friction.
• Discretionary vs. out-of-scope is a real distinction. Some work is not your responsibility but you will do it because it's the right call. Other work you will not do. Saying both lets adjacent teams plan around you.
• Success criteria are operational, not aspirational. "Delight customers" is not a success criterion. "P99 latency under 200ms" is. The charter is for measurable claims.
• Resolve disputes in one week. A charter with no escalation path produces standoff. Naming the resolver and the timeline turns scope disagreements into one-week problems instead of two-quarter ones.
• Review every six months. Same cadence as the operating manual. The charter should be a slow-moving document, but it does move — reorgs, new platforms, deprecated services.

What to skip

Skip values statements and team slogans. The charter is operational. Values belong in the operating manual at most; many teams skip them entirely and lose nothing.

Skip listing every project the team is working on. Projects come and go; the charter is about the standing scope. A charter that mentions specific projects ages out within a quarter.

Frequently asked questions

Is this template free?

Yes. The structure above is the template. Most teams keep the charter as a Notion page pinned in their team channel.

Can I edit it?

Yes. Smaller teams often drop the Interfaces section if their boundary is unambiguous; larger teams add a section for delegated decision authority.

Do I need to give my email?

Not for the template. The download is a polished Notion version; the email is for our newsletter only.