You have 4 summaries left


Two-Person Teams: Listener Questions

Wed Jul 05 2023
workload managementremote worktrustQAtask assignmentsreactive workon-call rotationcool down periods


This episode covers various aspects of managing absences and workload, defaulting to trust in the workplace, quality assurance and testing, task assignments and durations, reactive work and bug handling, on-call rotation and cool down periods. The episode emphasizes the importance of planning ahead for absences, building trust in remote work environments, implementing QA processes as the company scales, assigning tasks based on capacity, handling reactive work and bugs efficiently, and providing cool down periods for self-directed work.


Trust is a key factor in remote work

Remote work companies rely on trust as a prerequisite for successful collaboration, although occasional instances of taking advantage can occur.

Defaulting to trust saves time and money

Micromanaging and constantly verifying everything can be time-consuming and costly compared to defaulting to trust in the workplace.

QA is crucial for launching new features

Thorough testing by a dedicated QA team helps ensure the criticality of new features and avoid data loss.

Task assignments are based on estimated timeframes

Smaller tasks or standalone features are assigned to teams of two based on estimated durations, which vary depending on the complexity of the task.

Reactive work requires efficient handling

Teams and procedures are in place to handle reactive work, including infrastructure-based issues, performance issues, and bugs from previous releases.

On-call rotation promotes collaboration and learning

The on-call schedule involves two people working together for one week out of every cycle, allowing individuals from different teams to collaborate and learn from each other.

Cool down periods facilitate self-directed work

The cool down period provides dedicated time for programmers and designers to address bugs, make refinements, and improve the codebase.


  1. Managing Absences and Workload
  2. Trust and Remote Work
  3. Defaulting to Trust in the Workplace
  4. Quality Assurance and Testing
  5. Task Assignments and Durations
  6. Reactive Work and Bug Handling
  7. On-Call Rotation and Cool Down Period

Managing Absences and Workload

00:00 - 06:31

  • Vacation and sickness are worked out ahead of time in two-person teams.
  • Teams catch up ahead of time and focus on tasks that can be done without the absent team member.
  • Sickness is unavoidable, but teams work around it.
  • Sabbaticals are managed by waiting or finding other tasks to work on in the meantime.
  • Two-person teams refer to feature teams, not product teams.
  • Multiple teams exist to handle different projects and fill in when needed.
  • Time-boxing helps manage scope when team members are absent.

Trust and Remote Work

00:00 - 06:31

  • Shape Up encourages a mindset shift from estimates to focusing on solving problems within a certain timeframe.
  • Planning phase takes into account team availability and workload distribution.
  • Trust is a prerequisite for remote work companies, but occasional instances of taking advantage can occur.
  • Trade-offs of trust are worth it when working with creative people for the long term.
  • Clear boundaries and explicit communication help prevent misunderstandings and taking advantage of policies.

Defaulting to Trust in the Workplace

06:02 - 13:31

  • Unlimited vacation policies can be problematic because they lack clarity and can lead to confusion.
  • Defaulting to trust in the workplace is a better approach than micromanaging and checking up on everything.
  • Over the past 20 years, only a few instances of someone taking advantage of trust have occurred, resulting in minimal financial loss.
  • Defaulting to trust saves time and money compared to constantly verifying everything.
  • Trust should be earned and lost on an individual basis, both at the employee level and within the organization.
  • The concept of a 'trust battery' helps evaluate how much trust an individual has earned or lost based on past experiences.
  • While defaulting to trust is important, there are certain situations where caution is necessary, such as not trusting someone with critical tasks from day one.

Quality Assurance and Testing

13:08 - 19:52

  • Launching new features requires thorough testing to ensure criticality and avoid data loss.
  • QA team performs black box testing as users, finding issues that developers may overlook.
  • Initially, the company did not have a QA team, relying on customer feedback to catch mistakes.
  • QA should be added as the company scales and the consequences of errors increase.
  • Developers also check each other's work through code reviews.

Task Assignments and Durations

13:08 - 19:52

  • Smaller tasks or standalone features are assigned to teams of two based on estimated timeframes.
  • Not every project takes six weeks; durations vary depending on the complexity of the task.
  • The company does not have dedicated people waiting for work; assignments are made based on available capacity.

Reactive Work and Bug Handling

19:31 - 25:41

  • Reactive work could be infrastructure-based, performance issues, bugs from previous releases, or new bugs that pop up.
  • There are teams and procedures in place for reactive work.
  • Some bugs may not be critical and can be dealt with later.
  • Bundling techniques like spring cleaning or roaming time are used to handle non-critical issues.
  • People working on features need uninterrupted time to deliver on the set goals.
  • On-call team handles critical issues while code yellow allows individuals to clean up their own material issues.

On-Call Rotation and Cool Down Period

25:27 - 32:04

  • On-call rotation at the company has gone through various models over the years, but now it involves two people working together for one week out of every cycle.
  • The on-call schedule is set in advance, with occasional swaps for sickness or other issues.
  • Having an on-call buddy allows people from different teams to work together and learn from each other.
  • The cool down period is an important part of Shape Up, providing two weeks six times a year for self-directed work.
  • During the cool down, programmers and designers can address bugs and make refinements to improve the codebase.
  • For those working on ambitious six-week projects, there is a cool down/overrun period to allow for final polish and buffer time.
  • To ensure variety and prevent burnout, team members are not scheduled for solid six-week cycles back-to-back.