It's 7 a.m. The trades are mobilized, steel is going up, and your phone rings from the site. The installer has a question, and how fast you answer decides what happens next. Answer in two minutes and you save him an hour of downtime. Let it roll to voicemail and that same question turns into a field decision made without an engineer, on half the information.
During execution your availability isn't passive. It's active. You check in. You ask if there are questions. You don't wait for the phone to ring after something's already gone wrong. That's the shift this whole lesson is about. You're done being the producer. Now you're the resource.
By the end of this lesson you should be able to be the resource the field depends on instead of the bottleneck it works around, evaluate any field change for what else it touches before you ever say yes or no, and turn a stack of redlines into an accurate as-built and a closed project folder.
Once the steel starts going up, your role changes. You're not producing the design anymore. You're the resource for the team building it. You're the architect of this solution, and you spent more hours thinking about this system than anyone else on the project. You know why the sorter is that model and not another one. You know why the accumulation zones are sized the way they are, what the speed calculations showed, and what margin got built in. When a field question comes in, that knowledge is what the installer or the controls team needs to get at. Quickly.
There's a lane, and you stay in it. The project manager owns the schedule, the budget, and subcontractor coordination. You own the design. Those are different jobs and both matter. When the schedule slips or a sub shows up short-handed, that's the PM's call, not yours. When a question is about why the system is built the way it is, or whether a change is safe to make, that's yours. Know which is which, and be excellent at the half that's actually your job.
Field move. If you can't answer a field question the second it comes in, then set a response-time expectation and meet it, instead of letting the call go to voicemail. Tradeoff: you're now committing to call back on a clock while you're already buried in something else. Verify: watch how many engineering decisions the field makes without an engineer once they know exactly when they'll hear from you. It drops.
A handful of situations come up on almost every job. None of them are exotic. What separates a two-minute answer from a half-day scramble is whether the design lives in a folder you can open, or only in your head.
Notice what makes you quick in all three. It isn't memory. It's the folder. The setpoint arithmetic itself isn't your work here; that math is Lesson 20 and Lesson 25. During execution you retrieve it and confirm it. You don't re-derive it under pressure on the phone.
No project gets built exactly as drawn. Field conditions, a structural surprise, equipment that shows up a little different from spec, a customer request during install: all of it produces changes. When a change comes in, you don't just approve it and update the drawing. Your first question is never yes or no. Your first question is: what else does this affect?
A change to one section never happens in isolation, because the drawing connects everything. A two-foot position shift can move curve geometry, accumulation zone length, sensor placement, and pull-cord spacing at the same time. So you evaluate every change for downstream impact, you document the evaluation, and if the change has consequences that need design work, that design work happens before the field proceeds. Any change that touches scope, cost, or schedule becomes a formal change order, and any verbal approval gets written confirmation behind it.
A structural column is in the way of the conveyor run as drawn. Moving the run eighteen inches clears it, and the installer wants a yes. Before you answer, list every element of the system those eighteen inches might touch. When your list stops growing, ask yourself whether you found them all, or just the obvious ones.
Here's the question set. Every change type has its own first question, and not one of them is "can you do it."
| Change requested | The question you ask first |
|---|---|
| Equipment position moved | Does this force changes upstream or downstream too? A position shift rarely stays local. |
| Conveyor model substituted | Does the substitute match the speed range, the weight capacity, the zone length, and the roller centers the product needs? |
| Sensor relocated | Does the new position still give correct detection for the PLC delay the timing depends on? |
| Setpoint adjusted at startup | Was the original speed set to a throughput target? What happens to rate if it moves? |
| Safety device relocated | Does the new location still give required coverage, and can operators still reach the pull-cord? |
The engineer owns the installation drawings, the as-builts, and the review of every redline from the field. When a change gets made out there, it's my job to know what else that change touches and weigh that against what they're asking for. A change to one section never happens in isolation. The drawing connects everything. So before I approve anything, I think through the downstream effects, and then I capture what actually got built in the as-built. That as-built is a legal document. Five years from now, when the customer wants to expand, somebody designs from it. If it doesn't match reality, they're starting from a lie.
Letting redlines die on the clipboard. Redlines that stay in the field never become as-builts, and an as-built that doesn't exist can't be referenced when something fails or when the customer expands. Collect them at every visit, not at the end. Process them right away. The project isn't complete until the drawing reflects what was actually built.
A redline is a markup someone in the field makes on a printed drawing showing what changed from the original design. Redlines aren't a sign the design was wrong. They're a normal part of construction. The discipline is capturing them accurately.
Govern them on a cadence. Collect redlines at every site visit, not just at the end. Process them right away, because a redline that stays on the installer's clipboard never becomes an as-built. Your job is to review every redline, decide whether the change was within design intent, update the drawing to reflect what was actually built, and produce the as-built set.
As-built drawings are legal documents. They represent what got built, not what was originally designed. A customer who wants to expand five years from now works from the as-builts. If those drawings don't reflect reality, the expansion design starts from a false premise, and that isn't the next engineer's fault. It's yours. One thing this stage is not: proving the system runs. Confirming the WMS handshake and the setpoints hold under real load is commissioning, and that's Lesson 34. Here you capture what got built. Lesson 34 proves it works.
The project isn't complete when the system runs. It's complete when the folder is closed. The MHA Project Checklist walks the close, and every line on it protects either the customer or you:
The maintenance handover, the O and M documentation, the spares, and the customer training belong to the close too, and Lesson 34 teaches them. Here's the standard for a closed folder: another engineer can open it and understand the full history of the project without asking you a single question.
A field change comes in on the Riverside install. During installation the crew finds the horizontal run off the mezzanine edge is obstructed, and the mechanical installer wants to shift where the powered decline lands on the ground floor to clear it. Your first question isn't yes or no. You run it through the change-impact matrix.
Shifting the decline landing changes the decline angle within the run you've got, which touches the tumble limit for the Tall Case, the 10 by 8 by 14 carton flagged back in Part II and Part IV for its high center of gravity. It moves the accumulation zone ahead of the merge. It shifts the sensor placement the PLC delay depends on. It changes pull-cord spacing along the new run. And it may bring the run closer to the forklift-aisle crossing Riverside's maintenance lead flagged.
Evaluate each one, document the evaluation, and decide what design work has to happen before the field proceeds. Don't run the tumble or gap math here; that arithmetic is Lesson 14 and Lesson 25. Today the skill is knowing the change reaches those calculations before you approve it. Capture the approved change as a redline headed for the as-built. Write the change-impact evaluation and the redline plan in your Riverside note.
This is Lesson 33 of thirty-five, and it's where the drawing you've built across the whole program earns its keep or doesn't. Every calculation, every selection, every callout you put on that drawing gets tested the moment steel meets floor. The build going live doesn't hand your work back to you. It hands you a new job: keep the design honest while the field changes it, and keep the record honest so the next engineer, or the customer five years out, can trust what's on paper. That's what the engineer still owns after the first bolt turns. The system belongs to the field now. The truth of what got built still belongs to you.