For mentors
Supervise a cohort's delivery on a real, partner-scoped problem.
A partner organisation contributes a problem it has scoped but cannot staff. A mentor reviews the cohort's work against a stated quality gate and is accountable for what the cohort produces, in the same way a delivery lead is accountable on a client engagement. This is the same disclosure made to organisations that engage a cohort, stated here from the mentor's side.
What the role involves
Supervision, not lecturing.
A mentor is assigned to a cohort working a single problem for the stated duration. The work itself is performed by participants. The mentor reviews it, sets the standard it must meet before it reaches the partner, and is the named point of accountability if the output falls short. Contact time is structured around review points in the cohort's schedule rather than delivered as a lecture series. A mentor who has led this kind of work before will recognise the shape of it: it is closer to reviewing a junior team's output on a live engagement than to teaching a course.
What is required
The bar is five or more years of delivery experience, evidenced.
| Requirement | What this looks like |
|---|---|
| Delivery experience | Five or more years delivering transformation, operations or technology work inside organisations, not only advising on it. Evidenced by CV and reference at the expression-of-interest stage, not by a self-declared checkbox. |
| Domain coverage | Practice across one or more of the five problem categories the pipeline handles. A mentor is not expected to cover all five; cohorts are matched to a mentor's own domain. |
| Supervisory capacity | Willingness to review work you would ordinarily perform yourself, hold a stated quality gate, and be named as accountable for what a cohort produces on a given problem. |
Problem categories the pipeline handles
A mentor's own practice does not need to span all five. Cohorts are matched to the category or categories a mentor actually works in.
- Process automation Workflow redesign, robotic process automation, operational efficiency work.
- Legacy system modernisation Migration planning, technical debt assessment, platform replacement scoping.
- Data strategy Data readiness, governance, architecture and reporting capability.
- AI adoption Use case identification, governance, and agentic or automated workflow redesign.
- Change management Stakeholder alignment, adoption planning, and organisational readiness work.
What is not yet fixed
Time commitment, compensation and cohort load are set at expression of interest.
None of these has been finalised as a published figure. That is a structural fact of where the pipeline is right now, not an omission. Publishing a number ahead of the first cohort would mean publishing a guess. Each is confirmed with you directly once you register interest, against the specific problem and cohort you would be matched to.
Time commitment per cohort
Confirmed at expression of interest
Compensation basis
Confirmed at expression of interest
Cohort load
Confirmed at expression of interest
This does not change how a mentor is paid directly, but it is useful context: participants pay to work on problems for which the contributing organisation also pays, and Praxora Lab receives payment from both sides where applicable. Read how we are paid.
Why we are building this bench now
Cohorts cannot run without a mentor assigned to the problem they are working. Mentor availability is the constraint most likely to limit how fast the pipeline can scale once demand exists, and it becomes visible later than a shortage of problems or a shortage of applicants. Registering interest now does not commit you to a cohort; it puts you in the pool that gets contacted when a matching problem and cohort are scoped.