Webneuron
MSP and VMS

Tenure limits are a knowledge policy in disguise

The eighteen-month rule was written to manage co-employment risk. What it actually manages is how much institutional knowledge you are willing to discard on a schedule.

June 9, 20266 min readBy Webneuron Engineering Team

Most large contingent workforce programmes impose a tenure limit: a contractor may work for eighteen or twenty-four months, then must leave for a defined period before returning. The policy has a sound legal rationale. Co-employment risk is real, misclassification carries genuine liability, and counsel is right to want a bright line.

What is rarely examined is the second effect. The policy also governs, indirectly and without anyone intending it, how long knowledge is permitted to remain in your organisation.

What leaves when the contractor does

An engineer who has worked on a system for eighteen months holds a body of understanding that exists nowhere else: why a particular workaround is load-bearing, which integration fails silently under load, what was tried in 2023 and abandoned for a reason nobody wrote down.

Very little of this survives handover, because handover documents record how the system works rather than why it is that way. The replacement arrives, spends three months reaching the level the previous engineer reached in three weeks, and the cycle begins again on a fixed timetable.

Where a programme applies the limit uniformly, the effect compounds. Systems maintained largely by contingent staff acquire a permanent knowledge ceiling, because nobody is present long enough to exceed it.

Sharpening the policy

  • Distinguish co-employment risk from convenience. The legal exposure depends on how the relationship is managed — direction, integration, benefits — not solely on elapsed time.
  • Vary the limit by role. A contractor performing defined project work sits differently from one embedded in a permanent team, and a single rule for both is a blunt instrument.
  • Build conversion paths deliberately. Where an engagement has run eighteen months and the work continues, the honest answer is often that this should be a permanent role, and the tenure limit is a useful prompt to say so.
  • Overlap departures. A four-week handover with both engineers present transfers materially more than a document, and costs less than the ramp it prevents.
  • Track what the churn costs. Ramp time, incident rates after rotation, and repeated rediscovery are all measurable, and rarely measured.

The conversation worth having

Tenure limits are usually set by legal and applied by procurement, and the engineering leaders who bear the consequences are frequently not in the room. That is the structural problem, and it is solvable without weakening the control.

The productive version of the discussion is not whether to have a limit. It is which roles the limit should apply to at full strength, where a conversion path should exist instead, and what the organisation is prepared to spend on transferring knowledge it has already paid to create. Answered deliberately, the policy protects the company. Answered by default, it quietly guarantees that your most complex systems are understood by nobody for more than a year and a half.

Let's build the system your business will run on next.

Tell us where it hurts. We'll bring the architects, engineers, and delivery model to fix it — and scale it.