Highlights
Passages saved from the original.
- shipping has to come first. You cannot have anything else as your top priority
- it’s really important that one person on the project has an end-to-end understanding of the whole thing: how it hangs together technically, and what product or business purpose it serves
- Good teams and companies understand this, and make sure every project has a single responsible engineer (typically this position is called a “technical lead” or “DRI” role). Bad teams and companies don’t do this, and projects live and die based on whether an engineer steps up into this role of their own accord.
- Shipping is a social construct within a company. Concretely, that means that a project is shipped when the important people at your company believe it is shipped.
- If you deploy your system, but your manager or VP or CEO is very unhappy with it, you did not ship. (Maybe you shipped something, but you didn’t ship the actual project.)
- If you ship something users hate and makes no money, but your leadership team is happy, you still shipped.
- First, you have to get clear on what the company is looking to get out of the project.
- they will be trusting you for estimates, to answer technical questions, and to anticipate technical problems. Maintaining that trust should be your top priority. If they don’t have faith in your ability to do the job and to keep them informed, you will not ship.
- an un-celebrated launch is not a ship!
-
- Communicate professionally and concisely, and don’t make them chase you for updates: post a daily or weekly thread somewhere
- It is much, much more important to do these things than for the project to ship with zero bugs on the exact deadline.
- If a project has to be delayed for technical reasons, in my experience you will not suffer consequences so long as you communicate it clearly, confidently (and ideally with some warning).
- your manager will be much happier going to their manager about it if they can say something like “our options are to delay four days, or ship tomorrow by sacrificing X” — even if sacrificing X is a non-starter.
- you have the most end-to-end context on the project, which means you should be the least scared of scary changes.
Summary AI-generated
Summarised by an AI assistant when this source was saved. Double-check against the original.
In summary, the most interesting aspect is that shipping in large tech companies is fundamentally a social and political achievement rather than a purely technical one; success is defined by leadership perception and proactive trust management, not just by deploying flawless code.
- Prioritize shipping above all else, including code polish and perfect UX; your primary goal is getting the project across the finish line to meet leadership expectations.
- Treat shipping as a social construct: a project only counts as "shipped" when key stakeholders acknowledge its success, so actively manage their perception through clear communication.
- Build unwavering trust with leadership by maintaining visible competence, delivering concise updates without being chased, and projecting confidence even under pressure.
- Anticipate technical and coordination bottlenecks early by keeping implementation time flexible (20–50%) to pivot quickly when unexpected issues or external dependencies arise.
- Deploy features as early as possible behind feature flags to surface hidden problems early and present leadership with concrete fallback options if delays become necessary.
Notes this inspired
- Shipping projectsGrowingfurther reading
It's not when it's deployed, it's when it's acknowledged by leadership and socially celebrated. If you ship something users hate and makes no money, but your leadership team is happy, you still…