Team playbook: how we work together

A playbook describes the whole team's everyday working rules: how you set priorities, divide responsibility, communicate, use agents and release changes. A new person should be able to understand from it how to join the work. Someone already on the team should be able to find an agreement instead of asking about it again.

Make a map of rules and knowledge

In my playbook, I treated the main page as an entry point for people and agents. From it, we go to six areas:

• Product rules: who we build for, what value the product should provide, and what guides decisions.
• Domain knowledge: concepts, rules, exceptions, and their rationale. A shared team can develop several products, but their rules may differ.
• Team organization: responsibilities, priorities, work rhythm, communication, and how tasks are recorded.
• Change delivery: from need, through delivery and checking, to acceptance, release, and response to a problem.
• Interface and product use: user flows, forms, messages, and shared screen elements.
• Technical rules: system design, code, agent work, reviews, and tests.

One rule matters: every agreement has one place. The playbook links to it. For each area, say who cares for content, who checks changes, and when it was last confirmed current. File names and document count depend on the project; use what you already have.

Collect system-behaviour descriptions and maintenance instructions in operational documentation. The playbook links to it and says who completes it and when.

Describe everyday work specifically

I also recorded practical organization rules in the playbook. Treat them as examples to adapt:

• One main subject per person. It is clear what someone delivers; helping others and code review fit alongside it. An urgent subject requires a decision about what to defer.
• A short current update. What I did, what I do next, what blocks me, and when I expect to finish. Agree the place and rhythm for such a message.
• A demonstration when the result is ready. You need not wait for a large meeting to collect feedback and accept a small change.
• Checks chosen for risk. A text correction, calculation change, and production failure need different flows. Record who decides and which check is needed; after an urgent fix, complete the agreements.

Start by comparing the document with today’s work. The existence of a rule in an old playbook does not mean it still applies. Scope and progress of a single change remain in the task and project plan.

Agree where everything lives

For me, Jira leads work, Confluence holds agreements, GitHub and CodeRabbit hold code and its review, and Google Chat supports current communication. The deployment portal shows versions, and UptimeRobot helps notice unavailability. That is our set; your team may use other tools.

In the playbook, collect links to tasks, documentation, code, conversations, roadmap, and quarterly goals. Add one sentence to each: why do we look here? A new person should know where to start.

Example: you agree a feature-behaviour change in chat. The lead adds that agreement to the task. If a product rule changes, they also update its Confluence description. Chat keeps the link to that entry. You check task status in Jira, while the plan describes next steps; you do not need to reconstruct agreements from conversation history.

Prepare or update the playbook

The file contains responsibility tables, a working rhythm, an example Jira task, demo and review rules, and message templates for the team. Examples are filled in for a fictional product, with space alongside them for your own agreements.

Download the file and attach it to the project conversation. Point to your existing playbook and other agreements, if you have them. The agent will compare them with the template, help fill in the tables and ask about gaps. The team decides which proposals become rules.

Help us prepare or update the playbook for the whole team. Read the attached template and our current agreements: [links, if any]. Use only allowed sources. First make a map of current sources: product rules, domain knowledge, team organization, change delivery, interface, and technical rules. Identify product scope, the person caring for each area, the person checking changes, and the date it was last confirmed. Do not copy rules between documents. Ask which recorded rules we still use. Then clarify priorities, responsibilities, communication rhythm, work with agents, checks chosen for risk, releases, and maintenance. Separate confirmed agreements from unverified records and new proposals. Identify sources, contradictions, and gaps; ask about them one topic at a time. Do not invent roles or procedures for us. If a playbook already exists, prepare corrections to it rather than a second document. Show a version for joint discussion. Agree with us who will update it and when we return to the rules. Do not change team documents or tool configuration before changes are agreed.

Check whether you can work by it

Give the playbook to another person. Have them find who sets priorities, where to ask a question, which rules apply to an agent, and who responds to a post-release problem. Then trace one recent task: does the actual flow match the description?

Result: one entry point to team and product rules, understandable responsibilities, and people who keep individual areas current. A task checks the rules; the playbook itself covers the whole team’s everyday collaboration.