Before You Post the Job, Write Down Every Task You Do
Before hiring, list every task you do with weekly hours, how hard it is to train someone else on it, and what breaks if it's skipped. That list becomes your job requisition, not a vague sense that you need help.
A client of mine who runs a marketing agency showed up to our last call with a spreadsheet instead of a feeling. Most founders come to me wanting to hire because they're drowning. He came with a list.
Every task he does, scored four ways: hours per week it eats, how hard it would be to train someone else to do it, who currently owns it, and what happens if it doesn't get done. Forty-some rows. No guessing.
What should actually go on a hiring wishlist?
Not "we need a project manager." That's a feeling, not a job description. The list is the job description.
We sorted his rows into three buckets: move this week, move within 30 days, and stuff only he can touch. The first two buckets are what you hire for. The third bucket is what you keep, on purpose, because someone has to.
Once he had that split, the job requisition wrote itself. Client onboarding, routine check-ins, first-line support, daily workload review, Slack responsiveness, project queuing. All recurring, all trainable, none of it requiring him specifically.
Why do most founders hire for the wrong role first?
Because they hire for relief instead of math. His actual problem wasn't "I need more hands." It was that he was still the one validating every quarterly client report before it went to his strategists, still triaging support pings all day, still context-switching between fires that a $20-an-hour operator could put out.
None of that needed him. All of it needed someone who reports to him.
How do you size the hire before you post it?
Pull real calendar data, not your best guess. I asked him to pull the last 60 days of his calendar, meetings and all, so we could see where his time actually went instead of where he assumed it went. Most founders overestimate the hard stuff and underestimate how much of their week gets eaten by things like reviewing the same report format for the fortieth time.
That data is what turns "I think I need help" into "here's 12 hours a week, here's what it's worth, here's who should own it." A candidate you can't cost-justify on paper is a candidate you'll resent by month three.
What do you do with the estimates once you have them?
His first pass at the spreadsheet had soft numbers. A task listed as "a few hours a week" isn't hireable, because you can't price it and you can't hold anyone accountable to it. We went back through and tightened every row to an actual hours-per-week figure pulled from the calendar data, not a round number that felt right.
That tightening mattered more than the sorting did. Two tasks that looked similar on a gut-feel basis turned out to be six hours apart once he checked. The one that ate more time moved to the top of the requisition. The one that didn't got pushed to the 30-day bucket instead.
What should stay out of the new hire's hands?
Reporting was the clearest example. His team's quarterly client reports were already mostly AI-generated drafts, with a strategist spending 15 to 30 minutes per report validating the recommendations before it went out. That validation step is real judgment and stays with the strategist. Producing the report itself doesn't, and can move to a lower-cost operator entirely.
Same logic on content. Clients care about two things: leads and completed projects. Technical detail like schema markup notes and internal opportunity lists was cluttering the client-facing report for no reason. That stuff still matters, it just belongs in the project management tool for the internal team, not in an email a client skims from their phone.
He also raised a question worth asking before you simplify anything: does anyone actually read these reports in full? Nobody on his team could say for sure whether clients opened the detailed version past the first page. Before you spend hours polishing a deliverable, it's worth finding out if the polish is landing on anyone.
How long should you expect the handoff to take?
He's budgeting 90 to 120 days for the new hire to absorb the operational load, and he's staying on the hook for onboarding until that transition is done. Not indefinitely, not "whenever it feels ready." A number, on a calendar, that someone can be held to.
He also agreed to batch report reviews on set weekdays instead of touching them daily in scattered ten-minute blocks. Small change, but it turns a background hum of context-switching into two contained sessions a week.
The job posting is already live on Indeed and ZipRecruiter, with Upwork as a backup channel for the lower-cost report review work in the meantime. He's not waiting for the perfect candidate to fix the whole list at once. He's hiring for the twelve hours he can already prove.
