At a school, almost nothing about “who can see what” is written down. The treasurer can see the buyout amounts because she’s the treasurer and everyone trusts her. The room parent knows which families are behind on hours because she’s been around forever. The principal sees the totals when she asks. None of this is documented. It runs entirely on social trust.
Then you put it in software, and software demands an answer to a question the school never had to answer out loud: exactly who can see exactly what? That question is sharper than any agreement the school ever made — and the gap between the two is where new board members get blindsided.
Social trust is fuzzy on purpose
The unwritten system at a school works because it’s fuzzy. Access is granted informally, scoped vaguely, and adjusted by feel. The longtime volunteer coordinator can see more than her title strictly implies, because she’s earned it. A new committee chair sees less until she’s proven reliable. Nobody signs anything.
This fuzziness isn’t sloppiness — it’s a feature. It lets a small community handle sensitive information with judgment instead of rules. The treasurer knows not to mention the Hendersons’ hardship exemption at the PTA meeting. Everybody knows who’s discreet. The system bends.
Social trust scales down beautifully and scales up terribly. It works for forty families who know each other and falls apart at four hundred who don’t.
The trouble is that software can’t be fuzzy. It has to render every implicit understanding into an explicit rule, and that act of rendering forces uncomfortable specificity.
Software forces the awkward questions
The moment you configure permissions in a tool, you have to answer questions the school politely avoided:
- Can the volunteer coordinator see dollar amounts on buyouts, or only hour totals?
- Can a committee chair see the contributions of families outside her committee?
- Can the president see hardship-exemption reasons, or just that an exemption exists?
- Can a family see anyone’s ledger but their own?
- When a board member’s term ends, when exactly does her access stop?
Every one of these was previously answered by vibe. Now someone has to pick. And picking surfaces disagreements that the fuzziness had kept buried — like the fact that two longtime volunteers had quietly assumed opposite answers for years and never had to find out.
The two failure modes
When the gap between social trust and software permissions isn’t handled deliberately, organizations fall into one of two traps.
Too open
The easy path is to give everyone on the board access to everything. It feels collegial and avoids the awkward conversations. But “everything” now includes hardship exemptions, buyout amounts, and which families are behind — the most sensitive data the organization holds. In the fuzzy social system, that information was protected by discretion and proximity. In the software, it’s protected by nothing, and it’s one screen-share away from being seen by people who were never meant to see it.
New board members are routinely surprised by this. They expected the tool to encode the discretion they’d absorbed socially. Instead it handed them the keys to everything and trusted them to look away.
Too locked down
The overcorrection is just as bad. Scared of the sensitivity, an admin locks everything to a single role. Now the volunteer coordinator can’t see the sign-ups she’s supposed to manage, the committee chair can’t credit her own volunteers, and everyone routes every request through one overloaded person. The fuzzy system let many hands do many jobs; the over-locked system funnels everything to one. Within a month, people are working around the tool — sharing logins, exporting spreadsheets — and the careful permissions are theater.
What good permission design looks like here
Designing access for a school is not the same as designing it for a company. The right model takes the social reality seriously instead of fighting it.
Roles, not people. Access attaches to treasurer, president, committee chair — not to a person’s email. When the treasurer changes, the new treasurer inherits exactly the treasurer’s view, and the old one loses it. This is the single most important thing for surviving turnover, and the thing informal systems do worst.
Sensitivity tiers, made explicit. Not all data is equal. “This family has an exemption” is different from “this family’s exemption is for a medical hardship.” A good system lets you grant the existence of an exemption broadly while keeping the reason tight. The school always knew this distinction socially; the software should let you encode it.
Scope by committee. A committee chair should see her committee’s contributions, not the whole school’s. Scoping access to the part of the organization a person actually runs matches how the work is really divided.
Visible, not buried. A new board member should be able to see, in plain language, what each role can access — so the rules that used to live in tribal knowledge are now legible to someone who arrived last week.
A clean end. When a term ends, access ends with it, automatically. No lingering logins, no “I should probably remove her at some point.” The most common real-world security failure at a parent org is not a breach — it’s the past treasurer who can still see everything two years later.
The goal isn’t to be stricter than the social system. It’s to make the social system’s good judgment survive the people who exercised it.
The conversation worth having
Here’s the practical advice, software or not. Before you configure anything, get the board to answer a few questions out loud:
- What’s the most sensitive thing we track? (Usually: hardship-exemption reasons and dollar amounts.)
- Who genuinely needs to see it to do their job — and who’s just used to seeing it?
- What should a committee chair see beyond her own committee? (Often: nothing.)
- The day a board member’s term ends, what should she still be able to see? (Almost always: only her own family.)
These are uncomfortable conversations precisely because the social system was built to avoid them. But having them once, explicitly, is far less painful than discovering the disagreement live, after someone saw something they shouldn’t have.
Why we designed it this way
When we built permissions into Lumicura, we started from the school’s social reality rather than a generic corporate model. Access follows roles, so it survives July. Sensitivity is tiered, so you can share that an exemption exists without exposing why. Committee chairs are scoped to their committees. Every role’s access is visible in plain language to whoever inherits it. And when a term ends, access ends cleanly.
The aim isn’t to replace the school’s good judgment with rigid rules. It’s to take the discretion that lived in a few trusted people’s heads — the discretion that used to walk out the door every summer — and make it part of the system, so the next board inherits the judgment along with the job.
If your board has run into the awkward gap between trust and permissions, we’d like to hear how it showed up. Email hello@lumicura.org.
Filed under: Boards & handoffs. If you'd like one of these in your inbox monthly, subscribe to Field notes.