A student-run ecosystem for real work
Pods of about five give belonging. Pairs of pods review each other’s work. Flexible teams deliver real work. Rotating stewards run shared services with procedural authority only. An optional pathway supports ventures.
The problem
Students often reach graduation having studied subjects but with little structured practice working reliably with other people under real constraints: deadlines, dependencies, unclear requirements, disagreement and limited resources. Group assignments end without shared habits, follow-up or continuity.
Good ideas and capable collaborators fail to find each other. Promising projects stop at the end of a course or semester because nothing carries them forward.
The vision
Students learn to work effectively with other people from the start of their university life, through the way they actually spend their time with peers, not through lectures about teamwork.
The Ecosystem exists to help students work reliably with others, discover complementary collaborators, apply what they study to real problems, reach opportunities they would not reach alone, and continue promising work beyond a course, semester or graduation.
It does not exist to maximise activity, produce startups or build a student hierarchy.
- A student-run environment for learning to work with people.
- Stable pods plus flexible project teams.
- Open to all disciplines.
- A place where real work and real stakeholders exist.
- A route to ventures for those who want one.
- Free to join in the pilot.
- Compatible with university rules.
- A student association with titles and no work.
- A chain of command in which leaders assign work downward.
- A software-only club.
- An unpaid labour pool for outside parties.
- A mandatory incubator.
- A paid programme.
- A parallel university administration.
The fifteen principles
Success is measured by capability and wellbeing, not event counts.
Work is owned by the unit best placed to do it.
A unit solves what is inside its scope before asking permission.
Every significant task has an owner, an outcome and a review.
Pods persist; project teams form and dissolve around work.
Skills are practised through real coordination, not lectures about teamwork.
No one has to lead, volunteer constantly or start a venture.
The system lowers friction for good collaborations without forcing them.
Students keep rights in their ideas, work and personal information.
Time caps, exam freezes and pause rules protect studies and health.
Alternatives exist for cost, travel, ability, bandwidth and confidence.
The system changes based on evidence, not attachment to the design.
Cooperate with legitimate university rules; do not pretend to replace them.
Every layer, rule and tool must justify its cost.
Ventures continue free of Ecosystem control.
Four layers, one simple rule
Pods are the people structure. Project teams are the work structure. A member belongs to one pod and may join several project teams. Pods give belonging and accountability; project teams give focus and end when the work ends.
Pods, pairs, optional clusters, department liaisons and the Steward Circle.
Peer learning, activities, feedback and the professional competency framework.
Briefs, flexible project teams, integrators and structured reviews.
The project board, validation and the optional venture pathway.
How a pod works
- Weekly 45-minute check-in, or a written asynchronous equivalent.
- Monthly 30-minute retrospective.
- Rotating Convener, Scribe and Link roles; anyone may pass.
- A one-page pod agreement covering rhythm, channels, privacy and problems.
- A pod below four members gets a two-week recovery window before any merge.
Clusters and liaisons are optional
A cluster of 30–50 members is created only when a trigger is met, never to complete a hierarchy. Department Liaisons are a role, not a layer: they bring opportunities in and news out, but have no authority over pods.
The decision rule: Solve, Sync, Escalate
Inside our scope, authority and resources, with no change to other units’ commitments? Fix it and tell anyone affected.
Depends on another unit or a shared resource? Agree it directly, within two attempts or five days.
Exceeds authority, expertise, resources or acceptable risk, or Sync failed? Escalate one level with facts, options and the decision needed.
Self-governing, not unaccountable
Members make real decisions. Authority is procedural, time-limited and constrained by written rules. No steward, convener, lead or founder may assign work to a member who has not agreed to it.
Constrained authority
Offices carry responsibility, not rank. No one may hold office indefinitely.
Student ownership
Participation never transfers ownership of a member’s work, ideas, data or personal information.
Rotation and recall
Steward terms last one Term. Members can recall a steward through a written petition and vote.
University independence
The Ecosystem starts independent, never claims university endorsement and follows institutional instructions.
Qualified lottery
Stewards are approved by members, then seats are filled by public random draw from qualified nominees.
Transparency
Steward decisions are recorded, a fortnightly digest is published and any member may ask for reasons in writing.
The Steward Circle
Campus Coordinator
5–8 hours per weekChairs the Steward Circle and acts as the chapter’s public contact.
Limit: Procedural authority only: agenda, chairing and routine messages. No casting vote and no authority to assign work.
Projects & Opportunities Steward
4–6 hours per weekKeeps the project board moving and screens real-world requests against the work framework.
Limit: May decline unsuitable requests with reasons. May not assign work or choose teams.
Learning & Activities Steward
4–6 hours per weekKeeps the development layer alive through peer teaching, practice and low-cost social activities.
Limit: Activities are offered, never compulsory.
Records & Continuity Steward
3–5 hours per weekProtects institutional memory, runs elections and maintains the policy register and handovers.
Limit: Works to the retention rules and does not access individual feedback records.
Support and oversight
Welfare Contact
1–2 hours per weekA trained peer who listens and points members to the right help.
Limit: Not a counsellor. Never investigates, diagnoses or promises absolute confidentiality.
Safeguarding Lead
On call; about 2 hours per week plus incidentsAn adult outside the Steward Circle who handles serious welfare and safeguarding concerns.
Limit: Acts on safety grounds and keeps safeguarding records separate from the Circle.
Pilot Facilitator
8–10 hours per week during the pilotA temporary Cofoundr staff member who helps the chapter start and hands over cleanly.
Limit: No vote in chapter decisions. Reserved powers only for safety, safeguarding or legal compliance.
Mentor
Occasional, by agreementOffers experience and honest feedback to a pod or project.
Limit: Advises; does not direct. Outside mentors accept the Code of Conduct.
Complaints and appeals
Complaints about a steward go to the Safeguarding Lead. Retaliation against anyone who raises a concern is itself misconduct.
Cofoundr’s role is disclosed and limited
- Cofoundr runs the pilot infrastructure and may offer optional products.
- No member must use a Cofoundr product or enrol in a Cofoundr programme.
- Projects remain exportable in standard formats.
- Membership data is not used for marketing without separate consent.
- Reserved powers are limited to safety, safeguarding and legal compliance.
- The facilitator role ends by the end of the second Term.
Reliable work without unnecessary weight
Every substantial task starts with a brief. Pieces are defined by the actual work, offered to the most suitable people, and joined by a named integrator. Members choose pieces; they are never assigned work without agreement.
A brief contains
- Objective: the result wanted, in one or two sentences.
- Owner: one named person or unit responsible for the result.
- Scope: what is included and what is explicitly excluded.
- Deliverable: the specific output someone can use or review.
- Acceptance criteria: observable conditions for “done”.
- Time window: start, checkpoints and end.
- Resources: people, tools, access and money.
- Dependencies: what is needed from other units or outside parties.
- Decision authority: what the owner can decide alone.
- Channel: where updates and questions go.
- Reporting: when and how progress is reported.
- Blockers: how and when they are raised.
- Review and completion: who reviews and how closure happens.
Project lifecycle
Projects may also pause, continue with a new owner, archive, revive or be abandoned with reasons. A project that loses its lead is paused for no more than two weeks.
External work must pass the free-labour test
- A named stakeholder with authority to accept the work.
- A written scope and an hours cap agreed with the team.
- A change-request rule; extra requirements become a new brief.
- A stakeholder response commitment, credit and a right to withdraw.
- No replacement of a paid role the stakeholder would otherwise fill.
Ten professional competencies
Four levels: Beginning, Developing, Reliable and Guiding. Levels are evidence-based, private by default, confirmed by two peers before being shown to others and never used to rank members.
Communication
Clear messages, the right channel and early warning when something slips.
Collaboration
Shares information, asks for help and reviews work without taking over.
Reliability and time management
Plans realistically and renegotiates commitments before they fail.
Planning and execution
Breaks work into pieces, estimates and tracks dependencies.
Problem-solving and critical thinking
Describes a problem, compares options and tests a response.
Leadership and coordination
Runs a defined activity or meeting with support.
Conflict management
Notices tension and raises it with someone directly.
Documentation and records
Keeps notes and records decisions and actions.
Stakeholder interaction
Takes part in stakeholder meetings and asks clarifying questions.
Personal development and ethics
Accepts feedback, asks for help and knows their limits.
Communication standards
- If it would matter in a month, write it where it can be found.
- A decision made in chat is posted to the shared record within 24 hours.
- Reply within two working days, even if only to set a later answer date.
- No expectation of replies between 9 pm and 7 am or on rest days.
- Meetings end with decisions, owners and dates recorded.
- Text-first, small images and asynchronous alternatives protect low data budgets.
Feedback and recognition
- Self-reflection: monthly, ten minutes, private notes.
- Peer feedback: two or three peers who worked with the member, at most once per Term.
- Project review: at closure, covering what worked and what to change.
- Mentor conversation: occasional, by request.
- Development plan: one page each Term, optional.
- Feedback to the Ecosystem: any member, anytime, with an anonymous option.
Hours, popularity, extroversion, office-holding, isolated missed deadlines and academic grades are not used as feedback scores. There are no public rankings, points or leaderboards.
Student welfare comes before projects, activities and recognition
The Ecosystem is run by students and is not a counselling, medical, legal or investigative service. It can create a respectful environment, notice problems, listen and connect people to qualified help. Serious welfare, medical, safeguarding and legal matters belong to qualified professionals and legitimate authorities.
Handled inside the Ecosystem
- Disagreements between members.
- Missed commitments and workload strain.
- Respectful-conduct issues of a minor or moderate kind.
- Accessibility adjustments inside activities.
- Participation pauses.
Referred to qualified people
- Mental health crises, self-harm or suicidal thoughts.
- Medical emergencies.
- Sexual violence, assault, stalking or serious harassment.
- Abuse, coercion or exploitation.
- Threats, violence or criminal conduct.
- Matters involving a person under 18.
- Legal disputes and data-protection breaches.
Maximum participation across all roles and activities per week.
Maximum steward workload per week.
Optional activity pauses around exams without penalty.
At any time, without explanation and without penalty.
Accessibility is designed in
Code of Conduct
- Treat everyone with respect.
- No harassment, bullying, intimidation or discrimination on any ground.
- No unwanted sexual attention or advances.
- No threats or violence.
- Respect privacy: do not share other people’s personal information.
- Do not retaliate against anyone who raises a concern.
- Do not misuse position or information for personal advantage.
- Follow university rules and the law when acting for the Ecosystem.
Reporting and response
- Report directly to the Safeguarding Lead, any steward or a Welfare Contact.
- An anonymous form is readable only by the Safeguarding Lead.
- Confidentiality has limits where safety, serious harm, abuse or legal duties require sharing.
- Everyday concerns: within 7 days. Conduct concerns: acknowledged within 72 hours. Serious or urgent: same day.
- Safeguarding records are kept separately by the Safeguarding Lead, not by stewards.
Contact routes and referral partners are placeholders until verified before launch. Do not rely on this page for emergency contact details.
Workflows first, software later
The pilot runs on affordable, familiar tools. Custom software is not built until the pilot shows where tools fail. The design must work on phones, on low bandwidth and through periods of poor connectivity.
Minimum infrastructure
Tool administration is capped at 2 hours per steward per week. If it exceeds that, simplify or drop a tool.
Low-bandwidth and offline
- Text-first communication; short messages and compressed images.
- An asynchronous alternative for every live activity.
- Downloadable documents that work offline.
- A fortnightly email digest so members who miss chats can catch up.
- An outage protocol: commitments pause and no one is penalised.
- Paper or phone-note fallbacks, with records updated afterwards.
Records and privacy
The chapter keeps only the minimum records: roster, pod records, project register, decision log, policy register, consent records and aggregate evaluation data. Safeguarding records are held only by the Safeguarding Lead.
Never exposed to other members or the public by default: phone numbers, home addresses, private email, intake details, feedback notes, health or disability information, welfare records, location and anything about under-18 members.
Continuity and handover
- Every role and project has a handover note and at least two weeks of overlap.
- Access is removed within seven days after the overlap.
- Policy register, decision log, lessons log and term report preserve memory.
- A project without a lead for two weeks is paused, not left drifting.
- If Cofoundr withdraws, it gives at least one Term’s notice and hands over exports.
Optional, evidence-led and independent
The pathway exists so members who want to go from an idea to a real venture can do so with less friction, honest feedback and fair terms. It is not the purpose of the Ecosystem, not a requirement for recognition and not a promise of success. Most members will do other valuable things, and that is fine.
Principles
- Evidence before ambition; progress depends on proof from real people.
- Stages, not a ladder; a team may stop at any stage without stigma.
- Ownership and credit are written down early.
- Studies and health come first; time caps and exam freezes apply.
- A formed venture belongs to its founders, not the Ecosystem or Cofoundr.
- No false promises, no endorsement and no pressure to join.
Ownership and fair terms
- Who owns the idea, code, designs and data.
- How contributions of time and skill are valued.
- What happens when someone leaves or has a life emergency.
- How decisions are made and disagreements resolved.
- How university, employment and family obligations are respected.
- The Ecosystem may mediate but does not decide ownership.
| Stage | Question | Evidence to move on | Exit |
|---|---|---|---|
| Problem discovery | Is there a real problem for real people? | At least ten conversations with affected people, recorded. | Stop or reframe |
| Customer discovery | Who exactly has it, and what do they do now? | A clear description of one group and their current workaround. | Stop or pivot |
| Solution definition | What is the smallest useful thing we could offer? | An agreed assumptions list and a test plan. | Stop or return |
| Prototype | Can we make a version people can try? | A working prototype or service sample. | Stop or iterate |
| Validation | Do people actually use or want it? | Behaviour evidence: use, repeat use, willingness to pay or commit. | Stop, pivot or continue |
| Pilot users | Does it work with real users over time? | A small pilot with five to ten users, feedback and measurable use. | Stop or continue |
| Venture decision | Do we want to commit more, and on what terms? | A written decision by every founder. | Continue as a project, form a venture or stop |
| Independent venture | Is it running on its own terms? | Registration, customers, finance and outside advice. | Independent |
| Continuation or alumni | Does the venture stay connected? | Optional mentorship back to members. | Voluntary |
Growth follows evidence, not ambition
Each phase has a decision gate. The Ecosystem may stop, repeat or change at any gate. No chapter launches with open safeguarding or legal items.
Preparation
Decide open items, complete legal review, appoint the Safeguarding Lead and facilitator, set up tools and recruit the first cohort.
Pilot Term 1
Run the pilot playbook, monitor monthly and produce an honest evidence note.
Review and Term 2
Publish results, complete literature notes, hold steward elections and test the handover pack.
Stabilisation
Run without founder involvement in daily operations and test safeguarding, burden and continuity.
Expansion
Expand only after two chapters have each completed two Terms and the support model is proven.
Do not launch until
- • A named Safeguarding Lead and deputy are in place, trained, and the referral map is complete and verified.
- • Written legal advice on the Constitution, data collection and IP checklists has been received.
- • University rules on student groups and campus facilities have been checked for the pilot campus.
- • A facilitator and backup are named with committed hours.
- • Founders have approved or changed the pilot thresholds.
- • Interim stewards and Welfare Contacts have completed the briefing.
- • The conflict-of-interest disclosure has been written in plain language for members.
- • The members’ consent forms have been reviewed for data-protection compliance.
The public ecosystem page summarises the member-facing framework. Staff can review the pilot playbook, risk register, evaluation plan, simulations and readiness audit in the administration console.