The ramp is long because nothing is written down
A new project engineer at a commercial contractor learns by asking. How do we number RFIs. What does this general contractor require in a submittal package. When do we notify on a potential change. Which cost codes do we use for this. Who approves a purchase over a certain amount. Every answer exists, and almost none of it is documented, so it is transmitted by interrupting someone senior.
The cost lands twice: the new person is slow, and the experienced person is interrupted. For a contractor trying to add projects, this is a hard ceiling on how fast the team can grow.
Capture procedures as a byproduct of doing them
Writing a procedure manual is a project nobody finishes. A more realistic path is to document workflows as you automate or standardize them, which you are doing anyway. Defining the change order capture process well enough to build it produces the written procedure as a side effect.
Add the client-specific knowledge that is currently tribal: per-general-contractor requirements for submittals, billing, and correspondence. This is the material new staff most often get wrong, and it is the easiest to record because someone already knows it and just needs prompting to say it.
Make the knowledge answerable
A documented process stored in a folder still requires knowing where to look. Once the material exists, making it queryable in plain language turns it into something a new engineer uses instead of an interruption. What is our process for submitting a change order to this general contractor is a question that should have an answer available at the moment it is asked.
Scope it to internal process and reference information, and be explicit about its limits. The system answers how the company does things. It does not make technical decisions, interpret contracts, or approve anything, and new staff should be told that clearly on day one.
Keep the mentor relationship, remove the repetition
This is not a replacement for mentorship. Judgment, relationships, reading a jobsite, and knowing when something feels wrong are learned from experienced people and nothing substitutes for that. What changes is the composition of the conversations. Senior staff stop answering the same procedural questions for the fourth time and spend that attention on the parts that require experience.
Measure the ramp honestly. How long until a new project engineer can run a submittal log unsupervised, draft an RFI that does not need rewriting, or prepare a billing package that is accepted first time. Those milestones are concrete, and improving them is worth considerably more than it costs.
Keep the reference material current
Documented process decays faster than anyone expects. A general contractor changes its billing portal, the company adopts a new cost code structure, an insurance requirement shifts. Reference material that is subtly wrong is worse than none, because new staff follow it confidently and produce work that has to be redone.
Give each area of the reference material an owner and a review date, and make correcting it the expected response when someone finds an error. The signal to watch is whether experienced staff are still being asked the same procedural questions. If they are, the reference is either wrong, incomplete, or hard to search, and it is worth finding out which.