Why Contractors Need Stronger Task Context, Not More Meetings
A contractor who asks a clarifying question in week two isn't slow. They're missing the six months of context your team absorbed without noticing.
A contractor joins a project on Monday. By Thursday she has asked, in three different channels, whether the checkout flow needs to support guest purchases. Someone finally tells her: no, guest checkout was killed eighteen months ago after a fraud problem, and there's a standing rule against reviving it. Nobody documented the rule. It just became something everyone on the original team knew.
This is not a story about a slow contractor. It's a story about a decision that lived only in the heads of people who were in the room when it was made. The contractor didn't lack skill. She lacked the six months of context that the founding team acquired for free, one Slack message and one late-night incident at a time.
The tax nobody puts on the invoice
When a contractor is slower than expected, the usual response is to schedule a call. A kickoff call, a sync, a weekly check-in. More meetings feel like more support. Mostly they're a workaround for a documentation gap, delivered live and synchronously, which is the most expensive way to transmit information that didn't need to be spoken at all.
A meeting answers one question and evaporates. The next contractor who touches that part of the codebase, or the same contractor three weeks later after the detail slipped out of memory, hits the identical wall. The cost isn't the hour on the call. It's that the answer never became something the task itself could tell you.
What's actually missing (and it's rarely what people guess)
Teams tend to assume a new contractor needs a tour of the tools and a read-through of the style guide. That's the easy 20%. The expensive 80% is quieter:
- History — what was tried before and why it was abandoned, so the contractor doesn't rebuild something that already failed once
- Assumptions — the unstated rules the team treats as obvious: which fields are never null, which flow is legacy and untouchable, which number is hardcoded on purpose
- Product vocabulary — what "active" means for a user, what "the pipeline" refers to internally, the shorthand that makes a sentence unreadable to an outsider
- Constraints — the client who won't accept a certain UI pattern, the contract clause that limits what data can leave a region, the deadline that isn't written down anywhere but is very real
- Stakeholders — who actually approves this kind of change, versus who merely has an opinion about it in the channel
- Adjacent work — the other task, maybe assigned to someone else entirely, that touches the same file or the same customer and will conflict if nobody mentions it
None of this shows up in a codebase or a design file. It lives in the collective memory of whoever has been there long enough to have absorbed it, which is precisely the memory a contractor, by definition, has not had time to build.
Three ways this plays out
A backend contractor is asked to add a discount field to an order. He builds it cleanly. Two weeks later it turns out discounts already exist, under a different name, applied at a different stage — a decision made before he joined, that nobody mentioned because everyone already knew it. He didn't do the wrong work. He did work nobody told him was already done.
A designer contractor redesigns an onboarding screen to be simpler. It gets rejected in review, because the current version, clunky as it looks, was deliberately built that way to satisfy a compliance requirement from a specific client. The requirement is real. It's also nowhere written down — it lives in an email thread from fourteen months ago that the designer was never on.
A QA contractor spends a day filing bugs against behavior that is, in fact, intentional — an edge case the product team decided to leave broken because fixing it wasn't worth the engineering cost. Nobody flagged it because flagging it would have meant writing down a decision that, at the time, felt too small to bother recording.
In each case the contractor did competent work. The tax was paid afterward, in rework, review cycles, and a slightly bruised sense that the contractor "didn't get it." They got it. They just weren't given it.
A context checklist for the task, not the kickoff call
The fix isn't a longer onboarding doc that goes stale in a month. It's attaching the relevant pieces of memory to the task itself, at the point someone is about to do the work — because that's the only moment the context is actually needed.
Before a contractor picks up a task, someone who has the memory should be able to answer, in writing, next to the task:
- Has anything like this been tried before, and what happened?
- What's the one rule about this part of the product that isn't written anywhere else?
- Is there a term in this task that means something specific here and not what it sounds like elsewhere?
- Is there a constraint — legal, contractual, a client's stated preference — that isn't visible in the code or the design?
- Who actually has to approve this, and is that different from who's likely to comment on it?
- Is anyone else touching this area right now?
Six questions. Most take one sentence to answer. The value isn't in the length of the answer — it's in the answer existing at all, attached to the work, instead of living in the memory of whoever happened to be around when the decision was made.
Why this is a task problem before it's a communication problem
Teams that lean on meetings to close this gap are treating a memory problem as a bandwidth problem. Adding more calls doesn't create memory — it just gives the missing memory a live audience. The information still isn't attached to anything. It still has to be re-spoken the next time someone new touches the same task.
This is one reason we built Team and Tricks around scope rather than volume of chat. A task comment belongs to the task; a project decision belongs where the project's work is; a document belongs wherever it's actually referenced from. The point isn't to generate more written communication. It's to make sure the one sentence that would have saved someone a day gets written down exactly once, next to the thing it applies to, instead of re-explained on every call.
The distinction worth keeping
A skilled contractor and an unproductive one often look identical in week one, because the difference isn't skill — it's whether the organizational memory that the rest of the team took for granted made it onto the task before they started. Meetings can transmit that memory, slowly, one contractor at a time, forever. Or it can be written down once, next to the work, and stop being anyone's job to repeat.
