The board changes every two years: keeping continuity

What gets lost is not what you expect

When the statutes set a two year term, the association lives with a clock it rarely looks at. On the day, the outgoing board hands over what it knows how to hand over: the statutes, the last accounts, the membership file, sometimes a folder. All of it is useful, and all of it was already written down. The problem was never the existing documentation, it lies elsewhere.

What gets lost is everything that never needed to be written down while the same person was there. The address the platform account is attached to. The name of the person at the town hall who picks up the phone. The reason the association walked away from a partnership eighteen months ago. The fact that one member's dues were suspended for a personal situation nobody else needs to know about, which the new treasurer will chase up because nobody told them.

This information is not confidential, it is tacit. It worked because one person carried it. The day that person leaves, it does not become unavailable: it becomes invisible, which is worse, because the incoming board does not even know it existed. So it does not ask, and rediscovers the problem a few months later, treating it as a new one.

The most expensive consequence is not the loss of information. It is the restart. A board that inherits an association whose state it does not understand redoes what had already been done, reopens settled debates, and spends its first year reconstructing what its predecessor knew. On a two year term, a year of reconstruction leaves one useful year.

The four assets a board holds without thinking about them

Preparing a handover gets easier once you stop asking which documents to pass on and start looking at what the board actually holds. It falls into four blocks, of which usually only one is handed over.

• Access. Everything that needs a login and a password: the platform, the bank, the association's mailbox, the domain name, the public accounts, the accounting tool. It is the easiest block to inventory and the one most often forgotten, because each access was created one day, by one person, with no thought for what came next.
• The memory of decisions. Not the decisions themselves, which are in the minutes, but their reasons. A decision without its reason gets replayed at the first opportunity, and the incoming board reruns the debate without knowing that it is rerunning it.
• External relationships. The consulate, the local authority, the partner school, the supplier, the sponsor. An institutional relationship is not handed over through an email address: it is handed over through an introduction, and its state, warm, tense or dormant, matters as much as the contact's name.
• Member data. The file, its update rules, what members agreed to when they signed up, and what the association committed not to do. It is the only block that is both an asset and a legal responsibility, and the only one that survives poorly when it travels as an email attachment.

A board that hands over all four has done its job. A board that hands over only one, usually the membership file, leaves its successor in front of an association whose member list it has but whose keys it does not.

The personal account, the most common breakdown

The story repeats itself with a regularity that is not anecdotal. The association starts, someone creates the first account, and since no association address exists yet, they use their own. That account becomes the administrator account. Two years later, that person leaves the board. Sometimes they leave the country. Sometimes they stay, keep the access, and end up having to step in for an association they no longer run, which is uncomfortable for everyone.

The same pattern repeats on every channel opened along the way: the group chat created from a personal phone number, the public account opened with a personal address, the domain name bought on a personal account and renewed from a personal card. As long as the person is around, none of it shows. The day they leave, every access becomes a negotiation.

The answer is not to stop volunteers using their own tools. It is to separate two things that the rush of the early days had merged: the identity of the person, which belongs to them, and the function they hold, which belongs to the association. The person keeps their account and their address. The function must be removable from one person and grantable to another without any password changing hands.

Roles, not people

That is exactly what role based permissions do. Every board member has their own account, under their own name and address. That account grants nothing in itself: permissions come from the role attached to it, president, treasurer, secretary, group owner, local chapter lead. The role describes what the function is allowed to do, and the role transfers.

This changes three things on handover day. First, the handover becomes a few minutes of work: one role removed, another granted, no password communicated. Second, it becomes reversible without damage: a role granted by mistake can be removed, whereas a shared password cannot be taken back. Third, it becomes auditable: at any moment the association can show who holds which role, a question members rarely ask and funders sometimes do.

It also changes something day to day, outside any handover. A board with a single shared administrator account cannot delegate: either it grants full access or it grants nothing. The usual consequence is that the president does tasks they could have handed off, and gradually becomes the only person who knows how to do them. Concentrated permissions produce concentrated knowledge, and it is that concentration that makes the handover hard two years later.

One principle settles the edge cases: no access should depend on the goodwill of someone who no longer holds office. If removing an access requires a person to cooperate, the association does not hold that access, it borrows it.

The data belongs to the association, not to its board or its tool

The membership file is the one asset a diaspora association cannot rebuild. Statutes can be found again, accounts can be redone, an institutional relationship can be revived. A base of several hundred people gathered over years, with up to date contact details and their consent, cannot be rebuilt: you would have to ask each of them again, and many would not answer a second time.

That ownership has to be verifiable, otherwise it is only a form of words. Verifying it comes down to one question put to the tool you use: can the association obtain, whenever it decides and without going through a third party, a usable export of its directory, its memberships and its events? A usable export is one you can open, read and import elsewhere, not a printout as an image. We go through the questions to ask and the wording traps in data reversibility on a community platform.

The practical test is simpler still: run the export once, before you need it. An export that has never been run is a promise, not a guarantee, and the handover is a good moment to run it since the resulting file belongs in the handover file. It serves two purposes there: it proves the association holds its data, and it gives the incoming board a dated snapshot of what it is inheriting.

That export calls for one precaution, in a single sentence. A directory file is a file of personal data: it does not travel through personal email, it is not kept on a private computer after the end of a term, and it is deleted on the outgoing board's side once the handover is done. Continuity is not about multiplying copies, it is about guaranteeing that one copy stays available to whoever is in office.

The blind spot: everything that lives outside the platform

An association that has looked after its platform can still lose the essentials at handover, because part of its life happens elsewhere. The messaging group where the real decisions are made, the spreadsheet shared from a private account, the mailing list kept by hand in a mailbox. Those tools have no role management, and they have no transfer button.

The informal group chat deserves particular attention, because it is useful and it has no replacement. It belongs to whoever created it, its memory cannot be searched, and nothing guarantees that a new board will be granted its administration. The sensible split between the informal channel and the platform, and what each should carry, is covered in its own article: WhatsApp group or diaspora platform. From a handover point of view, one rule matters: nothing that must outlive the term should live only in a chat thread.

The same vigilance applies to the activity report. A board that produces a written report every year for its general meeting leaves behind a series of documents that tell the association's story better than any handover file, because they are dated and they were approved. We describe how to structure one in preparing a diaspora association's activity report. An association that has kept one across several terms has almost no memory problem left.

The handover file, and what it actually contains

A useful handover file is short. Long files do not get read, and an incoming board that receives sixty pages reads three. Four parts are enough, each one or two pages long.

• The inventory of accesses. For each service: what it is for, which role holds it, who handles its renewal and when. The last column matters most, because a domain name or a subscription expiring without anyone noticing is the most ordinary failure of an association in transition.
• Ongoing matters. What is committed and unfinished, with a deadline and a name. A grant application filed, an agreement to sign, a reimbursement pending, a dispute. Three lines per matter is enough, provided none is missing.
• External relationships. Name, position, two sentences of history, and the state of the relationship. This part is the most uncomfortable to write, because it forces you to put in writing things usually said out loud. It is also the one that saves the next board the most time.
• The state of the data. How many members are up to date, the date of the last export, what members agreed to at sign up, and the commitments made about the use of their data. If the association has no reliable census, this is the moment to say so rather than let it be discovered. The subject has its own article: how to map your diaspora.

This file is written during the term, not at its end. A board that keeps its access inventory current as it goes has nothing to write on handover day, only something to reread. A board that discovers the exercise the night before the general meeting will produce an incomplete document, and the gaps will be exactly what the outgoing president found obvious.

Preparing a handover in eight steps

1. Inventory every access. List everything that requires a login, service by service, and note which address each is attached to. The list is almost always longer than expected, and that is the only useful output of this step.
2. Replace shared accounts with named accounts. Every board member has their own, under their own name. A shared account cannot be revoked, only worked around.
3. Write the map of roles. Who holds which role, what that role allows, who grants it and who can remove it. One page is enough, and that page counts as a decision: it should be approved by the board, not drafted by one person.
4. Move memory out of personal mailboxes. Anything that commits the association belongs in a space owned by the association. Decisions and their reasons, agreements, exchanges with institutions.
5. Run the export once, for real. Directory, memberships, events. Open the resulting file and check that it is readable. An untested export does not count.
6. Write the handover file before the general meeting. While the outgoing board is still in office and still remembers. Four parts, a few pages.
7. Organise an overlap period. A window during which the outgoing and incoming boards talk, with questions written in advance rather than an improvised call on a Sunday evening. That window has an end, and the end is announced.
8. Remove the old permissions on a fixed date. Decide that date on handover day and record it in the minutes. An access you forget to revoke is not a gesture of trust, it is an oversight that will eventually cause a problem for the person themselves.

None of these steps needs a particular tool, and most fit into one board morning. What makes them hard is not their complexity, it is that they happen at the moment when nobody has a short term interest in them: the outgoing board is tired, the incoming board does not yet know what to ask.

When a light handover is enough

Everything above describes an association that holds assets worth transmitting. Many are not there yet, and for them formalising costs more than it returns. Three situations call for the opposite of this article.

• The association has just been created. A structure a few months old has neither established relationships nor old decisions, and its board is made of the same people who founded it. Writing a handover file means writing down what everyone has just lived through. The access inventory, however, is worth keeping from day one, because it is easier to maintain than to reconstruct.
• The board is renewed in thirds. When the statutes organise partial renewal, continuity is provided by the structure itself: there is always someone who knows. The handover file becomes a short note for the newcomer, and the effort shifts to individual onboarding rather than documentation.
• The association has one tool and no sensitive data. A community that keeps a directory and nothing else, with no dues, no institutional relationship and no ongoing commitment, holds one asset out of four. Applying the full procedure produces an empty document, and an empty document discredits the exercise for next time.

The test fits in one question, put to the outgoing president: if you were unreachable for a month, what would stop? If the answer is nothing, the handover will be light. If the answer includes a domain name, an institutional relationship or bank access, it names exactly what needs to be written down, and nothing more needs writing.

In short

Method and sources. This is a method article: it relies on no external source and puts forward no market figure. What it describes comes from field observation with diaspora and alumni associations, not from measurement. We deliberately publish no data on the turnover of association boards, no average term length and no proportion of associations affected by the difficulties described here: these situations are frequent in what we observe, which is not a measurement and should not be read as one. The only figures mentioned are Terrilink's public prices, and module availability follows the plan matrix: the directory, the news feed and messaging are included in every plan; the events calendar, discussion groups, the map and membership management are included from the Pro plan upwards. Roles and permissions are part of the platform and are not a separate module. The governance questions raised here, in particular term length, board renewal and the content of minutes, depend on your own statutes and call for your own analysis, with professional advice where appropriate.