Working Agreements That Actually Work: A Template for Engineering Teams

Working agreements are the explicit rules your engineering team agrees to follow. They cover everything from code review turnaround times to meeting etiquette to how you handle disagreements. When done well, they reduce friction and create predictability. When done poorly, they're ignored documents that collect dust. This guide shows you how to create working agreements that actually work.

"The best working agreements are the ones you don't have to think about—they're just how the team operates. The worst are the ones posted on the wall that nobody follows."

What Are Working Agreements?

A working agreement is a set of guidelines that a team creates together to define how they'll work. Unlike policies imposed from above, working agreements are team-owned—created by the people who follow them, for the people who follow them.

Working agreements typically cover:

• Communication: Response times, meeting norms, async vs. sync
• Code practices: Review turnaround, PR size limits, testing requirements
• Collaboration: Pairing expectations, knowledge sharing, documentation
• Availability: Core hours, on-call expectations, time-off communication
• Decision-making: How to resolve disagreements, escalation paths

Why Working Agreements Matter

Without explicit agreements, teams operate on implicit assumptions—and assumptions diverge. One engineer thinks "I'll review PRs when I have time." Another thinks "PRs should be reviewed within 4 hours." Both are frustrated, neither is wrong, and nothing improves until someone makes it explicit.

Benefits of Good Working Agreements

Working Agreement Examples

Here are concrete examples organized by category. Don't copy these directly—use them as starting points for your team's discussion.

Code Review Agreements

## Code Review Working Agreements

### Turnaround Time
- PRs should receive initial review within 4 business hours
- Authors should respond to review comments within 24 hours
- If you can't review in time, communicate in Slack

### PR Standards
- PRs should be <400 lines of code (excluding tests, generated files)
- Every PR needs at least 2 reviewers for production code
- Self-merging is allowed for typos/docs with no code changes

### Review Quality
- Approve means "I would ship this"—not "I looked at it"
- Blocking comments should explain why AND suggest alternatives
- Use "nit:" prefix for style suggestions that shouldn't block

### When to Pair Instead
- If a PR will take >30 minutes to review, consider pairing
- Complex architectural changes should be discussed before coding

Communication Agreements

## Communication Working Agreements

### Async vs. Sync
- Default to async (Slack, docs, PRs)
- Meetings are for discussion, not information sharing
- Urgent issues: Slack with @mention, then escalate to call if no response in 30min

### Response Expectations
- Slack DMs: Respond within 4 hours during work hours
- @channel mentions: Read within 2 hours
- Email: Respond within 24 hours (or set auto-reply if OOO)

### Meeting Norms
- Meetings start on time (no waiting for latecomers)
- Camera on for team meetings, optional for large meetings
- End meetings 5 minutes early to allow breaks
- Decline meetings without agendas

### Documentation
- Decisions should be documented in writing (Confluence/Notion)
- "If it's not written down, it didn't happen"
- PRs should link to relevant docs/tickets

Availability Agreements

## Availability Working Agreements

### Core Hours
- Core collaboration hours: 10am-4pm [timezone]
- Meetings should be scheduled within core hours
- No expectation to respond outside core hours

### Focus Time
- Everyone blocks 2+ hours of focus time daily
- Respect focus time—don't interrupt unless urgent
- Use Slack status to signal availability

### Time Off
- Announce PTO in team channel at least 1 week ahead
- Ensure coverage for on-call and critical reviews
- Out of office = actually offline (no "just checking in")

### After Hours
- Production incidents may require after-hours response
- Non-urgent issues wait until next business day
- No shame in not responding to weekend Slack

Creating Effective Working Agreements

"The process of creating working agreements is as valuable as the agreements themselves. It forces the team to surface assumptions and find common ground."

Step 1: Identify Pain Points

Start with what's broken. Ask the team:

• What causes friction or frustration in how we work?
• What assumptions have caused misunderstandings?
• What do you wish was more predictable?

Step 2: Draft Together

Working agreements should be created by the team, not imposed by managers. This means:

• Schedule a dedicated session (60-90 minutes)
• Everyone contributes—not just the loudest voices
• Focus on behaviors, not personalities
• Write down exactly what you agree to

Step 3: Make Agreements Specific

Vague agreements are useless. Compare:

Step 4: Make Agreements Measurable

If you can't measure it, you can't improve it. For each agreement, identify:

• How will we know if we're following this?
• What data can we look at?
• How often will we check?

Enforcing (or Not) Working Agreements

Here's the uncomfortable truth: working agreements that require enforcement have already failed. The goal is agreements that the team wants to follow because they make work better.

What Works

• Visibility: Show metrics in team retros, not to blame but to discuss
• Accountability partners: Pair people to remind each other
• Automation: PR size limits in CI, Slack reminders for stale PRs
• Regular review: Check agreements quarterly—update what isn't working

What Doesn't Work

• Punishment: Fining people for violations creates resentment
• Public shaming: Calling out individuals damages trust
• Manager enforcement: Turns team agreements into top-down rules
• Rigid adherence: Agreements should have escape valves for exceptions

"If an agreement is consistently broken, the problem isn't the people—it's the agreement. Either it's unrealistic, unclear, or addressing the wrong problem."

Working Agreements for Agile Teams

Agile teams often have additional agreements around ceremonies and processes:

Sprint Agreements

## Sprint Working Agreements

### Planning
- Sprint planning is 1 hour max
- Only items with clear acceptance criteria enter the sprint
- Capacity is calculated after accounting for PTO and meetings

### Daily Standup
- Standup at [time], max 15 minutes
- Focus on blockers, not status updates
- Deep dives happen after standup, not during

### Sprint Review
- Demo working software, not slides
- Stakeholders can attend but questions are held until the end
- Celebrate wins before discussing improvements

### Retrospective
- What we discuss in retro stays in retro
- Focus on systems, not people
- Every retro produces at least one actionable improvement

Working Agreements for Distributed Teams

Remote and distributed teams need more explicit agreements because they can't rely on office-proximity cues:

## Distributed Team Working Agreements

### Timezone Considerations
- Core overlap hours: 2pm-6pm UTC
- Async updates in Slack replace synchronous standups
- Record all meetings for people in other timezones

### Communication
- Slack status reflects true availability
- Over-communicate when blocked—don't wait for someone to ask
- Use video for complex discussions, async for simple updates

### Handoffs
- End-of-day updates in #team-updates channel
- PRs should be self-explanatory (don't assume reviewer can ask questions)
- Document decisions in writing—"we talked about it" doesn't scale

### Trust and Autonomy
- No tracking software or "productivity" monitoring
- Judge by outcomes, not hours online
- Assume good intent when messages seem terse

Keeping Agreements Alive

Working agreements decay. Team composition changes, tools change, and what worked six months ago might not work now. Build in regular reviews:

Quarterly Review Checklist

1. Are we following our agreements? Look at actual data (review time, PR size, etc.)
2. Which agreements are consistently broken? Discuss why—maybe they need updating
3. What new friction has emerged? Add agreements for new pain points
4. What's no longer relevant? Remove agreements that don't matter anymore
5. Do new team members know about these? Update onboarding docs

Related Guides

• Async Code Review for Distributed Teams — How to make code review work across time zones
• Reduce PR Cycle Time — Tactics to speed up your review process
• Review Load Balancing — Distribute review work fairly across the team
• Engineering Metrics Without Surveillance — Using data without creating a surveillance culture

Conclusion

Working agreements are the operating system for how your team collaborates. They turn implicit assumptions into explicit commitments, reduce friction, and create accountability. But they only work if:

• The team creates them together—not imposed from above
• They're specific and measurable—not vague aspirations
• They're visible and tracked—not forgotten in a doc somewhere
• They evolve over time—updated when they stop working

"Your team already has working agreements—they're just implicit. Make them explicit, and you can actually improve them."

Start small. Pick one or two areas of friction and create agreements for those. Use tools like CodePulse to track whether you're following your own rules. And remember: the goal isn't compliance—it's a team that works better together.