Ways of Working
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" (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, 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:
- Explicit — are they written, and easy to find/read any time (e.g. in team documentation)?
- Understood — is every teammate familiar with the ideas and knows where to find more detail?
- Open to debate — does every teammate know how to propose a change, comment, or suggest a new practice?
- 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
- 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.
- 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").
- 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."
- Check it against the four-question test above before treating it as finished.
Learn more
- ways-of-working repository — the full collection this skill summarizes.
- Glossary — the principles/values/tenets/norms/working-agreements distinctions in full.
- Related repos referenced by the collection: Leadership, Principles, Team Focus, OKR.