Cadence¶

Cadence is the heartbeat of a team.

It's the predictable rhythm that tells everyone when to synchronize, when to plan, when to reflect, and when to ship. Without cadence, teams operate reactively—lurching from deadline to deadline, never quite sure what's coming next. With cadence, teams operate proactively—anticipating what's needed, preparing in advance, and maintaining a sustainable pace.

The goal is not to fill calendars. It's to create enough structure that people can focus on their work without constantly wondering what's happening, while leaving enough flexibility that the team can adapt when reality demands it.

What problem this solves¶

Without a clear cadence:

People don't know when to expect planning, reviews, or feedback.
Synchronization happens ad-hoc, usually too late.
Some work gets rushed while other work languishes.
The team feels chaotic even when individuals are working hard.
Remote team members struggle to stay connected.

A well-designed cadence provides the structure that enables autonomy. People know when the checkpoints are, so they can manage their own time between them.

When to use this¶

Use this when:

Forming a new team and establishing operating norms.
A team feels chaotic or unpredictable.
Coordination is breaking down between team members or with stakeholders.
Transitioning from co-located to remote work.
Scaling a team and needing more explicit structure.

Don't use this when:

The team is small (2–3 people) and naturally in sync—keep it light.
You're in crisis mode and need to focus on immediate fires.
The cadence itself has become the problem (too many meetings, too much overhead).

Roles and ownership¶

Role	Responsibility
Engineering Manager	Owns the cadence design. Ensures it's serving the team. Adjusts based on feedback.
Tech Lead	Partners on cadence design, especially technical ceremonies (architecture reviews, tech debt discussions).
Product Manager	Coordinates cadence with product planning cycles. Ensures alignment between team and stakeholder rhythms.
Team members	Follow the cadence. Raise concerns when it's not working. Participate actively in rituals.

The EM owns the cadence, but it should be co-created with the team and regularly reviewed.

The cadence layers¶

Good cadence operates at multiple time horizons:

Daily rhythm¶

Purpose: Keep the team loosely synchronized without heavy meetings.

Async standup (async, daily): What I did, what I'm doing, any blockers.
Core collaboration hours (2–4 hours of overlap): When synchronous work can happen.

Daily rhythm should be lightweight. The goal is awareness, not status reporting.

Weekly rhythm¶

Purpose: Ensure the team is aligned and making progress toward sprint/iteration goals.

Day	Activity	Purpose
Monday	Week kickoff (async or brief sync)	Confirm priorities for the week
Daily	Async standup	Maintain visibility
Wednesday	Mid-week sync (optional, 15 min)	Surface blockers, adjust course
Friday	Week wrap-up (async)	Summarize progress, capture learnings

Weekly rhythm creates accountability without micromanagement.

Sprint/iteration rhythm (1–2 weeks)¶

Purpose: Plan work, execute, and reflect in manageable cycles.

When	Activity	Purpose
Sprint start	Planning	Commit to achievable goals
Mid-sprint	Demo/check-in	Show progress, get feedback
Sprint end	Demo + Retrospective	Celebrate, learn, improve

Sprint rhythm creates a forcing function for delivery and continuous improvement.

Quarterly rhythm¶

Purpose: Align on strategy, review progress, and plan the next horizon.

When	Activity	Purpose
Quarter start	Quarterly planning	Set OKRs, define major initiatives
Mid-quarter	Check-in	Assess progress, adjust if needed
Quarter end	Review + Retrospective	Evaluate outcomes, extract learnings

Quarterly rhythm connects team work to organizational strategy.

Designing your cadence¶

Step 1: Identify your constraints¶

What's fixed that your cadence must work around?

Time zone distribution of the team.
Product release schedules.
Stakeholder availability.
Dependencies on other teams.
Company-wide rhythms (all-hands, planning cycles).

Step 2: Choose your iteration length¶

Most teams work best with 1–2 week iterations:

Length	When it works	When it doesn't
1 week	Fast-moving, well-understood work; small teams; high trust	Needs tight coordination; can feel rushed
2 weeks	Most common; enough time for meaningful work; not too long to course-correct	Work that doesn't fit in 2 weeks needs slicing
4 weeks	Research, platform work, longer initiatives	Hard to maintain urgency; feedback loops too slow

Start with 2 weeks unless you have a strong reason not to.

Step 3: Map the rituals to the cadence¶

For each cadence layer, identify:

What rituals happen at what frequency?
How long should each ritual take?
Who participates?
What's the expected output?

See Rituals for detailed guidance on each ceremony.

Step 4: Optimize for time zones¶

For distributed teams, cadence design must account for time zone fairness:

Identify overlap hours. When can everyone reasonably meet?
Rotate meeting times. Don't make the same people sacrifice their mornings or evenings.
Default to async. Only use synchronous time when it's genuinely needed.
Record and summarize. Those who can't attend live should still have access.

Step 5: Communicate and commit¶

Once the cadence is designed:

Document it in the working agreement.
Put recurring meetings on calendars.
Set expectations about participation.
Agree on how you'll evaluate and adjust.

Example cadence: 2-week sprint, distributed team¶

## Team Alpha Cadence

### Daily

- **Async standup** (Slack, by 10am local time): What I did, what I'm doing, blockers.
- **Core hours**: 14:00–17:00 UTC (overlap for EU + Americas)

### Weekly

- **Monday**: Sprint week kickoff (async). PM posts priorities; team confirms.
- **Wednesday**: Optional sync (15 min, 15:00 UTC). Only if needed for blockers.
- **Friday**: Week wrap-up (async). What shipped, what's carrying over.

### Sprint (2 weeks)

- **Sprint Planning** (60 min, Day 1): Review backlog, commit to goals, assign work.
- **Mid-Sprint Demo** (30 min, Day 5): Show progress to stakeholders, get early feedback.
- **Sprint Demo** (30 min, Day 10): Show completed work to broader audience.
- **Retrospective** (60 min, Day 10): What worked, what didn't, one improvement to try.

### Quarterly

- **Quarterly Planning** (half-day, first week of quarter): Set OKRs, align on initiatives.
- **Mid-Quarter Check-in** (60 min, week 6): Progress review, course correction.
- **Quarterly Review** (90 min, last week): Outcomes, learnings, team health.

### Time zone rotation

- Sprint planning alternates between 09:00 UTC (EU-friendly) and 16:00 UTC (Americas-friendly).
- Quarterly planning is recorded for async viewing.

Signals that cadence is working¶

The team can predict what's happening this week and next.
Meetings start and end on time, with clear outcomes.
People don't feel surprised by deadlines or decisions.
Remote team members feel included and informed.
The pace feels sustainable, not exhausting.
The team delivers consistently, not in bursts.

Failure modes and mitigations¶

Failure mode	What it looks like	Mitigation
Over-scheduled	Too many meetings; no time for deep work	Audit ruthlessly; cut anything that doesn't clearly serve
Cadence drift	Rituals get skipped; schedule becomes unpredictable	Protect the cadence; reschedule, don't cancel
Time zone inequity	Same people always sacrifice their hours	Rotate meeting times; invest in async
Ritual without purpose	Going through the motions; no real value	Every ritual needs a clear output; measure it
Cadence doesn't fit the work	Sprints are too long or too short for the nature of the work	Adjust iteration length; match cadence to reality

Copy-pastable artifact: Cadence template¶

# [Team Name] Cadence

## Daily rhythm

- **Async standup**: [Where, by when]
- **Core collaboration hours**: [Time range in UTC]

## Weekly rhythm

| Day   | Activity   | Format       | Duration   |
| ----- | ---------- | ------------ | ---------- |
| [Day] | [Activity] | [Sync/Async] | [Duration] |

## Sprint rhythm ([Length])

| When     | Activity            | Format   | Duration   | Participants |
| -------- | ------------------- | -------- | ---------- | ------------ |
| Day 1    | Sprint Planning     | Sync     | [Duration] | [Who]        |
| Day [X]  | Mid-Sprint Check-in | [Format] | [Duration] | [Who]        |
| Last day | Demo                | Sync     | [Duration] | [Who]        |
| Last day | Retrospective       | Sync     | [Duration] | Team only    |

## Quarterly rhythm

| When    | Activity             | Format   | Duration   |
| ------- | -------------------- | -------- | ---------- |
| Week 1  | Quarterly Planning   | [Format] | [Duration] |
| Week 6  | Mid-Quarter Check-in | [Format] | [Duration] |
| Week 12 | Quarterly Review     | [Format] | [Duration] |

## Time zone considerations

- [How you handle time zone fairness]
- [What gets recorded/summarized for async consumption]

## Cadence review

- We review this cadence in retrospectives.
- Major changes are proposed and agreed as a team.
- Last updated: [Date]

Rituals — What happens at each cadence point.
Working Agreements — Where cadence is documented.
Async Communication — Making cadence work across time zones.
Meeting Standards — Making synchronous rituals effective.
Delivery: Planning & Slicing — How to fill the sprint with the right work.