---
name: ways-of-working
description: Use when asked to write or improve a team's ways of working — ground rules, working agreements, meeting/communication/feedback norms, remote/async practices, or onboarding/orientation docs — or to distinguish "principles" from "values", "tenets", "norms", and "working agreements" when a team is documenting how it operates.
---

# Ways Of Working

"Ways Of Working" (WOW) describes how people work, especially together in
teams — the explicit and implicit rules, norms, and agreements a team uses
day to day. This skill is grounded in the curated collection at
[joelparkerhenderson/ways-of-working](https://github.com/joelparkerhenderson/ways-of-working),
which aggregates 100+ pieces of teamwork advice and named frameworks under
one glossary.

## The vocabulary, precisely

These terms get used loosely in practice; the repo's glossary draws real
distinctions worth keeping when writing a team's own docs:

| Term | What it is | Example |
| --- | --- | --- |
| **Principles** | Fundamental, intended-universal-and-permanent truths behind beliefs/behavior | "Be kind", "Tell the truth" |
| **Values** | Virtues a team wants; can be subjective, comparative, or time-bound | "Responding to change over following a plan" |
| **Whys** | Explanations for why something matters, giving context | "Why do we value X?" |
| **Tenets** | Desirable attributes built into every plan, used to judge if a plan will succeed | "Involve users early and often" |
| **Ground rules** | Behavior guidelines for a specific situation (a meeting, a task) | "Everyone gets a chance to speak" |
| **Aspirations** | Statements guiding interaction/decision-making across groups | "Every challenge is an opportunity to learn" |
| **Norms** | Informal, implicit standards that emerge from observed behavior, not written down first | "The team is observably always punctual" |
| **Working agreements** | Protocols the group *develops together* and commits to uphold together | "Code is complete when all tests pass" |

The repo explicitly recommends retiring the word "culture" for this kind of
document in favor of the more specific terms above — "culture" doesn't tell
a reader whether something is a rule, an aspiration, or an emergent pattern.

## A usable definition of "done"

Four questions the source material uses to check whether a team's ways of
working actually function, not just exist as a wiki page:

1. **Explicit** — are they written, and easy to find/read any time (e.g. in
   team documentation)?
2. **Understood** — is every teammate familiar with the ideas and knows
   where to find more detail?
3. **Open to debate** — does every teammate know how to propose a change,
   comment, or suggest a new practice?
4. **Alertable** — does everyone know quickly when the ways of working are
   broken, and who's responsible for handling it?

A ground-rules doc that fails any of these four is decoration, not a
working agreement.

## Topic areas covered

The repo organizes advice by situation, each with a short "For X" summary
and a deeper `doc/<topic>/` page:

- **Team interaction**: goodness/wellness, focus, respect, collaboration,
  discussions/forums, mutual participation, feedback, reflection.
- **Meetings & communication**: meetings/briefings/standups, asynchronous
  and remote work, chat/messaging, email, hand-signs for voting/
  clarification, schedules/calendars (including Paul Graham's
  maker's-schedule/manager's-schedule distinction).
- **Team logistics**: orientation (a "people" doc and a "projects" doc),
  credentials, shared spaces, team bonding (all-hands, kick-offs, offsites),
  safety.
- **Named external frameworks and essays**, curated rather than
  reproduced in full: Amazon's high-velocity decision making,
  Basecamp's six-week-cycle work structure, Esther Derby's team norms,
  the Core Protocols, Google's Five Keys to a successful team, Software
  Engineering at Google, SAFe, and several leadership speeches/essays
  (Dave Packard, Elon Musk's Tesla ground rules, Kevin Kelly's advice
  collections).

## Applying this to write a team's own doc

1. Pick the right term from the glossary table for what you're actually
   writing — a "working agreement" implies the team co-developed and
   committed to it; don't label a top-down mandate that way.
2. State the *why*, not just the rule — the repo's own docs consistently
   pair a norm with its rationale (e.g. "prefer ISO date formats... because
   we work with teams across the world").
3. Make it concrete and testable, not aspirational filler — contrast a
   vague "communicate well" against a specific commitment like "read
   messages sent directly to you within 1 business day."
4. Check it against the four-question test above before treating it as
   finished.

## Learn more

- [ways-of-working repository](https://github.com/joelparkerhenderson/ways-of-working) — the full collection this skill summarizes.
- [Glossary](https://github.com/joelparkerhenderson/ways-of-working/tree/main/doc/glossary) — the principles/values/tenets/norms/working-agreements distinctions in full.
- Related repos referenced by the collection: [Leadership](https://github.com/joelparkerhenderson/leadership/), [Principles](https://github.com/joelparkerhenderson/principles/), [Team Focus](https://github.com/joelparkerhenderson/team-focus), [OKR](https://github.com/joelparkerhenderson/objectives-and-key-results).