Almost every fellowship, grant cycle, or mentorship programme starts the same way: a spreadsheet, built quickly, that works fine. Cohort 1 has twenty people. One tab per cohort, a few formulas for status tracking, done. It's not until several cohorts in — often around cohort 5 or 6 — that the same spreadsheet starts to visibly buckle. The team assumes something went wrong with how it's being used. Usually, nothing went wrong. The spreadsheet simply hit the point where its structure stops matching the size of the problem.
Why the breakdown isn't gradual
A spreadsheet's usability doesn't degrade in a straight line as data grows — it holds up fine for a while and then falls off a cliff. Cross-referencing two cohorts by hand is annoying at cohort 2, tedious at cohort 4, and functionally impossible at cohort 6, because the number of relationships to track doesn't grow one at a time — it grows with every new combination of cohort, mentor, and applicant. A structure that was never designed to model relationships, only to list rows, runs out of road exactly when the programme has grown enough to be worth protecting.
The specific ways it shows up
- Formulas silently break when someone inserts a row in the wrong place, and nobody notices until a number looks wrong weeks later.
- Version control becomes guesswork — three people have "final_v3" open, and nobody's sure which one has the latest updates.
- Cross-cohort questions become manual projects. "How many mentors from cohort 2 are still active in cohort 6?" stops being a filter and starts being an afternoon.
- Matching and pairing stops scaling. Manually cross-referencing mentor and mentee criteria was manageable at twenty people. At two hundred, it's the single biggest bottleneck before a cohort can even start.
The actual signal to watch for
It's not a headcount threshold — it's a specific moment: the first time someone on the team says a version of "I think this number's wrong, let me go check manually" about something the spreadsheet should have been able to answer directly. That's the point the structure has stopped matching the size of the operation, and it's usually cheaper to migrate to a proper relational structure right then than to keep patching the spreadsheet through another cohort.
What the migration doesn't have to mean
It doesn't require replacing the spreadsheet's simplicity with something the team can't operate — it means moving the same fields into a structure (like Salesforce NPSP or a properly related database) that can actually model cohorts, mentors, and applicants as connected records instead of disconnected rows, so the questions that were manual projects become filters again.