Meetings, async work and decision records for a small team
How a small team can decide which conversations need a meeting, what to write instead, and how to keep a decision record, using the Scrum Guide and GOV.UK.
General information, not management or legal advice. Written October 10, 2026. This article describes practices and sources. It does not promise that any practice will improve a team’s results.
A team of four people in three time zones can lose a day to a meeting that could have been a paragraph, and lose a week to a decision that nobody wrote down. Both losses are quiet. The meeting looks productive and the decision seems settled until someone asks what was decided and why.
This article is about three habits that work together. Decide which conversations deserve a meeting. Move the rest to writing. Keep a short record of the decisions that matter. It leans on two public documents, one describing a meeting cadence and one describing a decision record, and it treats everything else as a design you can change.
Start with what a meeting is for
A meeting is the most expensive way to move information, because it takes everyone’s attention at the same moment. It earns that cost when the conversation is hard to hold in writing: a disagreement where tone matters, a problem where people need to think out loud together, a decision that needs many voices quickly. Reading a status update does not need a meeting, and neither does reporting a result.
A useful test is to ask, for any recurring meeting, what would be lost if it became a written note. If the answer is “nothing much”, the meeting is a note in disguise. If the answer is “the argument”, the meeting is doing real work. The same test can be run on a one-off call before you send the invitation. It also helps to name the one outcome the meeting is meant to produce, such as a choice between two options, and to end it when that outcome exists.
What the Scrum Guide says about regular events
The Scrum Guide is a description of a team framework, and a small team can borrow a single idea without adopting the rest. The guide says “Events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum.” The aim is that a few regular events replace many ad hoc ones. It also gives events fixed durations. It says “The Daily Scrum is a 15-minute event for the Developers of the Scrum Team.” and “Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint.”
What a founder can take from this is a principle, not a prescription. A meeting with a fixed time limit and a stated purpose is easier to run than an open one, and a small set of regular meetings can reduce the number of extra calls. The guide’s figures are for its own events, on a team that works in Sprints, and are not targets for yours. Whether your team needs a daily check-in at all depends on how it works, and a team spread across time zones may find that a written update does the same job.
Moving work to writing
Asynchronous work means that people contribute at different times and do not wait for one another. It does not mean silence. It means that the useful content of a conversation is written so that a person who was asleep when it started can read it and add to it. These practices tend to help, and each is a design choice, not a rule from a source.
| Practice | What it does | A question to test it |
|---|---|---|
| State the question first | Lets a reader decide whether it concerns them | Can someone tell from the first line what is being asked? |
| Say what you need, from whom and by when | Replaces a vague message with a request | Does each person named know their part? |
| Put the context in the message | Avoids a chain of questions to reconstruct it | Could a new colleague act on this without asking? |
| Keep one place for each kind of conversation | Prevents decisions from scattering across channels | Where would someone look for the last decision about pricing? |
| Agree what counts as urgent | Keeps an interruption for the cases that need it | Does everyone share the same meaning of urgent? |
For a team across several countries, add questions about the working day. Which hours overlap for everyone, and is that overlap spent on the conversations that need it? Who is expected to be reachable when, and who has agreed to that? When one person is asked for an answer outside their working hours, is that a rare exception or a habit? Those are decisions for the team to make and write down, and the team handbook article covers where they can live. An operating rhythm for a remote offshore team describes a cadence for a distributed team.
Why write a decision down
A decision made in a meeting is a decision that exists only in the memory of the people who were there. A month later, they remember it differently, or a new person asks why the team did it that way, and the answer is a shrug. The cost is not only confusion. A team that cannot find an earlier decision tends to make it again.
A decision record is a short document that captures the choice and the reasoning. The UK government’s Architectural Decision Record framework describes the kind it has in mind: “An ADR is a formal document used to capture significant architectural decisions.” The framework says each record should contain a title, a date, a status, a context, the decision, the consequences, the stakeholders consulted and links to supporting documents. It says the record “provides a record of the decision-making process”, and that a team should “Regularly review and update the ADR” so that it remains useful.
The framework is about architecture decisions in government digital services, and a small company will choose its own scale. A one-paragraph record for a pricing change is the same idea at a smaller size. The useful features carry over: the context says what prompted the choice, the decision says what was chosen, the consequences say what the team expects and the status says whether the decision still stands.
| Field | What to write | Example for a pricing change |
|---|---|---|
| Title and date | A short name and the day it was decided | Move annual plans to a single price, with the date |
| Status | Proposed, accepted, replaced or withdrawn | Accepted |
| Context | What prompted the question and what constrained it | Customers asked for a simpler page and support kept explaining the tiers |
| Decision | The choice, in a sentence | One annual price replaces two annual tiers |
| Consequences | What the team expects, good and bad, and what to check later | Fewer questions to support, less choice for customers, review at the next quarter |
| Who was consulted | The people whose view was asked for | The two founders and the person handling support |
Keep records in one place the whole team can search, and write them at the time of the decision. A record written months afterward is a story about the decision. If a record is later replaced, mark it replaced and link to the new one, and do not edit the old one in place.
A decision, from question to record. The same four moves work for a meeting and for a written thread. What changes is where the discussion happens.
-
Write the question
State the decision in one sentence and name who will make it.
-
Collect views in writing
Give people a set time to add facts, options and objections before anyone talks.
-
Decide and say why
The named person decides and writes the reasoning in two or three sentences.
-
File the record
Store the decision with its date where the whole team can find it later.
What to bring together in a week
These habits fit together. A short, regular meeting handles what needs voices in a room. Written updates handle the rest. A decision record keeps what was settled. A founder can fold the three into the weekly pattern in a weekly operating rhythm for a founder, and a team with a product to ship can see how decisions feed a plan in product management for a first SaaS. Decision records are also what you point to when two people remember a choice differently, which is one reason they help in working through a disagreement with a co-founder.
The glossary defines shared terms.
Where this fits in a long effort
A decision record costs a few minutes and saves the team from reopening the same question in a year. For a company expecting to last, the archive of past decisions is a form of memory that survives staff changes. The weekly operating rhythm article shows where a decision review fits in the week, and the how WE works page describes WE’s own practice. The longevity paradox article explains why a written record matters most in the later years of a company.
Other founders are often the best test of a decision-record format. The founder communities in the ecosystem directory are independent groups where small teams compare how they run their weeks.
What this article cannot tell you
This article cannot tell you how many meetings your team needs or which tools to use. It rests on the Scrum Guide and one GOV.UK framework, both read on October 10, 2026. The Scrum Guide is written for teams that work in Sprints, and the GOV.UK framework is written for architecture decisions in government digital services, so the examples and the pricing record are this article’s own scaling. It does not cover meeting tools, time-zone law, working-time rules or the legal weight of a record, and it makes no claim about productivity. Ask counsel if a decision record may matter in a legal dispute.
In the data
These figures describe U.S. businesses in general, not WE’s results. Each one names its source.
Show the data as a table
| Age group | Median tenure |
|---|---|
| Ages 20 to 24 | 1.5 years |
| Ages 25 to 34 | 3.0 years |
| Ages 35 to 44 | 4.7 years |
| Ages 45 to 54 | 7.0 years |
| Ages 55 to 64 | 9.6 years |
| Ages 65 and over | 9.9 years |
| All workers 16 and over | 4.1 years |
Wage and salary workers only; tenure is time with the current employer, not in the current job.
Source: U.S. Bureau of Labor Statistics, Employee Tenure, Table 1 , January 2026
Retrieved 2026-10-16. Values are the published medians for both sexes, copied as printed.
Sources
- The Scrum Guide, Scrum Guides (Ken Schwaber and Jeff Sutherland) . Accessed October 10, 2026.
- Architectural Decision Record framework, GOV.UK . Accessed October 10, 2026.
Spotted an error? Read how we handle corrections in our editorial policy.