Your SOPs Will Not Make the New Hire Fast

Because most of what makes you fast was never written down, and some of it cannot be. You do not consciously decide which of four jobs to run first. You look at the postcode, the customer's tone on the phone, the age of the building, and the weather, and the answer arrives. That is pattern recognition built from thousands of repetitions. It has no steps. One tradesperson put it this way on r/Plumbing: "The checklist stuff won't save you as much time as you're hoping. A new hire is going to run every job slower than you for the first couple months even with perfect SOPs, because half of what makes you fast is stuff you've internalized and can't write down. I'd plan for that instead of expecting the training doc to make them instantly as efficient as you." The mistake is not writing the documents. The mistake is the expectation attached to them. Owners who expect the SOP to buy speed get three months in, see output still below their own, and conclude the documentation was a waste. They stop maintaining it. Then a year later someone leaves and the knowledge leaves with them. The person being trained often feels the same gap from the other side. On r/Construction, someone trying to step up into more responsibility described it plainly: "So even if he wanted to hand more over to me, I’d probably struggle because I don’t always have the context needed to make decisions or take ownership properly." Note what is missing there. Not instructions. Context.

Split the work into two layers before you write anything. Documenting the wrong layer is how SOP folders go stale. Transferable, and worth writing: the sequence of what happens and in what order; the standard for what done looks like; the inputs you need before starting; the handover points covering who gets told and when; and the five exceptions that go wrong most often. Tacit, and only trainable through exposure: which job to bump when three are urgent; reading whether a customer is about to become a problem; pricing a job that does not match anything you have quoted; knowing a quoted fix will not hold and saying so; and deciding when to break the process. The transferable layer is genuinely writable and worth the hours. It is also the layer that survives a resignation. The tacit layer moves a different way. It moves by exposure, by being asked to make the call and then having the call reviewed, and by hearing the reasoning behind decisions rather than the decisions themselves. That is not a document. It is a review habit. The plumber who started the same r/Plumbing thread was already using that convention in his own setup: "Detailed procedures live in **SOP / training docs**, not in the checklist". Two artefacts, two jobs. The checklist is used during the work and stays short. The SOP is read before and after the work and holds the detail. Merging them produces a checklist nobody opens because it is too long to use mid-job.

Set the expectation before the hire starts, not after you are disappointed. A shape worth planning around, offered as an illustration rather than a measured benchmark, looks like this. Weeks one to four, the new person shadows and completes simple jobs with review. Output is negative. You are slower than you were alone. Weeks five to twelve, they run standard jobs solo, and you are checking outcomes rather than watching the work. Output approaches break-even. Beyond three months, they handle the standard book of work and you start seeing real capacity back. The judgement calls still route to you for longer than that. The exact numbers vary by trade, complexity and prior experience. The shape does not. There is a period where hiring costs you time, and it is worth budgeting for it deliberately rather than assuming it away. Two consequences follow. First, do not hire the week you are drowning. The trough makes drowning worse. Hire when you are busy but functional. Second, measure the right thing during the ramp. Jobs per day is the wrong metric for a new person. Rework rate, callbacks, and whether the standard was hit are the right ones. Speed comes on its own once the work is correct.

This is the fear that stops owners documenting anything, and it is a fair one. The same doubt shows up in the person doing the training. From r/HVAC, a technician training a new starter: "I don't wanna tell the guy how to live his life, but I also don't wanna waste my time, as well as his, training him if he ain't gonna stick around when he's not gonna get what he wants." The honest answer is that some will leave. Documentation is what determines how much of what they knew stays behind. Build for departure from day one. That means the transferable layer lives somewhere shared, not in one person's head or their personal notebook. It means the job management system holds the record of what was done, so history survives the person. It means at least two people know how each recurring process runs, even if only one runs it. There is a counter-argument worth conceding. Over-documenting is a real failure mode. Owners who try to write down everything spend months producing a manual that is out of date before it is finished and that nobody opens. If a document has not been read in six months, it was not worth writing. Start with the three processes that break most often when you are not there. Write those. Stop.

Work in this order. One, a one-page job checklist per job type, covering sequence and standard only, living on the phone rather than in a folder. Two, a definition of done: photos taken, invoice raised, customer told what happens next. Leave this vague and the work comes back. Three, an exception list covering the five situations that go wrong most and what to do about each. This is where tacit knowledge becomes writable, because you have seen each one many times. Four, a review loop of fifteen minutes at the end of the day for the first month, dropping to weekly, where the new person explains their decisions and you correct the reasoning rather than just the outcome. Five, a single system of record, so jobs, notes and photos sit in one place such as your job management software and the knowledge attaches to the job rather than the person. Only three of those five are documents. The other two are habits. Systemising a business is mostly habits with documents attached, and the habits are the half that gets skipped.

Software helps with the transferable layer and cannot touch the tacit one. A tool can enforce sequence, block a job from closing without photos, send the customer update without anyone remembering, and keep the record when someone resigns. That is consistency, which is exactly what the written layer was buying anyway. Automating the checklist removes the failure mode where the checklist exists but nobody opens it. A tool cannot decide which job matters most today or whether a customer needs a phone call rather than an SMS. Anyone selling you that is selling you the thing you cannot buy. The practical implication is that the person who maps the process should be someone inside your business, not an outside consultant working from an interview. Process-mapping and diagnosis are the skills that carry. Building the automation itself is the easy half. That is the premise behind buildAutomation: train two or three of your own people to map, build and maintain the systems, so the capability stays when the contractor does not.

**Do SOPs make new employees faster?** No. SOPs make new employees consistent. Speed comes from repetition and judgement that documentation cannot transfer. A well-written SOP shortens the time to correct work and reduces rework, which eventually shows up as speed, but the first months will still be slower than working alone. **How long before a first hire pays for themselves?** It varies by trade and by the person's prior experience. Plan for a period where output is below your own and your admin load increases. Budget cash for that trough rather than assuming the hire is revenue-positive in month one. Measure rework and standards before measuring output. **What is the difference between a checklist and an SOP?** A checklist is used during the work and is short enough to actually be used. An SOP is read before and after the work and holds the detail, the exceptions and the reasoning. Keeping them separate is why both get used. Merging them means neither does. **What should I document first in a trade business?** The three processes that fail most often when you are not there. Usually that is job handover, invoicing and customer follow-up. Write the sequence, the definition of done and the top exceptions. Skip anything you have not needed twice. **How do I stop knowledge leaving when a staff member resigns?** Keep the transferable layer in a shared system rather than in someone's head, attach job history to the job in your job management software, and make sure at least two people understand each recurring process. Accept that judgement will still walk out and rebuild it through review, not documents. **Can software replace SOPs?** It can replace the parts of an SOP that describe sequence and required inputs, by enforcing them in the workflow. It cannot replace the reasoning, exceptions and standards that a new person needs to understand why the sequence exists. Use both.

Quotes are reproduced verbatim from public Reddit threads and attributed to the subreddit only. r/Plumbing: https://www.reddit.com/r/Plumbing/comments/1qdgh2t/solo_plumber_doing_200kyr_trying_to_systemize/ . r/Construction: https://www.reddit.com/r/Construction/comments/1u72dww/how_to_progress_to_being_a_pm/ . r/HVAC: https://www.reddit.com/r/HVAC/comments/1ujbltt/im_training_a_new_guy_and_im_starting_to_think_he/ . Evidence strength: moderate. These are recurring themes in trade and service owner discussions, not survey findings, and they are not specific to Australia. No statistics are claimed in this article.