You finished the program. That means you understand the methodology. It does not mean you're ready to run a project alone. Those are two different things, and confusing them is where a new engineer tends to slip in the first six months.
The methodology handles the technical part. What it can't hand you is the pattern recognition that only comes from repetition, on real projects, with real customers and real consequences. This lesson tells you what to expect in your first 90 days, what you don't do without a second set of eyes, and what good work looks like when you're doing it right.
By the end of this lesson you should be able to use your first 90 days on live projects to build the judgment the program can't give you, name the situations you don't run alone yet and the observable signs that you're ready, and know who to call and which habits to build from the very first project.
Treating a finished program as a finished engineer. Finishing means you know how the work is done. It doesn't mean you have the pattern recognition to do it unsupervised. That only comes from repetition on real projects. Treat the first 90 days as where you build it, not as a formality you've already earned past.
The first 90 days aren't about proving what you know. They're about building the pattern recognition the program can't give you. Here's what that stretch should look like, in three windows.
Days 1-30. Shadow and verify.
You're present on every site visit, call, and review you can get into. You're not leading. After each one you run the calculations yourself and compare your numbers to what the senior engineer produced. When you disagree, you find out who's wrong before the proposal goes out. Most of the time it's you. Occasionally it's them. Both teach you something.
Days 31-60. Lead the calc, shadow the customer.
You run the spec calc on live projects and present your numbers for review before they go into any proposal. You draft scope and limitations. A senior engineer checks your work before it leaves the building. You're still preparing questions and listening, not yet owning the customer relationship.
Days 61-90. Lead the project, support in the room.
You run your first project with a senior engineer available but not leading. You own the site-visit prep, the calculations, the scope, and the first draft of the proposal. The senior reviews before anything goes to the customer and is present on the first presentation.
By the end you'll know whether you're ready. Not because someone told you, but because you'll feel the difference between projects where you knew what to do and projects where you had to ask.
Some engineers pull ahead fast in their first year. The ones who do are the ones who ask specific questions. Not how do I get better at this. That gets you a general answer. I mean something like, I got a gap check failure on the sorter at twenty cartons a minute, I tried increasing the sorter speed, and then the takeaway spur spec went above catalog maximum, walk me through how you would approach that. A specific question like that gets you a specific answer you can actually use. Ask the small, exact question. It's worth ten of the big vague ones.
This isn't a list of things you can't do. It's a list of situations where the cost of being wrong is high enough that a second set of eyes is required first. You learned the math behind every one of these in Parts III through VI. The skill here isn't running the calculation again. It's recognizing the trigger and asking before you proceed.
If you're not sure whether a situation belongs on this list, it does. Ask first. The question costs you five minutes. Getting it wrong costs the firm a bad proposal and costs you credibility that takes months to rebuild.
Look at the do-not-run-alone list. Add one situation to it from your own worry, a place where being wrong would be expensive for a project you can imagine running. Name the situation, and name who you would call before you proceeded.
Readiness isn't about how long you've been doing the job. It's about whether you can do the work without needing to be caught. Here are the observable criteria. When you can say yes to all of them honestly, you're ready.
If you think you're ready to run a project solo, then say so, and bring specific evidence: which projects you ran, what you got right, and what you would do differently. Tradeoff: you're inviting a hard look at your own work instead of waiting to be told. Verify: the conversation either confirms you're ready or tells you exactly what's still missing, and both outcomes move you forward.
This is a framework. The categories don't change; the names in them belong to your organization, and your manager fills them in with you in your first week. Four categories cover the calls you'll make.
When a gap check fails and you're not sure which lever to pull. When the product mix is outside the range you've worked with. When a constraint shows up that the methodology doesn't clearly address.
Contact: ______________________
When a customer pushes back on scope or pricing in a way that could change the project. When a customer asks for a commitment you're not sure the system can meet.
Contact: ______________________
When a customer asks you to justify a line item, or a scope change lands after the proposal. Never estimate pricing changes without talking to someone who owns the numbers.
Contact: ______________________
When the WMS conversation gets technical and you're not sure the controls scope is being defined correctly.
Contact: ______________________
This is the starting version of yours. Fill in the categories now; fill in the names in your first week.
These are the practices that separate good solutions engineers from average ones. Build them in from the beginning, because they're harder to add later. The methodology handles the technical part. These handle everything else.
You've walked the whole journey now. Dana's voicemail in Part I. The product and the flow, the conveyance and the intelligence, the validation and the proposal, and in this part the handoff, the execution support, and a commissioned, accepted, serviced system.
So hold Riverside against the readiness criteria. Could you run that project solo today, from the first voicemail to a system that's accepted and running? Go criterion by criterion. Where are you ready, and where would you still ask? Then build three things: a readiness self-assessment against the five criteria, an escalation map filled in with your organization's real names, and a first-90-days plan.
The Capstone simulation is where you run the whole thing yourself, unscaffolded, from Dana's first voicemail to an accepted system. Riverside was the walkthrough. The Capstone is the solo. Now go run it.
Look back at the whole arc. Part I taught you to discover what the customer needs. Part II, to understand what they handle. Parts III and IV gave you the technology and the flow. Parts V and VI connected the machines and built the intelligence and the reliability in. Part VII turned the engineering into a proposal a customer could sign. Part VIII closed the loop: you released the drawing, supported the build, proved it worked, and handed over a system built to keep running after you left. Now run that arc the other direction, because the dependency cuts both ways. A single gap at any stage doesn't stay put: a missed discovery input becomes a wrong product envelope, a wrong envelope becomes an under-scoped BOM, an under-scoped BOM becomes a drawing released without the vendor calls, and that drawing becomes a change order out on the floor. One early defect compounds through every stage after it, and that's exactly why these aren't separate skills that happen to share a program. They're one interdependent system, and the chain is only as strong as its weakest stage. An engineer who can take a customer's problem all the way to an accepted, serviced system, and do it again on the next project, is what this program was built to produce.
I love this industry.
I love that no two projects are the same. I love that the problems are real, the stakes are real, and the solutions have to work in the physical world, not just on a screen. I love sitting across from a customer who has a problem they cannot solve and knowing that I have the tools to help them solve it.
What I love most is that sometimes the right answer is a complex, sophisticated system with multiple technologies, a full control architecture, and months of engineering work. And sometimes, after all that thinking, after running every calculator, stress testing every assumption, and walking the flow a hundred times in my head, the right answer is something elegant and simple. A system that solves a complex problem with the minimum number of moving parts, the minimum cost, and the minimum risk.
When I find that answer, when the elegant, simple solution is sitting right there and I can see it clearly, that is the best feeling in this work.
I have imagined myself sitting in the box riding through a system I designed, feeling every transfer, every curve, and every accumulation zone. When the ride is smooth, when there are no surprises, when it just works, that is what this is all for.
You just completed this program. You have the foundation. You have the frameworks, the calculators, the field knowledge, the key takeaways, and the professional habits that took me years to develop. Now go to the Capstone Project and use all of it. Then go find a real project and do it again.
The industry needs engineers who think this way. I am glad you are one of them.