Running More Than One Programme at Once
Separate cohorts, shared machinery. What has to differ between programmes, what must not, and the point at which a second one needs a second manager.
The second programme is a staffing decision
Most centres add a second programme for one of two reasons: a funder wants something specific, or there is an audience the existing programme does not serve.
The second reason is good. The first is where trouble starts, because a programme launched to attract funding rarely comes with the staff to run it, and the capacity has to come from somewhere.
The honest test before adding one: does the existing programme run without the director's daily involvement? If not, a second programme will not run either - it will consume the attention that was keeping the first one going.
Share the machinery
The mistake that makes multiple programmes expensive is letting each build its own everything.
Share these:
- The question bank. One library of application questions, reused. Two programmes asking about team size in different words produce data you cannot compare across the centre.
- Stage definitions. Same three or four stages everywhere, so progression means the same thing.
- Reporting cadence and fields. Same quarterly update, same definitions, whichever programme a company is in.
- The permission model. One way of deciding who can see what, applied per programme.
- Space and facilities. One pool, allocated across programmes, not two parallel systems.
Sharing these is what makes a centre with three programmes still able to answer "how many startups did we support and how did they progress" in one query.
Do not share these
Selection and rubrics. Different audiences need different criteria. A pre-incubation applicant with an idea and a prototype cannot sensibly be scored against a rubric written for companies with revenue, and forcing one rubric across both produces a ranking that means nothing in either.
Cadence. An accelerator's fixed twelve weeks and an incubator's rolling residency are different rhythms. Trying to synchronise them for administrative tidiness makes both worse.
Panels. Some overlap is fine and useful. Identical panels are not - the expertise needed to judge a research spin-out differs from what is needed for a consumer app.
Keep the boundaries visible to founders
Companies should know which programme they are in, what it includes, and what it does not.
The failure mode is a centre where three programmes share a building and nobody can say which support belongs to which. Founders in the light-touch programme expect the intensive one's mentoring; founders in the intensive one wonder what they are getting that the others are not.
State it plainly at intake: this programme, this duration, this support, these obligations.
Watch for the attention imbalance
The predictable failure when one manager runs two programmes.
The programme with hard deadlines - an accelerator cohort, a demo day, a funding round - always wins attention, because its work is urgent. The other programme's work is important and not urgent, so it gets done last, then not at all.
The symptoms are recognisable: one cohort's updates are chased and the other's are not; one has mentor sessions running and the other's mentors were never contacted; one appears in the board pack in detail and the other in a sentence.
If those symptoms appear, the fix is a second programme manager, not better prioritisation.
Report per programme and in total
Both, always.
Per programme, because a centre that reports only totals cannot tell which programme is working. If one has 70% survival and the other 30%, the aggregate hides the finding that matters most.
In total, because that is what the institution and the funder usually ask for, and because it is the number that describes the centre.
Keeping shared definitions is what makes both possible from one set of records. Programmes with divergent stage definitions can only be reported separately, and the total becomes an addition of incomparable things.
A short readiness check
Before adding a programme:
- The existing programme runs without daily director involvement
- There is an audience the existing one genuinely does not serve
- There is a person to run it, or budget to hire one
- Selection and rubric will be separate
- Question bank, stage definitions and reporting will be shared
- Space is allocated from one pool, not two
- Board reporting will show both separately and in total
If more than two of those are unresolved, the second programme is a plan rather than a decision - and the first programme will pay for the difference.
Frequently asked questions
- When is a centre ready for a second programme?
- When the first one runs without the director's daily attention, and when there is a distinct audience the first programme genuinely does not serve. A second programme launched to attract a second funder, with the same staff, usually weakens both.
- What should be shared between programmes?
- The machinery: the question bank, stage definitions, reporting cadence, permission model and space management. Sharing those keeps data comparable across programmes and stops each one inventing its own vocabulary.
- What must not be shared?
- Selection and rubrics. Two programmes with different audiences need different criteria, and scoring a pre-incubation applicant against an accelerator rubric produces a ranking that means nothing.
- Can one person run two programmes?
- For a while, and it is the most common way both end up mediocre. The programme with deadlines wins the attention; the other quietly becomes a set of desks and an occasional event.
