The Team of One

Last October I published a piece on how teams collaborate inside BeMo. I've been going back through the record I put out while we were building, checking each claim against what the beta has taught since. The last edition was about memory that stays where it's stored instead of showing up in the work. This one is about who I thought was in the room.

What I claimed

The original piece argued that collaboration is not people typing in the same file at the same time. That "looks like teamwork," I wrote, "but it's not continuity." The real problem was keeping a shared understanding alive after the meeting ends: "the real challenge isn't getting everyone into the same file. It's keeping everyone in the same understanding."

I stand by that. I just pictured "everyone" as a group. In a lot of the organizations we serve, everyone is one person.

I illustrated the idea with a scenario. A maternal-health initiative moves through BeMo: the development director finds funders, the strategy lead refines the impact goals, the communications director drafts the posts, the volunteer coordinator builds the training. Four people, four roles, one shared thread, each picking up the reasoning where the last one set it down. The architecture followed from that picture: a shared conversation everyone could join, document threads anyone could read, memory that keeps a team in sync.

Who's actually in the room

A lot of the time, there is no second person.

Plenty of the organizations we build with do have a few people, and that case is real. But a large share of them do not have a development director and a separate strategy lead and a separate communications director. They have a person. One person who is the development director on Monday, the strategy lead on Tuesday afternoon, the communications director the night the newsletter goes out, and the volunteer coordinator on the weekend. The four roles in my scenario were real. The four people often were not. It was one person wearing four hats, switching between them under deadline.

I had not designed for that. I had designed as if the team were the default and the solo operator a stripped-down version of it, the same system with fewer seats filled. The beta said otherwise often enough to matter: the person doing all four jobs is not a smaller team. She is her own case, and she is a large part of who we serve.

So there are two problems, not one, and I had folded the second into the first without noticing. There is continuity between people: keep several heads in one understanding. And there is continuity inside one head, across time: keep the same person in one understanding when she closes the laptop on Tuesday and opens it again on Friday as a different function of the same job. The handoff is sometimes between teammates. Just as often it is between Tuesday's version of her and Friday's.

The mechanism of the miss

Here is the uncomfortable part. The two problems look similar enough on a whiteboard that I never noticed I had collapsed them into one. Both need shared memory. Both need a thread that persists. So I built the version that sounded harder, several people held in one understanding, and assumed the single-person case was the same thing with fewer participants.

It is not the same thing. Designing only for the team optimizes for the wrong gap. Between people, the gap you close is who knows what right now: bring the new joiner up to speed, kill the version drift, stop repeating the same explanation. Within one person across time, the gap is what did I decide, and why, three days and four context-switches ago, with nobody who happened to overhear it. Without a record of it, she does not resume, she restarts. A team can reconstruct a lost decision by asking each other. A person who is the whole team has no one to ask. The system is the only thing that was in the room both times.

That second case is the one I had underbuilt. When the org chart is one person, continuity is not a convenience that keeps a group aligned. It is the only place the reasoning is held at all. The fewer people in the room, the more the system has to carry, not less.

What changed

The delta is simple to say and was not simple to see: continuity between people and continuity inside one person over time are two problems, and I had built only the first. So the design target became both. We kept building the shared thread for teams, and we started grading it on the second question we had been treating as automatic: how well it holds one person's reasoning across the days between sessions. Does it come back briefed. Does it hold what was decided and why. Does it carry Tuesday's thinking into Friday without being asked to explain the whole thing again.

None of the team features got thrown out. Organizations with real teams exist, they are a core part of who we build for, and the solo users we serve now will fill more seats as they grow. The correction was not swapping one unit for another. It was refusing to treat the smaller unit as a byproduct of the larger one, because it turns out to be the harder problem and a large share of the work. Get continuity right for the person who is the entire team, and the team of four is mostly a case you have already solved. Solve only for four, and the person of one falls through the gaps between the seats.

The claim I would write today is wider than the one from last October, not narrower. Collaboration is keeping people in the same understanding. It is also keeping one person in the same understanding as herself, across time, and that second half is not a smaller version of the first.