The Hire Problem

The Hire Didn't Fail. The System Did.

You've probably been here. You brought someone on — an assistant, a project coordinator, someone to help manage the load — and it didn't work. They asked too many questions. Things fell through the cracks. You spent more time explaining and correcting than you would have spent just doing it yourself. Eventually you stopped delegating, or you let them go, and you went back to running everything alone.

And you walked away with a conclusion that felt earned: this type of work is too specialized to hand off. Or the right person just doesn't exist. Or you're better off doing it yourself until you can afford someone with more experience.

That conclusion is understandable. It's also wrong. The hire didn't fail. The system did.

What actually happened

When your administrator started, what did they walk into? Not in terms of their qualifications or your expectations — in terms of the actual environment. Was there a defined place for new matter information to live? A process for how documents got filed? A way to track deadlines that didn't depend on you flagging them? A clear picture of what a completed task looked like versus one that needed your review?

In most solo and small construction consulting practices, the answer to all of those questions is no. The practitioner knows how things work because they built the practice around themselves. The workflow lives in their head. The filing system makes sense to them because they created it. The deadlines are tracked because they're always watching.

None of that is visible to someone walking in from the outside. So they improvise. They create their own logic for where things go. They ask questions because there's no other way to know. They make decisions you wouldn't have made because they had no way to know what you would have decided. And the output looks wrong, not because they're incapable, but because they were navigating without a map.

The belief it creates

The experience is frustrating enough that it produces a conclusion. And the conclusion almost always points at the hire — their experience level, their fit, their ability to handle this type of work. It rarely points at the environment they walked into.

That's a natural response. It's also a costly one, because it protects the real problem from ever being examined. If the issue is the hire, the solution is a better hire. If the issue is the system, the solution is building one. Those are very different problems with very different fixes. Misidentifying the first one means the second one never gets addressed — and the next hire fails for exactly the same reason.

What the hire actually needed

Not more experience. Not a background in construction consulting. Not someone who could figure it out on their own.

A system to plug into.

Defined inputs — how a new matter gets opened, what information gets captured, where it lives. Defined outputs — what a status update looks like, how an invoice gets prepared, what done means for each type of task. A structure that tells them what to do without requiring you to direct every step. That's what makes a hire work. Not their resume. The environment you put them in.

When that structure exists, the administrator's job becomes executable. They're not improvising or interpreting or guessing at your preferences. They're following a framework that was designed for the work — and when something falls outside the framework, they know to flag it rather than guess. That's what independence looks like in practice. It's not the absence of questions. It's questions that don't require you to stop what you're doing every time.

The next hire can work

But something has to change before they start. The system has to exist before the person arrives — not built alongside them, not figured out together over the first few months. Built first, so they have something to step into.

The hire didn't fail. The environment wasn't ready. Build the system first, then bring someone in to run it. That's the order that works.