How I ship projects at big tech companies
The most common error I see is to assume that shipping is easy. The default state of a project is to not ship: to be delayed indefinitely, cancelled, or to go out half-baked and burst into flames. Projects do not ship automatically once all the code has been written or all the Jira tickets closed. They ship because someone takes up the difficult and delicate job of shipping them.
That means that in almost all cases, shipping has to come first. You cannot have anything else as your top priority.
Shipping is a social construct within a company.
Engineers who think shipping means delivering a spec or deploying code will repeatedly engineer their way into failed ships.
I think a lot of engineers hold off on deploys essentially out of fear. If you want to ship, you need to do the exact opposite: you need to deploy as much as you can as early as possible, and you need to do the scariest changes as early as you can possibly do them. Remember that you have the most end-to-end context on the project, which means you should be the least scared of scary changes. Everyone else is dealing with more unknowns and is going to be even less keen to pull the big lever.
While shipping in a large organization is more complex and difficult than in a small one, all the facts stated in this article apply to every software developer trying to ship, and the solutions Sean posits ring true as practical and actionable.
Have courage! indeed.