Skip to content

Faculty & duties

Faculty workload and course allocation

Flip the population and the same engine works: faculty rank the courses they want to teach, load caps and competency requirements act as constraints, and the head of department publishes an allocation instead of negotiating one.

Same problem, different population.

Teaching-load allocation is the same constrained matching problem as elective allocation — except the head of department has to keep working with everyone afterwards.

  • Load caps set by regulation and by contract
  • Competency requirements limiting who can teach what
  • The same popular courses claimed by the same senior faculty every year
  • Exam and invigilation duties distributed by whoever answers email last
  • A negotiation that costs the HoD weeks of goodwill each semester

How it works

How Allotix runs faculty workload allocation

1

Set load caps and competencies

Each faculty member gets a maximum teaching load and a set of courses they are competent to teach.

2

Faculty rank what they want to teach

Preferences are collected in a controlled window, exactly as they are from students.

3

Publish the allocation

Run the engine against caps and competencies, and publish the result with the priority rule attached — so it is a process outcome, not a personal decision.

What you get

Built for this allocation, not adapted to it

  • Per-faculty teaching load caps
  • Competency requirements per course
  • Ranked teaching preferences
  • Seniority or rotation-based priority
  • Published allocation with the rule on record

FAQ

Faculty workload allocation — frequently asked questions

Can we rotate priority so the same faculty do not always win?

That is exactly what a stated priority rule is for. Rather than seniority alone, the priority basis can encode a rotation, so a faculty member who received their first choice last cycle is ordered lower in the next. The rule is published with the result, which is what makes it defensible.