Skills on AI 459 skills

Active theme: Light

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:

  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

View ways-of-working/SKILL.md on GitHub