You get consistent, high-quality reports from junior engineers by putting a senior's questions where the junior is standing, not where the reviewer is sitting. The gap between a first-year's report and a senior's is rarely a writing gap. It is that the senior would have asked six more questions on site, and by the time anyone notices they were not asked, the engineer has left the building.
The cleanest example is a pipe. A junior writes that he saw a pipe, and carries straight on with the description. A senior reads that and immediately wants to know: what kind of pipe? Pressurised or not? Water or gas? Hot or cold? Sewage, or storm? What size? What make? None of that is writing skill. It is knowing what to interrogate, and it is the thing twenty years actually buys.
A capture problem, not a review problem
By review time the answers no longer exist anywhere. The reviewer can flag that the pipe was not identified; they cannot supply the answer, and neither can the junior, because nobody looked. That is what makes this expensive. A wording problem is fixed in the review. A missing observation is fixed by going back to site or, far more often, by quietly softening the finding until it no longer depends on the detail nobody captured. That second outcome never shows up as a problem. It shows up as a report that is slightly less useful than it should have been.
Move the senior's questions to the point of capture
The fix is the same whatever tools you use: get the senior's questions in front of the junior while they are still standing at the subject. The lowest-tech version works today: write the ten questions a reviewer asks most often on each report type, in the words a senior would use, and put them on the card or checklist the junior carries. The firm is better off with those questions written down than living in one person's head, whatever happens next.
Tenera Reports, our reporting tool, automates that habit. Reports are drafted from the engineer's narration and photos, and configurable buttons run against the draft while the engineer is still on site. Those buttons do two different jobs, and the distinction matters.
Completeness checks and elicitation are different jobs
Completeness is the self-audit: did you cover everything this report type requires? It reads the draft against what the template says a section must contain and points at the gaps.
Elicitation is the senior engineer's questions, asked automatically. The button is written to press on the things that get missed, so when the report says "pipe", it comes back asking which kind, what size, what pressure, what make. A junior gets pressed the way they would be pressed in review, except it happens while they can still go and look. Both are live today; elicitation is the one that changes the report, because it changes what gets captured.
The questions are your firm's questions
The questions are configured rather than built in. A button's instruction can be two sentences or three pages, and it is written for the firm. The same layer carries the firm's standing constraints, the terminology an insurer requires and the scope a discipline must stay inside; why those belong in the template rather than in a senior's memory is its own article on this blog. The narrower point here is that the follow-up questions your reviewers ask are firm knowledge in exactly the same way, and writing them into a button is what stops them living in whoever happens to review.
Experience spread is what makes this urgent
The problem tracks the range from EIT (engineer-in-training) to principal, and that range only exists at scale: a firm of forty has people in their first year, people in their tenth, and people who predate the current code. Senior engineers raise two things with us consistently. Juniors reach for consumer AI tools, which know nothing about the site and cannot be constrained to what was observed. And they want the same voice and quality from a first-year that they get from experienced staff. Those are the same problem viewed from two ends, and both are solved by moving the questions earlier rather than reviewing harder. Banning the consumer tools does not help on its own: a junior facing a blank page at 5pm on Friday wants help, and help that is constrained to what they observed, and that asks better questions, removes most of the reason to reach for something unconstrained.
A style guide does not fix it either, for the same reason the review does not: it addresses how the report reads, and the problem is what was never captured.
Write the ten questions down
Take your last five reports written by engineers with under three years' experience and mark every place you had to ask a follow-up question. Note how many could only have been answered on site; that subset is your real cost, invisible in every quality metric a firm tracks. Then write the ten questions down, in the words a senior would use standing next to the junior. The button asks the question; it never answers it. The junior looks, decides, and records. The reviewer confirms. The seal means what it always meant.
Run three reports against your own questions
Tenera's first 15 reports are free, with no time limit, so the trial costs nothing but the setup. Take the report type where junior work needs the most correction, write in the questions your reviewers ask most often on it, and run three reports. What you are measuring is the length of the first round of review comments, not the quality of the prose.