What I Got Wrong About Hiring

Most hiring mistakes don't look like mistakes when you make them. They look like reasonable decisions with reasonable logic. The cost shows up later, distributed across months of inefficiency, misaligned expectations, and rework — never cleanly attributed to the original decision.

Three beliefs shaped early hiring decisions in ways I'd approach differently now.

Contractor-first as a reflex, not a decision

The case for starting with contractors is real: lower commitment, faster onboarding, access to specialization without long-term overhead. For specific use cases — a defined project with a clear end state, a skill needed once — contractors are the right answer.

The mistake was using contractor-first as a default operating principle rather than a considered choice. Every ongoing operational need got met with a contractor because "we're not ready to hire yet." The result was a business that ran on relationships that required constant re-explanation of context, had no institutional memory, and couldn't build compound capability because every engagement reset to zero.

The actual question isn't "contractor or employee." It's: is this work ongoing and does it compound with institutional knowledge? If yes, the contractor model has a hidden cost that shows up as re-onboarding time, knowledge loss at project end, and inconsistency in client-facing work. That cost doesn't appear on a payroll line, which is why it's easy to ignore until it's large.

Context-switching has a compounding cost. Contractor relationships that require full context transfer at the start of every engagement are organizational context-switching — the same cognitive overhead, at the team level, every time.

"Culture fit" as a filter

Culture fit is a useful concept that is almost always applied incorrectly. The useful version: does this person share the working values that make the team functional — directness, reliability, willingness to ask questions rather than guess, comfort with ambiguity? Those are real and worth screening for.

The harmful version: does this person remind me of people who've worked well in the past? The second version is a cognitive shortcut that replicates existing team composition rather than finding people who are genuinely good at the work. It's also where hiring bias lives — "culture fit" as a veto without definition is a mechanism for rejecting candidates whose background or style differs from the existing team's, regardless of capability.

The fix is specificity. "Culture fit" as a criterion needs to be decomposed into observable behaviors before it's used in evaluation. What does direct communication look like in practice at this organization? What does ownership look like? What does "comfortable with ambiguity" mean for this specific role? The more specific the criteria, the less the evaluation relies on gut reaction — which correlates with the interviewer's comfort level, not the candidate's competence.

Hiring before the process exists

The logic: bring someone in and they'll help build the process. The result: the new hire spends their first six months operating without a clear definition of success, making decisions based on incomplete information, and establishing patterns that may not be the patterns the organization actually wants.

Process doesn't need to be comprehensive before a hire. It needs to be clear enough that the person knows what good looks like in their first 90 days, what decisions they own, and what they escalate. That's one document, not an operations manual. But without it, onboarding is guesswork for both sides — and the first person to fill a role defines the patterns that become "how we do things," whether those patterns are optimal or not.

The discipline: write the role definition, the decision rights, and the 90-day success criteria before the first interview. Not as a bureaucratic exercise — as a forcing function for clarity about what the organization actually needs. If you can't write what success looks like, you're not ready to evaluate candidates against it.

---

Related reading

• The Problem with Generic Tech Recommendations
• If the Recommendation Came Before the Questions, It's Not Advisory

Frequently asked questions about hiring mistakes

When is contractor-first actually the right model?

For work that is bounded and non-recurring: a specific design project, a code audit, a market research sprint. For specialized skills needed once or occasionally. For capacity overflow when you have more work than headcount but don't expect that ratio to persist. The test is whether institutional knowledge compounds on this work — if it does, the contractor model has a hidden carrying cost.

How do you evaluate culture fit without bias?

Define the behaviors in writing before you evaluate candidates, and evaluate every candidate against the same criteria. Ask the same behavioral questions across interviews. Where possible, use structured evaluation rubrics rather than impressionistic ratings. Audit your rejections periodically — if candidates who don't "fit" share demographic characteristics, the criteria are doing something other than what you think they're doing.

What's the minimum process documentation needed before a first hire?

Role definition (what this person owns, what they don't), decision rights (what they decide autonomously, what they escalate), 90-day success criteria (specific and measurable), and the communication expectations for the role. That's enough to give someone a real start. Everything else can be built together.