Skip to main content

Ways of Working

Guidelines for effective team collaboration, clear responsibilities, and a healthy engineering culture.

Overview​

Ways of Working define how a team collaborates, communicates, and holds each other accountable. They create shared expectations and reduce friction, allowing teams to focus on delivering value.

Purpose

Clear ways of working prevent misunderstandings, reduce coordination overhead, and create a foundation for high-performing teams.

Team Structure and Roles​

Scrum Roles​

Product Owner

  • Responsible for: Product backlog, priorities, business value
  • Accountable for: ROI, stakeholder satisfaction
  • Key activities:
    • Define and prioritize backlog
    • Write and refine user stories
    • Accept or reject work
    • Communicate with stakeholders
    • Make scope/timeline trade-off decisions

Scrum Master

  • Responsible for: Scrum process, removing impediments
  • Accountable for: Team effectiveness, continuous improvement
  • Key activities:
    • Facilitate scrum ceremonies
    • Remove blockers
    • Coach team on agile practices
    • Shield team from distractions
    • Foster self-organization

Development Team

  • Responsible for: Delivering working software
  • Accountable for: Quality, sprint commitment
  • Key activities:
    • Estimate and plan work
    • Develop, test, and deploy features
    • Collaborate on technical decisions
    • Participate in ceremonies
    • Continuously improve

Technical Roles​

Tech Lead

  • Guides technical direction
  • Reviews complex technical designs
  • Mentors developers
  • Escalation point for technical decisions
  • Balances short-term delivery with long-term quality

Backend Developer

  • API development
  • Database design
  • Service integration
  • Performance optimization

Frontend Developer

  • UI implementation
  • User experience
  • Client-side state management
  • Accessibility

Mobile Developer

  • iOS/Android app development
  • Native platform integration
  • Mobile-specific patterns
  • App store management

DevOps Engineer

  • CI/CD pipelines
  • Infrastructure automation
  • Monitoring and alerting
  • Deployment strategies

Communication Guidelines​

Daily Communication​

Slack/Teams:

  • Use for: Quick questions, updates, coordination
  • Response time: Within 4 hours during work hours
  • Channels:
    • #team-payments: Team-specific discussions
    • #engineering: Cross-team engineering topics
    • #incidents: Production issues (monitor actively)
    • #releases: Deployment notifications

Email:

  • Use for: Formal communication, external stakeholders
  • Response time: Within 24 hours

Video Calls:

  • Use for: Complex discussions, pairing, design reviews
  • Best practices:
    • Camera on when possible (builds connection)
    • Mute when not speaking
    • Use screen sharing for technical discussions
    • Record important decisions

Meetings​

Core Hours:

  • 9:30 AM - 4:00 PM: Everyone expected to be available
  • Outside core hours: Async communication preferred
  • No meeting blocks: 9:00-10:00 AM (focus time), 1:00-2:00 PM (lunch)

Meeting Etiquette:

  • Be on time (or 1-2 minutes early)
  • Come prepared (read materials beforehand)
  • Have an agenda (share 24 hours ahead)
  • Take notes (rotate note-taker)
  • End with clear action items
  • No laptops unless needed (stay present)

Meeting Sizes:

  • Decision meeting: <5 people (more = slower decisions)
  • Information sharing: Async (email, Confluence) unless discussion needed
  • Brainstorming: 3-8 people (diverse perspectives)

Documentation​

Where to Document:

  • Confluence: Long-form docs, design docs, runbooks, team wiki
  • README.md: Repository setup, architecture overview
  • Code comments: Complex logic, "why" decisions
  • ADRs: Architectural decisions
  • Jira: User stories, acceptance criteria, sprint planning

Documentation Standards:

  • Write for someone joining the team next month
  • Update docs when code changes
  • Link related documents
  • Include diagrams where helpful
  • Mark outdated docs clearly (delete if no longer relevant)

Collaboration Practices​

Pair Programming​

When to Pair:

  • Complex or critical features
  • Onboarding new team members
  • Knowledge sharing (e.g., domain expert + developer)
  • Debugging tricky issues
  • Learning new technology

How to Pair:

  • Driver: Types code, thinks tactically
  • Navigator: Reviews code, thinks strategically
  • Switch roles every 20-30 minutes
  • Take breaks every 90 minutes
  • Prepare beforehand (understand the problem)

Pairing Anti-Patterns:

  • One person dominates (switch roles more often)
  • Pairing on trivial tasks (not worth it)
  • No breaks (leads to fatigue)
  • Pairing all day every day (too draining)

Mob Programming​

When to Mob:

  • Critical architectural decisions
  • Complex problem requiring diverse input
  • Team learning sessions
  • Kickoff of complex features

How to Mob:

  • 3-6 people (more = diminishing returns)
  • One driver, everyone else navigates
  • Rotate driver every 10-15 minutes
  • Timebox sessions (2 hours max)
  • Retrospect on effectiveness

Code Review​

See Code Review Guidelines for detailed practices.

Key Principles:

  • Review within 4 hours
  • Be kind and constructive
  • Approve if it improves codebase (perfect is enemy of good)
  • Ask questions rather than make demands
  • Explain "why" for requested changes

Decision-Making​

Decision Levels​

Different decisions require different processes based on reversibility and impact. This framework clarifies who decides what, reducing coordination overhead and decision paralysis.

Level 1: Individual Decisions (Reversible, low impact)

  • Variable naming, code formatting, local refactoring
  • Process: Just do it, no approval needed
  • Why: Waiting for approval on trivial decisions kills velocity. If it's easily reversible and affects only your code, decide and move forward.

Level 2: Team Decisions (Reversible, medium impact)

  • Story estimation, task breakdown, test strategy for a feature
  • Process: Discuss in standup or planning, reach consensus
  • Why: Team members have context needed to make good decisions. Consensus builds shared ownership and surfaces concerns early.

Level 3: Tech Lead Decisions (Reversible, high impact)

  • Library/framework choice within team, database schema changes, API contract changes
  • Process: Tech Lead decides after team input
  • Why: Requires technical judgment and long-term thinking. Team input surfaces trade-offs; Tech Lead breaks ties and owns the decision.

Level 4: Architecture Decisions (Hard to reverse, organization-wide)

  • New technology adoption, architecture patterns, cross-team API standards
  • Process: RFC/ADR, architecture review, consensus
  • Why: Impacts multiple teams and is expensive to reverse. Requires broad input, documentation, and buy-in before committing. See Technical Design for ADR process.

Disagree and Commit​

When team can't reach consensus:

  1. Discuss: Everyone shares perspective
  2. Debate: Challenge assumptions, explore trade-offs
  3. Decide: Decision-maker (usually Tech Lead) makes call
  4. Commit: Everyone supports the decision, even if they disagreed
Decision-Making Culture
  • Bias to action: Make decision with 70% information (don't over-analyze)
  • Reversible decisions: Move fast, fix if wrong
  • Irreversible decisions: Move carefully, gather more data

Quality Standards​

Code Quality​

Before Creating PR:

  • Code compiles without errors/warnings
  • All tests pass locally
  • Linting passes (zero errors)
  • Self-reviewed the code
  • Manually tested the feature

Definition of Done: See Definition of Done for comprehensive checklist.

Code Reviews:

  • Minimum 1 approval for feature PRs
  • Minimum 2 approvals for release PRs
  • Code owner approval for affected areas
  • All comments addressed or discussed

Testing Standards​

Testing Pyramid:

The testing pyramid shows the proportion of each test type. Lower layers test more code with less cost; higher layers test closer to user experience with higher cost. This distribution balances speed, cost, and confidence.

Unit tests form the foundation because they're fast (milliseconds), cheap to maintain, and pinpoint failures. Integration tests verify components work together. Contract tests ensure APIs don't break consumers. E2E tests validate critical user flows end-to-end. The pyramid shape reflects cost and quantity: more fast cheap tests at the bottom, fewer slow expensive tests at the top. See Testing Strategy for detailed guidance.

Coverage Targets:

  • Overall: >85%
  • New code: >90%
  • Critical paths (payment processing): 100%

Coverage measures which code lines execute during tests, not whether tests are good. 100% coverage with weak assertions proves nothing (see mutation testing). Use coverage to find untested code, not as a quality metric.

Time Management​

Focus Time​

Deep Work Blocks:

  • 9:00-10:00 AM: Focus time (no meetings, no Slack)
  • 2:00-4:00 PM: Coding time (minimize interruptions)
  • Use "Do Not Disturb" status
  • Decline meetings during focus blocks (unless urgent)

Context Switching:

  • Batch similar tasks (e.g., review all PRs in one session)
  • Finish work in progress before starting new work
  • Use pomodoro technique (25 min focus, 5 min break)

Work-Life Balance​

Working Hours:

  • Core hours: 9:30 AM - 4:00 PM (expected availability)
  • Flexible outside core hours
  • No expectation to respond after 6:00 PM or on weekends
  • Respect time zones (remote teams)

Time Off:

  • Update calendar with PTO
  • Notify team in Slack
  • Set Slack status with return date
  • Hand off critical work before leaving
  • Don't check work messages during PTO

Sustainable Pace:

  • 40-hour work week is the norm
  • Occasional crunch OK for critical deadlines
  • If consistently working >45 hours: raise with manager
  • No hero culture (burnout helps no one)

Onboarding New Team Members​

Week 1: Setup and Context​

Day 1:

  • Workspace setup (laptop, accounts, badges)
  • Introductions to team
  • Assign onboarding buddy
  • Read team documentation (this guide!)
  • Attend team standup (observer)

Day 2-3:

  • Development environment setup
  • Clone repositories
  • Run application locally
  • Understand architecture (design docs, diagrams)
  • Shadow pair programming session

Day 4-5:

  • Pick up small, well-defined ticket
  • Pair with buddy on first PR
  • Participate in code review
  • Attend sprint ceremonies

Week 2: First Contributions​

  • Complete first ticket independently
  • Review others' PRs
  • Participate actively in standup
  • Ask lots of questions (expected!)

Week 3-4: Ramp Up​

  • Work on medium-complexity tickets
  • Review onboarding experience (feedback to team)
  • Identify documentation gaps
  • Begin contributing to team rituals

Month 2-3: Full Productivity​

  • Take on complex tickets
  • Lead design discussions
  • Mentor next new hire
  • Fully integrated team member

Onboarding Buddy Responsibilities:

  • Daily check-ins for first week
  • Answer questions (no question is stupid)
  • Pair on first few tickets
  • Introduce to team and stakeholders
  • Review PRs with detailed feedback

Incident Response​

Severity Levels​

SEV 1 - Critical:

  • Payment processing down
  • Data breach or security incident
  • Complete service outage
  • Response: Immediate, all-hands-on-deck

SEV 2 - High:

  • Degraded performance (>50% slower)
  • Partial feature outage
  • Critical bug affecting subset of users
  • Response: Within 30 minutes, dedicated team

SEV 3 - Medium:

  • Minor feature broken
  • Non-critical bug
  • Performance degradation (<50%)
  • Response: Next business day

SEV 4 - Low:

  • Cosmetic issues
  • Minor annoyances
  • Response: Backlog, prioritized normally

Incident Process​

  1. Detect: Monitoring alerts, user reports trigger awareness something is wrong
  2. Declare: Create incident ticket, assign severity (SEV 1-4), start incident clock
  3. Assemble: Incident commander coordinates; tech lead debugs; communications lead updates stakeholders; scribe documents
  4. Communicate: Update stakeholders every 30 mins (SEV 1/2) even if no progress - silence creates panic
  5. Mitigate: Stop the bleeding first (rollback, feature flag off, traffic reroute) - don't aim for perfect fix
  6. Resolve: Deploy root cause fix once system is stable and fix is tested
  7. Post-Mortem: Blameless retrospective within 48 hours, create prevention action items (see Incident Post-Mortems)

Why separate mitigation from resolution: Mitigation is fast and imperfect - gets system working even if ugly. Resolution is slow and correct - fixes root cause properly. In a SEV 1 (payment processing down), you rollback immediately (mitigation) even if it disables a feature, then spend hours debugging and testing the proper fix (resolution). Speed matters more than perfection during incidents.

Incident Roles:

  • Incident Commander: Coordinates response, makes decisions, declares incident over. Not necessarily the most technical person - needs clear communication and decision-making under pressure
  • Technical Lead: Debugs issue, implements fix. The technical expert who knows the system
  • Communications Lead: Updates stakeholders with non-technical summaries. Translates technical details into business impact
  • Scribe: Documents timeline, actions taken, decisions made. Critical for post-mortem - memory is unreliable during high-stress incidents

On-Call​

On-Call Schedule:

  • Weekly rotation
  • Handoff Monday morning
  • Backup on-call assigned

On-Call Responsibilities:

  • Respond to pages within 15 minutes
  • Escalate if can't resolve in 30 minutes
  • Update incidents in tracking system
  • Handoff unresolved issues at end of rotation

On-Call Compensation:

  • Time off in lieu for weekend pages
  • Overtime pay (if applicable)
  • Recognition for challenging incidents

Continuous Improvement​

Retrospective Actions​

  • Review previous retro actions at start of new retro
  • Assign owner to each action item
  • Make actions specific and measurable
  • Limit to 1-3 actions per sprint (focus)
  • Celebrate improvements

Team Health Metrics​

Track and discuss quarterly:

  • Velocity: Story points per sprint (trending up/down/stable?)
  • Cycle Time: Time from "In Progress" to "Done"
  • PR Review Time: Time to first review, time to merge
  • Bug Rate: Bugs per story (quality indicator)
  • Deployment Frequency: How often we ship to production
  • MTTR: Mean time to recovery (how fast we fix incidents)
  • Team Satisfaction: Anonymous survey (1-10 scale)

Knowledge Sharing​

Lunch & Learns (Bi-weekly):

  • 30-45 minute sessions
  • Rotate presenters
  • Topics: New technology, lessons learned, architecture deep-dives
  • Optional attendance

Tech Talks (Monthly):

  • External speakers or team members
  • 60 minutes
  • Broader technical topics
  • Open to other teams

Documentation Culture:

  • Write README for every repo
  • Document complex decisions (ADRs)
  • Update docs when code changes
  • Reward good documentation

Team Norms​

Core Values​

Transparency:

  • Share context openly
  • Communicate bad news early
  • Admit mistakes
  • Make work visible (Jira, PRs, standups)

Ownership:

  • "See it, own it, solve it"
  • Don't assume someone else will fix it
  • Follow through on commitments
  • Escalate when blocked

Respect:

  • Assume good intent
  • Value diverse perspectives
  • Listen actively
  • Provide constructive feedback
  • Disagree without being disagreeable

Excellence:

  • High quality bar
  • Continuous learning
  • Take pride in work
  • Leave code better than you found it

Collaboration:

  • Ask for help
  • Offer help
  • Share knowledge
  • Pair when helpful
  • Review each other's work thoughtfully

Conflict Resolution​

When conflict arises:

  1. Talk directly: Address with the person (not others)
  2. Assume good intent: They're trying their best
  3. Focus on problem: Not the person
  4. Seek to understand: Ask questions before judging
  5. Find common ground: Shared goals
  6. Escalate if needed: Manager, Scrum Master, or HR

Disagreements are healthy when:

  • Respectful and professional
  • Focused on better outcomes
  • Backed by data or reasoning
  • Open to changing minds

Remote and Hybrid Work​

Remote-First Practices​

Even if some team members are co-located:

  • Default to video calls (not hallway conversations)
  • Document decisions (not just verbal agreements)
  • Async communication (respect time zones)
  • Inclusive meetings (everyone joins their own laptop, even if in same office)

Hybrid Meeting Etiquette​

  • Camera on when speaking (builds connection)
  • Mute when not speaking (reduces noise)
  • Use hand raise feature (orderly discussions)
  • Chat for questions (don't interrupt speaker)
  • Repeat questions (for remote attendees)

Building Connection Remotely​

  • Virtual coffee chats: Random 1:1s
  • Team retrospectives: Celebrate wins
  • Informal Slack channels: #random, #pets, #gaming
  • Team events: Virtual game nights, hackathons
  • In-person meetups: Quarterly if possible

Recognition and Feedback​

Positive Feedback​

Give feedback when:

  • Someone goes above and beyond
  • Code review was especially helpful
  • Teammate unblocked you
  • Great presentation or demo

How to give:

  • Specific (what they did)
  • Timely (within 24-48 hours)
  • Public when appropriate (team channel)
  • Sincere and genuine

Example:

"@teammate Thanks for that thorough code review on my payment refund PR.
Your suggestion to use a state machine made the code much clearer, and
catching the race condition saved us from a production bug. Really appreciate it!"

Constructive Feedback​

Give feedback when:

  • Pattern of behavior affecting team
  • Code quality concerns
  • Missed commitments
  • Communication issues

How to give:

  • Private (1:1 conversation)
  • Timely (don't let it fester)
  • Specific (examples, not generalizations)
  • Focus on behavior, not character
  • Suggest alternatives
  • Listen to their perspective

SBI Framework:

  • Situation: When this happened...
  • Behavior: You did this...
  • Impact: It had this effect...

Example:

"In yesterday's standup (Situation), when you said 'this code is terrible'
about Jane's PR (Behavior), it came across as harsh and made Jane defensive,
which prevented constructive discussion (Impact).

In the future, could you phrase feedback as questions or suggestions? Like
'Have we considered extracting this into a separate method?' That tends to
lead to better discussions."

Receiving Feedback​

  • Listen actively: Don't interrupt or defend
  • Assume good intent: They're trying to help
  • Ask clarifying questions: Understand the concern
  • Thank them: Even if you disagree
  • Reflect: Consider if there's truth to it
  • Follow up: Show you've taken action

Summary​

Key Takeaways:

  1. Clear roles and responsibilities reduce confusion and overlap
  2. Effective communication balances sync and async, uses right medium
  3. Decision-making framework clarifies who decides what
  4. Quality standards ensure consistent excellence
  5. Time management practices protect focus time and work-life balance
  6. Onboarding structure gets new members productive quickly
  7. Incident response keeps us calm and effective under pressure
  8. Continuous improvement makes team better every sprint
  9. Team norms create healthy, high-performing culture
  10. Regular feedback builds trust and improves performance
Living Document

Ways of Working should evolve with the team. Review quarterly, discuss in retrospectives, and update when practices change. What works for a 3-person startup team differs from a 30-person enterprise team. Adapt these guidelines to your context.