How to keep a team of five aligned without meetings

A team of five can feel busier than a team of fifty. Everyone talks to everyone. A decision made in a hallway on Tuesday is gone by Thursday, and someone redoes work that was already finished. The usual fix is a meeting, and then more meetings. A meeting is a way of putting everyone in the same place so the same facts sit in every head at once. It works, briefly, and then the facts leak out again.

The real problem is not communication. It is memory. A meeting is an expensive and temporary form of memory. The cheaper and more durable form is writing things down in a place that does not forget. Once the shared facts live somewhere stable, most of the standing meetings have nothing left to do.

This article is about two questions. What has to be written down, and where it has to live. Get those right and a team of five can stay aligned with almost no meetings at all.

Why writing beats talking for a small team

Talking is fast, but it does not carry across time. The person who was not in the room, the person who joins next month, and the you of six weeks from now all need the same facts, and none of them were there. Writing serves all of them at once. It also forces a kind of honesty: a decision you cannot state in two sentences is usually a decision you have not finished making.

There is a second benefit that is easy to miss. When the shared record is open, people correct it. A wrong number sits in the open until someone who knows better fixes it. Government digital teams put this plainly as a working principle — share what you are doing: code, designs, ideas, intentions, even failures. [1]

What has to be written down

Not everything. A log of every message would be as useless as no record at all. Three kinds of thing earn their place.

Decisions, with the reason

Record the decision and the reason behind it, in that order. The reason matters more than the decision itself, because six months later someone will want to change it, and without the reason they cannot tell whether the ground has actually shifted. "We bill monthly, not annually, because our customers asked for smaller payments" is a sentence you can revisit. "We bill monthly" is not.

Keep it short. One line for the decision, one or two for why, the date, and who decided. That is enough.

How recurring work gets done

Anything that happens more than a few times should be written as a short procedure: the steps, in order, that a person follows to get a known result. In operations this is an old idea — a written compilation of routine procedures that the person on duty carries out, so the result does not depend on who is on duty that day. [2] For a small business it might be how you onboard a new customer, how you close the month, or how you handle a refund. The test is simple. If the only person who knows how to do it is on holiday, the work stops. Write it down before that happens.

The current state of things

Who owns which customer. What stage each deal is at. Which tasks are open and who holds them. This is the part a meeting is usually called to recover, and it is the part that goes stale fastest. It should never live in one person's head or in a thread. Keeping a customer record accurate is a habit more than a one-off task, and a shared system is only as good as that habit — a point we have made before about CRMs in why your CRM is only as good as your habits.

Where it has to live

The content matters, but the location decides whether any of it survives. Four rules make a location work.

One place, not several. The single most useful property of a shared record is that there is exactly one of it. In data management this is called a single source of truth: every data element is mastered, or edited, in only one place, and everything that needs it points back there rather than keeping its own copy. [3] The moment the same fact lives in two documents, they drift, and you are back to calling a meeting to find out which is right.

Reachable by everyone who needs it, without asking. If a person has to request access, or chase someone for the link, the record is not really shared. A record all five people can see without friction beats a tidier one behind a gate.

It keeps a history. You want to see what a thing said last week, and who changed it. A record with no history cannot settle an argument; it can only show the present, which is the very thing in dispute. The quiet value of a change log is something we covered in the audit trail nobody thinks about.

It is where the work already happens. A record you have to leave your tools to update will not get updated. If your customers live in one system, your decisions in a separate document, and your procedures in a third, you have three places to keep in sync and no one will. The fewer the places, the truer they stay.

This is where a connected system earns its keep. In 360REV the customer records, the notes on each decision, and the history of who changed what sit in the same place the team already works, so keeping them current is part of the job rather than a separate chore. That is the whole of the product's role here: a tool can hold the record, but it cannot decide what you write in it.

The habit that keeps it true

Written records rot without a habit. The habit is small: when a decision is made, write it down the same day; when a procedure changes, change the document in the same hour, not next week. A record that is usually right but sometimes stale is worse than no record, because people stop trusting it and go back to asking.

For a team of five, that is the entire system. A single place everyone can reach. Three things written in it — decisions with reasons, procedures, and the current state. One habit of updating it as the work happens. The standing meeting that survives all this is the one about judgement, not facts, and those are rare and worth having. The rest you will not miss.

If you are still deciding what belongs in a customer record in the first place, that is worth settling before anything else; we wrote about it in recording why a customer leaves.