Team handbook
Practical working agreements for our fictional eight-person team. Start with onboarding.
Onboarding
Welcome to the team. This handbook describes a fictional eight-person product team so you can explore a realistic workspace. Names, budgets and policies are examples.
Before your first day
Your manager prepares your laptop, calendar invitations and access requests. Use individual accounts, enable multi-factor authentication and store credentials in the team password manager. Never paste passwords or customer records into this wiki.
Your first week
- Monday: meet your buddy, check your equipment and agree on working hours. Ask your manager to confirm which systems you need.
- Tuesday: read the product guide and shadow a customer-support session using anonymized examples.
- Wednesday: follow a small issue from request to deployment. Your buddy explains the review checklist.
- Thursday: make your first documentation improvement. Ask the page owner to review it.
- Friday: share one thing that helped and one thing that was unclear in your onboarding check-in.
What good looks like after 30 days
You can explain the product, find the owner of an unfamiliar system and deliver a small change with support. Your manager schedules a 30-minute check-in to discuss workload and the next learning goal. Getting stuck is a reason to ask early, not to work late.
Owner: People operations. Review this page whenever the onboarding process changes.
Team rituals
Our fictional team works asynchronously by default. Meetings resolve decisions or unblock people; written updates make participation possible across time zones.
Weekly rhythm
- Monday, 10:00 UTC — planning, 25 minutes: choose the week's three outcomes, assign owners and identify dependencies.
- Wednesday — written progress update: post what changed, what comes next and where you need help. No meeting is required.
- Friday, 14:00 UTC — demo and retrospective, 40 minutes: show completed work, discuss one improvement and give it an owner.
Prepare a useful decision
Leave a record
The facilitator records the decision, owner, due date and any unresolved question in the relevant project book. Link to the source discussion, but write enough context that someone joining next month can understand the result.
Protect focus time
Keep mornings free of optional meetings. If a decision can wait until the next working day, use a written question. For an active service incident, use the incident channel and name one coordinator.
Owner: Team lead. Review at each quarterly retrospective.
Deploy process
This is an example deployment checklist for the fictional handbook team. Adapt commands and rollback steps to your own service before using it operationally.
Before you deploy
- Link the change to an issue that explains the user-visible behavior.
- Get a code review and pass the relevant automated checks.
- Verify the change in staging, including an error path and a small-screen view when the interface changes.
- Check migrations for compatibility with the currently running version. Prepare a separate plan for irreversible data changes.
- Record the release version, previous working version and person watching the release.
Release and observe
Deploy during staffed hours. Announce the affected service in the operations channel, then release through the approved pipeline. Check the health endpoint and complete the user journey changed by the release. Watch errors, latency and failed jobs for 15 minutes against the pre-release baseline.
If something fails
Pause further releases and assign an incident coordinator. Roll back to the recorded working version when the database remains compatible. If rollback could lose data, stop and follow the migration recovery plan. Do not repeatedly redeploy without understanding the failure.
Close the loop
Record the result and link the monitoring evidence. Create follow-up issues with owners for anything still unresolved. A release is complete when users can perform the intended task, not merely when the build is green.
Owner: Engineering. Review after a deployment incident.
Time off
These are fictional team working agreements, not employment terms. Your contract and applicable rules determine your actual entitlement.
Request planned leave
Submit dates through the team's leave system at least two weeks ahead where possible. Add a short handover note and name a proposed backup for time-sensitive work. Your manager checks coverage and confirms the request; a calendar entry alone is not approval.
Prepare a handover
List active tasks, deadlines, the next useful action and links to the relevant pages. Give your backup the access they need before you leave. Reschedule meetings you own and set an out-of-office message with a contact for urgent matters.
When you are ill
Tell your manager through the agreed private channel as soon as reasonably possible. Do not put medical details in a shared wiki or public calendar. Follow the absence-reporting process provided by People operations.
While someone is away
Respect the absence. Route requests to the backup and let non-urgent decisions wait. No one is expected to monitor chat during approved time off.
Owner: People operations. Ask privately if your situation is not covered here.
Expenses
This fictional policy demonstrates how a team can make routine decisions easy to find. It is not a promise of reimbursement by BookHost.
Before spending
Agree business travel and unusual purchases with your manager in writing. Our example team requires approval for any single purchase above EUR 100 and for every recurring subscription, regardless of price. Check for an existing team license before buying another one.
Submit a complete claim
Within ten working days, attach the receipt in the private expense system. Include the purchase date, original currency, business purpose and project. For a shared meal, list attendees there rather than in this public handbook. Use the reimbursement system's exchange-rate process instead of guessing a conversion.
What happens next
Your manager confirms the business purpose; Finance checks the evidence and includes approved claims in the next reimbursement run. If information is missing, Finance returns the claim with a specific question. Keep the original receipt until Finance confirms it can be discarded.
Missing receipt or accidental personal charge
Contact Finance privately and explain what happened. Do not manufacture a replacement receipt or edit a merchant invoice. Finance will explain which evidence is acceptable.
Owner: Finance. Store bank details, receipts and employee information outside shared documentation.