During my first year as a project manager at Ford, a corporate training put us through a competition to build a project schedule. I did terribly. I was eager, I was confident, and I got it wrong in most of the ways an inexperienced PM gets it wrong. I spent the years after that leading large projects, and from where I sit now I can see every mistake I made in that room.
The biggest one was treating speed as the goal. Going faster is the easy part of a large project. Knowing what to slow down on is the hard part, and it is the skill that separates an experienced leader from someone managing a schedule.
Speed gets the praise, and on most work it earns it, because faster usually is better. The calculus changes on the largest, highest-stakes systems. On a small job, a fast decision that turns out wrong is cheap to undo. You catch it, you fix it, you move on. On a large, high-stakes system with a hard deadline and no room to slip, the early decisions are the expensive ones, because everything downstream is built on top of them. A rushed infrastructure choice, a rushed assumption in a coordination meeting, or a design call made only to keep the schedule moving will not stay small. They compound, and you pay for them near the end, when there is no time left to absorb the cost.
The answer is not to slow the whole project down. Schedules are real and clients are watching. The skill is knowing which few decisions deserve to be slow while everything else runs fast. Experienced leaders spend their judgment on the handful of choices that lock in the rest, and let the team move quickly on everything that is genuinely reversible.
The young PM who failed that scheduling exercise thought the job was speed. The lesson took years to learn. Knowing where to apply the brakes is the rarer skill, and it is usually the one that determines whether the system works on opening day.