Ask a PTO president what the hardest month of the year is and most of them will not say October, when the fall festival lands. They will say July. July is when the new board takes over, and July is when everything the old board knew quietly stops being known.

It looks like a fresh start. New officers, new energy, a clean budget. But underneath the optimism is a small disaster that repeats every single year: the institutional memory of the organization just walked out the door, and almost none of it was written down.

Turnover is the design constraint, not the exception

Most software is built for organizations with continuity. The people who configure the tool in year one are mostly still around in year two. They remember why the categories are named what they’re named, why one family is exempt, why the carnival uses a different point value than the book fair.

Parent organizations do not have that continuity. By design, the board turns over — frequently the whole slate at once. A two-year term feels long. A treasurer who lasts three years is a local legend. The natural state of a PTO is that nobody in the room next August was in the room last August.

The handoff is not an edge case you patch later. It is the central thing the organization does, every year, forever.

Once you see turnover as the main event rather than an interruption, a lot of otherwise-puzzling failures suddenly make sense.

What actually gets lost

When people say “we start over every July,” they rarely mean the obvious stuff. The bank balance carries over. The 501(c)(3) status carries over. The Facebook group carries over.

What gets lost is the unwritten layer:

  • The exceptions. Which families are exempt, and why. Who gets a hardship waiver. Which committee chair negotiated out of the hour requirement three presidents ago.
  • The reasons. Not “the carnival is worth 4 points” but why it’s worth 4 points and the book fair is worth 2.
  • The relationships. Which local print shop gives the discount. Which parent will always say yes to running the bake sale if you ask in person.
  • The near-misses. The thing that went wrong last year and the workaround that quietly fixed it.

None of this lives in the budget. Most of it lives in one outgoing officer’s head and a folder of emails she’s about to stop checking.

The three ways tools make it worse

Software is supposed to help here. Usually it makes the handoff harder, in three predictable ways.

1. The knowledge moves into the tool, then the tool’s login leaves with the person

The outgoing treasurer set up the volunteer-tracking tool. It’s tied to her personal email. She graduates her youngest, moves on, and stops responding. Now the configuration exists, the data exists, and nobody can get in. The new board does the rational thing: they start a new spreadsheet. The tool’s careful setup is dead weight.

2. The tool assumes the configurer remembers the configuration

Plenty of tools are perfectly usable if you already know how they were set up. The exemption rules, the point values, the category logic — all editable, all sensible, all completely opaque to someone seeing them cold. The new treasurer opens the dashboard, sees forty rules she didn’t write, and has no way to learn the intent behind any of them. So she doesn’t trust them. So she rebuilds.

3. The tool has no concept of “the reason”

This is the deep one. Most tools store what happened — this family owes 20 hours, this one paid a buyout — but not why a decision was made. When the why isn’t a first-class field, it ends up in a comment cell, an email, or a memory. All three evaporate at handoff.

What “surviving the handoff” actually requires

A parent-org tool that survives July has to treat the new president as its primary user — someone who has never seen the product, inherited it under duress, and has about a week of patience before she reaches for a spreadsheet.

Concretely, that means a few things.

Ownership belongs to the organization, not a person. Access is granted by role, not by who happened to set it up. When the treasurer changes, the new treasurer inherits the treasurer’s access automatically. No one is ever locked out because a person left.

Configuration is legible. Every rule — exemptions, point values, deadlines, conversion rates — is visible in plain language inside the product, with a short note on why it exists. Not in the implementer’s inbox. Not in tribal memory.

Reasons are typed, not free-text. When a family is exempted, the exemption carries a structured reason, an approver, and an effective date range. Next year’s treasurer reads the why before she sends the “you’re short on hours” letter — and avoids the apology email that always follows.

There is an actual handoff view. A page the outgoing board walks through with the incoming board: here are your open items, here’s what’s configured, here’s what’s unusual about your school. Turning the tribal knowledge transfer into a checklist instead of a coffee that never gets scheduled.

A small ritual that helps even without software

If you take nothing else from this: institute a written handoff, and make it boring.

Before the old board dissolves, have each officer fill in three things — what they did, what’s currently in flight, and the one weird thing their successor needs to know. A single shared doc. Thirty minutes per person. It is astonishing how rarely this happens and how much grief it prevents.

The goal is not a perfect manual. The goal is that the new treasurer’s first week is spent doing the job, not reverse-engineering it.

Why we built around this

When we started Lumicura, we expected the hard part to be tracking volunteer hours. It wasn’t. The hard part — the thing that quietly kills parent-org tools — is that the organization forgets itself every summer.

So we made the handoff the spine of the product. Access follows roles. Configuration is readable. Every exception carries its reason. And there’s a handoff view built for the exact moment a stunned new president logs in for the first time in July, wondering what she signed up for.

You can’t stop the board from turning over. You shouldn’t want to — fresh energy is the whole point of a volunteer organization. What you can stop is the organization losing its memory every time the people change. That’s a software problem with a software answer, and it’s the one we set out to solve.

If your board has a July problem, we’d like to hear how it shows up at your school. Email hello@lumicura.org — we’re collecting these, and every conversation has sharpened what we build.

Filed under: Boards & handoffs. If you'd like one of these in your inbox monthly, subscribe to Field notes.