The Résumé Problem in Project Hiring

The résumé has survived for a remarkably long time, given how little it tells anyone. It is a document written by the person being judged, edited to flatter, and formatted to survive a few seconds of skimming. For a permanent role, where an employer will invest months in onboarding and has a probation period to correct mistakes, that weakness can be absorbed. For project hiring, where a client needs a specific outcome in a specific window, the weakness becomes the whole problem.

A document built for a different question

A résumé answers the question "who is this person, broadly?" It lists employers, titles, durations and a handful of skills. Project hiring asks something narrower: "can this person deliver this particular thing, on this timeline, without constant supervision?" The two questions overlap less than we pretend.

Consider what a title actually encodes. "Senior developer" at one company can mean someone who architects systems; at another it means someone who has been there four years. "Led the redesign" can describe a person who made every decision or a person who sat in the meetings. The résumé format flattens these differences because it was designed for comparison at scale, not for precision.

There is also the matter of authorship. Every line is self-reported. That does not make résumés dishonest; most people describe their history in good faith. But self-reporting has a predictable bias toward the favourable interpretation, and a reader has no way to separate the confident from the accurate.

What project hiring actually needs to know

When a client commissions a piece of work, the useful evidence falls into a few categories. Has this person completed comparable projects, and were those projects finished rather than abandoned? Did they deliver on the dates they agreed? Did previous clients come back for more work, which is perhaps the most honest signal a working relationship can produce? And can the person describe, concretely, how they would approach this job?

Notice that only the last of these is something a candidate can generate on demand. The others are facts about the past, and their value depends entirely on whether anyone other than the candidate can vouch for them. A résumé can claim "consistently delivered on time," but it cannot show the dates.

This is why experienced clients lean so heavily on referrals. A referral is a third party putting their own credibility behind a claim. It is slow, it does not scale, and it favours people who already have networks, but it is at least evidence rather than assertion.

The cost of guessing

The price of relying on weak signals is rarely visible at the moment of hiring. It shows up three weeks later, when the first milestone slips, or at the end, when the delivered work technically meets the brief but misses the point. By then the client has spent money, the freelancer has spent time, and both are worse off than if the mismatch had been caught early.

Weak signals also distort the market in subtler ways. If the only differentiator is how well someone writes about themselves, then self-presentation becomes the skill that gets rewarded. Capable people who are modest or simply busy lose work to confident people who are less capable. Over time, clients learn to distrust everyone, which raises the cost of every hire.

Toward evidence that travels

The alternative is not to abolish the résumé but to supplement it with records that someone other than the candidate has confirmed. A history of contracts with dates, a count of repeat clients, a measure of on-time delivery drawn from milestones that were agreed in advance: these are harder to embellish because they were not written after the fact by the person they describe.

Some platforms are now built around this idea. On https://workli.tech/, for example, a freelancer's profile shows only contracts recorded on the platform, and clients can confirm an engagement from their own accounts; nothing on that history is typed in by the freelancer. Whether one uses that approach or another, the principle is the same: the record should be produced by the work, not by the writing about the work.

For clients who cannot rely on such records yet, a few habits help. Ask for a concrete plan with dated steps rather than a general pitch. Ask which past clients hired them more than once, and why. Start with a small, well-defined first phase before committing to the whole. Each of these replaces a claim with something closer to evidence.

A better default

The résumé will not disappear, and it should not; it remains a reasonable introduction. The mistake is treating an introduction as proof. In project hiring, where the work is specific and the window is short, the reasonable default is to ask what has been verified, by whom, and how recently. A hiring process built on that question will still make mistakes, but they will be fewer, smaller and easier to correct.