Which document to trust

Engineering information collects in many places. Use this rule: the document that has a named owner and a recent review date is authoritative. Personal notes, chat threads and old slide decks are useful context but are not the answer.

When documents disagree or fall short

Two documents disagree

Trust the one with the more recent review date and tell its owner about the conflict.

A document has no owner

Ask your team lead before relying on it.

Your change makes a document wrong

Update it in the same change.

Documentation by type

Sample entries for fictional Northstar. Each type has one approved home that your team lead can point you to.

Standards

Coding and review standards

How we name, structure and review work. Owner: Engineering Enablement (sample).
Architecture

System architecture overview

How our main systems connect, and which team owns each one.
Runbooks

Release and rollback runbook

The steps for releasing a change and undoing it when something goes wrong.
Runbooks

On-call handbook

What to do when an alert fires, and who to call next.
Onboarding

First-change walkthrough

The step-by-step path for your first reviewed change.
Open walkthrough
Onboarding

Team rituals guide

What each recurring meeting is for and when it happens.
Open guide

Something wrong or missing?

Who do I tell about an error?

Every document has an owner who fixes errors. Tell the owner named on the document, or your team lead if none is named.

Will my correction change what new hires read here?

Engineering Enablement (sample owner) reviews this site whenever team practices change, so your correction may also change what new hires read here.