The BEAT Manifesto
Balanced. Empowered. Async. Teams.
We are uncovering better ways of building software by doing it and helping others do it.
Through this work we have come to value:
Core Values
Deep work over constant availability
Asynchronous communication over synchronous meetings
Written documentation over verbal agreements
Individual autonomy over prescribed processes
Sustainable pace over heroic effort
Small experiments over perfect plans
That is, while there is value in the items on the right, we value the items on the left more.
The Five Team Values
Beyond what we value in our work, we hold these values in how we treat each other:
Trust — We assume competence and good intent. We give autonomy because we trust it will be used well. We share information openly because we trust it will be handled responsibly.
Courage — We speak up when something is wrong. We admit when we don't know. We challenge decisions respectfully. We try new approaches even when they might fail.
Candor — We give honest feedback, kindly delivered. We say what we mean in writing. We surface problems early rather than hiding them. We disagree openly, then commit.
Ownership — We take responsibility for our work and its impact. We don't wait to be told. We fix what we find broken. We see things through to done.
Calm — We do not create urgency where none exists. We respond thoughtfully, not reactively. We protect each other's focus. We choose sustainable over heroic.
The Twelve Principles of BEAT
On Focus
1. Protect the focus state above all else.
The uninterrupted mind produces the best work. We maintain sacred blocks of four hours daily where no meetings, messages, or interruptions are permitted. The maker chooses when this time occurs.
2. Interruptions are not free.
Research shows 52 minutes to reach deep focus, 23 minutes to recover from interruption. Every "quick question" costs more than it appears. Default to async. Wait for the open window.
3. Presence does not equal productivity.
We do not measure hours worked or time online. We measure outcomes delivered. A maker in focus for four hours outproduces a maker in meetings for eight.
On Communication
4. Writing is thinking made visible.
We write by default. Decisions not documented did not happen. Written words can be searched, referenced, and shared across time zones. They outlive the meeting that never was.
5. Synchronous time is expensive. Spend it wisely.
Meetings cost everyone present, simultaneously. We limit them to two hours per week, one hour maximum each. If it can be written, write it. If it must be discussed, write first, then discuss the delta.
6. Response time is not reaction time.
Async means responding when working, not responding immediately. We expect responses within 24 working hours. Urgent means phone call. Everything else waits.
On Autonomy
7. Trust makers to make.
Those who build the thing decide how to build it. They choose their tools, their approach, their schedule, their collaborators. We provide goals and constraints, not instructions.
8. Pull, don't push.
Work is not assigned. Work is pulled by those with capacity and interest. Makers select from a prioritized stack. They may skip with reason. They may propose alternatives.
9. The maker's "no" is valid.
Makers may refuse work that is unethical, impossible, or poorly conceived. They may challenge priorities. They may push back on requirements. This is not insubordination—it is ownership.
On Sustainability
10. Sustainable pace is not optional.
Overtime is a red flag, not a badge of honor. When deadlines conflict with capacity, we cut scope. We never cut rest. Burnout destroys teams. Recovery is productive. We plan at 80% and leave slack for life.
11. The team's health is the Enabler's responsibility.
Someone must watch for warning signs: maxed WIP, skipped check-ins, overtime patterns, withdrawal. Someone must shield the team from organizational noise. Someone must say "no" to protect "yes."
12. Exploration time is not a reward. It is a requirement.
Twenty percent of time belongs to the maker for learning, tooling, experiments, and interests. No justification required. No approval needed. This is how we stay sharp. This is how we find better ways.
The Framework
The principles above guide us. The framework below implements them.
Roles
We recognize three roles, loosely held:
The Maker builds things. They have full autonomy over implementation. They pull work, propose solutions, review code, and surface blockers. They choose what, how, when, where, and with whom.
The Enabler removes obstacles. They maintain the priority stack, shield from interruptions, monitor wellbeing, and facilitate decisions. They do not dictate—they enable.
The Connector maintains knowledge flow. They keep documentation current, ensure context flows between makers, and onboard new members. This role is optional and may rotate.
Beats
We work in beats—flexible iterations of one to two weeks.
Beats have goals, not commitments. We aim; we do not promise. Beats flow into each other. There is no sprint pressure, no velocity tracking, no burndown theater.
At beat start, we review priorities and pull initial work. During the beat, we check in async daily. At beat close, we reflect: what worked, what didn't, what to improve.
Work Items
Documentation effort scales with task size:
Tasks (hours): A one-liner. No ceremony needed.
Work Items (days): Title, context, done condition. Three lines.
Projects (week+): Half-page doc with breakdown. No more.
We size with S/M/L, not story points. We do not groom. We do not point. We do not track velocity.
Definition of Done
Work is not done until it meets these criteria:
For Code:
- Code works as intended
- Tests pass (existing and new where appropriate)
- Code reviewed by at least one other maker
- Merged to main branch
- Deployable (or deployed, depending on team practice)
- No known defects introduced
For Non-Code:
- Meets the stated "done when" condition
- Reviewed by relevant party if needed
- Documented where others can find it
The team owns this definition. Adjust it as needed. But once agreed, honor it. "Done" means done—not "done but..." or "done except..."
If something is merged but not truly done, it carries hidden cost. Be honest about completeness.
Prioritization
We use four buckets:
NOW — Critical, blocking, time-sensitive. Maximum five items.
NEXT — High value for this beat. An ordered stack. Pull from top.
LATER — Valuable but not urgent. The backlog.
ICEBOX — Someday, or needs more thought. Revisit quarterly.
The Enabler sets the stack. Makers may adjust with reason. Disputes resolve async, then sync if stuck.
The Board
A simple kanban with priority built in:
ICE → LATER → NEXT → IN PROGRESS → DONE
Work-in-progress limit: three per maker. NEXT is ordered. NOW pins to top. Items stale for five days return to backlog.
Meetings
Hard limits:
- Two hours per week total
- One hour maximum per meeting
- Agenda required or meeting cancelled
We hold:
- Beat Start (30 min): Goals, priorities
- Beat Close (30 min): Reflection, health check
- Ad-hoc Help (≤25 min): Unblocking
- Brainstorm (≤1 hr): Creative solving, with 10-minute exit window
If a topic needs more than one hour: write first, comment async, meet on the delta. Never extend.
Daily Check-in
Replace standups with written updates:
Working on: [current task]
Blocked by: [nothing / specific issue]
Post once daily, when convenient. Two minutes. No gathering required.
Collaboration
Default mode is solo deep work.
Help is ad-hoc: post when stuck, someone responds when available, sync briefly if needed, return to solo work.
We do not schedule pairing. We do not mandate walkthroughs. We do not assign buddies. Collaboration is initiated by those who need it.
Multi-Maker Work
Large features require coordination without ceremony:
Break vertically. Each maker owns an end-to-end slice, not a horizontal layer. Slices ship independently.
Define interfaces first. Agree on contracts. Work in parallel against them. Mock until real.
Coordinate via doc. One feature doc serves as source of truth. Makers claim slices, flag blockers, log decisions. Update async.
Sync only when stuck. When async fails, meet briefly. Document outcome. Return to async.
Avoiding Chokepoints
Reviews: Anyone can review. Four-hour response SLA. Auto-proceed after 24 hours if CI passes.
Merges: Merge main daily. Claim files. Keep branches short-lived.
Blockers: Surface in check-in. Pull different work while waiting. Enabler escalates.
Decisions: Post recommendation. Wait 24 hours. No objection means proceed. Dispute means brief sync, then owner decides.
Spotted Issues
When you find something wrong while doing something else:
Blocking your work? Fix now.
Five minutes or less? Fix now.
More than five minutes, not blocking? Log it, continue. Protect your focus.
Production critical? Flag team immediately.
Burnout Prevention
Plan at 80%. Leave room for spotted issues, complexity, life.
Protect exploration time. One day per beat. No justification needed.
Enforce boundaries. No after-hours expectation. Vacation means offline. Mental health days need no explanation.
Monitor health. Every beat close: Did anyone crunch? Is anyone overwhelmed? Are boundaries respected?
Cut scope, not sleep. When deadlines conflict with capacity, the deadline yields or the scope shrinks. Never the person.
Customer & User Feedback
Building in isolation produces irrelevant software. We stay connected to users:
Direct access. Makers should have direct access to user feedback—support tickets, analytics, user interviews. Not filtered through three layers of management.
Regular exposure. At least once per beat, someone on the team reviews real user feedback. Share highlights async.
Fast feedback loops. Ship small. Learn fast. The best specification is user behavior. The best validation is real usage.
User problems, not user solutions. Users tell us what hurts. We decide how to fix it. Listen to the problem; be skeptical of the proposed solution.
Close the loop. When we ship something based on user feedback, tell them. "You asked, we built." This builds trust and invites more feedback.
Incidents & Emergencies
When production breaks, normal rules suspend temporarily:
What qualifies as an incident:
- Users cannot complete critical actions
- Data integrity is at risk
- Security vulnerability is being exploited
- Significant revenue or reputation impact
Incident protocol:
- Alert — Post immediately in dedicated incident channel. Phone/page if needed.
- Acknowledge — Someone claims ownership within 15 minutes.
- Communicate — Brief status updates every 30 minutes until resolved.
- Fix — Stabilize first, perfect later. Rollback is a valid fix.
- Document — Async post-mortem within 48 hours. No blame. Root cause and prevention.
During incidents:
- Sacred blocks are suspended
- Sync communication is acceptable
- Async rules resume once stable
- Whoever is available helps—no "not my job"
After incidents:
- Post-mortem required (async document)
- Focus on systems, not individuals
- Action items tracked and completed
- Share learnings with team
This is not normal work. Incidents should be rare. If they're frequent, that's a systemic problem to solve—not a reason to abandon sustainable pace.
Technical Practices (Optional)
BEAT does not prescribe technical practices. Teams choose what works for them. However, these practices align well with BEAT principles:
Continuous Integration — Merge frequently. Keep main deployable. Automated tests run on every push.
Small Pull Requests — Easier to review, faster to merge, lower risk. Aim for PRs reviewable in under 30 minutes.
Feature Flags — Merge incomplete work safely. Decouple deployment from release. Enable experimentation.
Automated Testing — Tests enable confidence. Confidence enables speed. Coverage targets are team-decided.
Refactoring as You Go — Leave code better than you found it. Small improvements compound. No permission needed.
Trunk-Based Development — Short-lived branches. Merge daily. Avoid long-running feature branches.
These are not mandated. They are offered as practices that support focus, speed, and quality. Adopt what serves you. Discard what doesn't.
Onboarding to BEAT
When someone new joins a BEAT team:
Week One: Observe
- Read this manifesto
- Shadow async check-ins and board activity
- Observe one Beat Start and/or Beat Close
- Get access to tools, repos, docs
- Meet team members 1:1 (async or sync, their preference)
Week Two: Participate
- Pull first small task (S-sized)
- Post first daily check-in
- Submit first PR, experience review process
- Ask questions freely—in channel, not DMs (so others learn too)
Week Three: Contribute
- Pull regular work items
- Participate in Beat Close
- Start taking ad-hoc help requests
- Begin exploration time
First Month Expectations
- Understand the board and priority buckets
- Know how to post check-ins and flag blockers
- Completed several work items end-to-end
- Experienced one full beat cycle
- Identified sacred block timing that works
Connector's Responsibility
The Connector (or Enabler if no Connector) ensures:
- Documentation is current and findable
- New member has a "buddy" for questions (informal, not mandatory pairing)
- First tasks are well-scoped and achievable
- Overwhelm is caught early
What We Don't Do
- Throw new members into complex work immediately
- Expect full productivity in week one
- Leave people to figure it out alone
- Assign mandatory onboarding buddies for months
Onboarding should feel like a gradual ramp, not a firehose or an abandonment.
Anti-Patterns
Common ways teams fail at BEAT:
Process Anti-Patterns
| Anti-Pattern | What It Looks Like | The Fix |
|---|---|---|
| Async theater | Writing decisions but ignoring comments | Genuine engagement or revert to sync |
| Sacred block erosion | "Quick calls" during focus time | Enabler enforces boundaries |
| Check-in decay | Updates become sporadic, then stop | Address in retro, understand why |
| Permanent NOW | Everything is urgent, always | If everything is NOW, nothing is |
| Grooming creep | Meetings sneak back in disguised | Ask: could this be async? |
| Document graveyard | Docs written but never maintained | Connector role, or delete stale docs |
People Anti-Patterns
| Anti-Pattern | What It Looks Like | The Fix |
|---|---|---|
| Hero culture | Same person handles all crises | Rotate, distribute, investigate cause |
| Silent struggle | Maker stuck for days, says nothing | Normalize asking for help early |
| Autonomy hoarding | One maker claims all interesting work | Discuss in retro, Enabler balances |
| Review blocking | PRs languish waiting for "the" reviewer | Anyone can review, auto-proceed rule |
| Passive Enabler | Enabler doesn't shield or prioritize | Role clarity, or rotate role |
Organizational Anti-Patterns
| Anti-Pattern | What It Looks Like | The Fix |
|---|---|---|
| Management override | Exec demands meeting during sacred block | Enabler pushes back, escalates pattern |
| Stealth deadlines | Surprise "we promised client by Friday" | Surface commitments before making them |
| Metric theater | Tracking velocity, points, hours | Stop. Measure outcomes, not activity. |
| BEAT in name only | Ceremonies adopted, principles ignored | Re-read manifesto, recommit or don't claim BEAT |
When BEAT Isn't Working
Signs the methodology isn't serving the team:
- Burnout despite 80% planning
- Decisions taking too long async
- Quality declining
- Team feeling disconnected
- Makers disengaged from beat goals
Response: Discuss in Beat Close. Adapt the framework. BEAT is a tool, not a religion. If it's not working, change it or choose something else.
What We Have Learned
BEAT emerges from research on how developers actually work:
- Developers trend toward introversion and need low-stimulation focus time
- Deep focus requires 52 minutes to reach and 23 minutes to recover from interruption
- More than two meetings per day reduces productive output to 14%
- Peak cognitive work capacity is approximately four hours per day
- 72% of meetings are ineffective at their stated purpose
- Autonomy, competence, and relatedness drive intrinsic motivation
We built BEAT for these realities, not against them.
Where BEAT Fits
BEAT works best for:
- Remote-first or distributed teams
- Senior and mid-level developers
- Product companies
- Teams of 3-8 people
- High-trust environments
- Async-native cultures
BEAT fits poorly for:
- Junior-heavy teams needing close guidance
- Regulated industries requiring ceremony
- Agency work with constant client sync
- Organizations unwilling to protect focus time
BEAT can adapt for:
- Incident response (see Incidents section)
- Mixed seniority (extra onboarding support)
- Larger teams (multiple BEAT teams with coordination layer)
Know your context. Adapt accordingly.
The BEAT Commitment
By adopting BEAT, we commit to:
Protecting focus — We will not interrupt sacred time. We will wait.
Defaulting to async — We will write first, meet only when writing fails.
Trusting makers — We will provide goals, not instructions. Constraints, not control.
Sustaining pace — We will cut scope before we cut rest. We will plan for humans, not machines.
Improving always — We will reflect each beat. We will adjust. We will find better ways.
In Summary
We protect focus.
We write things down.
We trust each other.
We work sustainably.
We ship and learn.
BEAT: Built for how developers actually work.
Appendix: Quick Reference
The Core Values
| We Value More | Over |
|---|---|
| Deep work | Constant availability |
| Async communication | Synchronous meetings |
| Written documentation | Verbal agreements |
| Individual autonomy | Prescribed processes |
| Sustainable pace | Heroic effort |
| Small experiments | Perfect plans |
The Team Values
| Value | Meaning |
|---|---|
| Trust | Assume competence and good intent |
| Courage | Speak up, admit uncertainty, try new things |
| Candor | Honest feedback, surface problems early |
| Ownership | Take responsibility, don't wait to be told |
| Calm | No false urgency, protect each other's focus |
The Numbers
| Constraint | Limit |
|---|---|
| Sacred block | 4 hours daily |
| Meetings per week | ≤2 hours total |
| Meeting duration | ≤1 hour each |
| WIP per maker | 3 items |
| Planning capacity | 80% |
| Exploration time | 20% (1 day/beat) |
| NOW items | Max 3-5 |
| Review response | 4 hours |
| Auto-proceed | 24 hours |
The Buckets
| Bucket | Meaning |
|---|---|
| NOW | Critical, blocking, deadline |
| NEXT | This beat, ordered stack |
| LATER | Future beats |
| ICEBOX | Someday, unclear |
The Roles
| Role | Purpose |
|---|---|
| Maker | Builds with autonomy |
| Enabler | Unblocks and shields |
| Connector | Maintains knowledge (optional) |
The Ceremonies
| Event | Duration | Purpose |
|---|---|---|
| Beat Start | 30 min | Goals, priorities |
| Beat Close | 30 min | Reflection, health |
| Ad-hoc Help | ≤25 min | Unblocking |
| Brainstorm | ≤1 hr | Creative solving |
Definition of Done
Code:
✓ Works as intended
✓ Tests pass
✓ Code reviewed
✓ Merged to main
✓ Deployable
✓ No known defects
Daily Check-in Template
Working on: [task]
Blocked by: [nothing / issue]
Spotted Issue Decision
Blocking? → Fix now
≤5 min? → Fix now
>5 min? → Log it, continue
Critical? → Flag team
Incident Protocol
1. Alert (immediately)
2. Acknowledge (15 min)
3. Communicate (every 30 min)
4. Fix (stabilize first)
5. Document (within 48 hrs)
License
This manifesto is open for use and adaptation.
Attribution appreciated. Improvement welcomed. Dogma discouraged.
BEAT v1.0