How to Create Remote Team Values and Principles Document Collaboratively

Remote teams need explicit documentation of values and principles that guide behavior, decision-making, and collaboration. Without the organic interactions of a physical office, building this document through a collaborative process ensures buy-in from everyone and creates a foundation that actually reflects how the team operates.

This guide walks through a practical workflow for creating remote team values using async-first processes, version control, and structured help techniques.

Why Collaborative Creation Matters

Values documents fail when leadership drafts them in isolation and presents them as done. Team members who never contributed to the discussion treat them as performative artifacts. Collaborative creation serves two purposes: the final document benefits from diverse perspectives, and the process itself builds shared understanding about what the team stands for.

Phase 1: Gathering Initial Input

Start with a structured async brainstorm rather than a live meeting. This gives everyone equal opportunity to contribute regardless of timezone.

Create a shared document and ask specific questions:

What behavior do you most appreciate seeing from teammates?
What frustrates you about remote collaboration?
What principles should guide how we make decisions?
What does great teamwork look like in our team?

Give everyone 5-7 days to respond. Here’s a bash script to create a timestamped brainstorm document:

#!/bin/bash
# Create a new values brainstorm entry
TEAM_DIR="team-values"
mkdir -p "$TEAM_DIR"

DATE=$(date +%Y-%m-%d)
FILENAME="$TEAM_DIR/input-$(date +%s).md"

cat > "$FILENAME" << EOF
# Values Brainstorm - $DATE

## What behavior do you most appreciate from teammates?

## What frustrates you about remote collaboration?

## What principles should guide our decisions?

## What does great teamwork look like?

EOF

echo "Created brainstorm template: $FILENAME"

Phase 2: Synthesis and Categorization

Designate a facilitator to synthesize the responses. They cluster similar themes, identify patterns, and draft an initial framework.

Common value categories that emerge:

Communication: How we share information and handle async vs sync discussions
Ownership: Taking responsibility for deliverables
Respect: Time zone awareness, assuming good intent
Growth: Learning from mistakes and knowledge sharing
Results: Outcome over hours, sustainable pace

Create a structured document:

# Team Values Draft

## Communication
- **Over-communicate context**: Share the why behind decisions
- **Async by default**: Reserve sync time for complex discussions
- **Document decisions**: If it wasn't written down, it didn't happen

## Ownership
- **Raise blockers early**: Better to ask for help than miss deadlines silently
- **Take initiative**: If you see something broken, fix it

## Respect
- **Assume good intent**: Text lacks tone—give colleagues the benefit
- **Respect time zones**: Record meetings, use async video

## Growth
- **Learn from mistakes**: Blameless post-mortems make everyone safer
- **Share knowledge**: Teaching reinforces your own understanding

## Results
- **Outcome over output**: Working more hours doesn't equal more value

Share the synthesized draft for another async review. Ask specific questions:

Does this resonate with your experience?
What’s missing that should be here?
What’s here that you disagree with?

Use GitHub issues or PRs for this phase:

---
name: Values Feedback
title: "Values Review: [Category]"
labels: team-values

## Your feedback on this value:
## A real example from your experience:
## Suggested change:

Values should emerge with strong consensus. If three or more team members strongly disagree with a value, revise it or remove it.

Phase 4: Finalization and Version Control

Commit the document to version control. Treat it like code:

git checkout -b values/update-2026-spring
git add team-values/principles.md
git commit -m "Add team values and principles document"
gh pr create --title "Team Values: Final Draft" --body "Please review before merging."

Keep it alongside other team documentation:

docs/
├── values.md          # The living values document
├── decision-log.md    # How we make team decisions
└── onboarding.md      # New team member guide

Phase 5: Living the Document

A values document only matters if the team uses it. Build reference points into workflows:

Onboarding: New team members review and share which resonate most
Retrospectives: Reference values when discussing what worked
Hiring: Share values with candidates to assess cultural fit

Review quarterly. Teams evolve, and values should reflect current priorities.

# Values Review Checklist

- [ ] Quarterly review scheduled
- [ ] New team members introduced to values
- [ ] Recent decisions referenced values
- [ ] Any values feel outdated?

Example Values Document

# Our Team Values

**Last updated**: March 2026

## Communication
### Over-communicate Context
Include the reasoning behind decisions, not just the what.

### Async First
Default to async. Use sync time only for complex discussions.

### Bad News Travels Fast
Share problems early. Hiding issues removes options.

## Ownership
### Take Initiative
If you see something broken, fix it or assign it.

### Raise Blockers Early
Asking for help is a strength. Blockers unraised become crises.

## Respect
### Assume Good Intent
Written communication lacks tone. Give colleagues the benefit.

### Respect Time Zones
Record meetings. Don't expect immediate responses outside core hours.

## Growth
### Learn from Mistakes
Blameless post-mortems. The goal is systemic improvement.

### Share Knowledge
Writing things down helps the team scale.

## Results
### Outcome Over Output
Focus on what actually moves the needle.

### Sustainable Pace
Burnout destroys long-term productivity.

Tools

Remote teams use various tools:

Notion/Confluence: Structured databases with property tracking
GitHub/GitLab: Version-controlled documents with PR reviews
Google Docs: Async commenting and suggestions

Choose tools your team already uses.

Common Pitfalls

Avoid these mistakes:

Too many values: Limit to 5-8 core principles
Generic language: Be specific about what values look like in practice
Written once, never revisited: Treat values as living documents
No accountability: Reference values in feedback and decisions

Built by theluckystrike — More at zovo.one