How I ship projects at big tech companies
Shipping software in large tech companies is portrayed as less about deploying code and more about persuading leadership that a project is “done,” emphasizing internal marketing, optics, and stakeholder management over purely technical milestones. Commenters split between seeing this as an honest, useful primer on how to get work recognized in big organizations and condemning it as cynical careerism that prioritizes pleasing executives over serving users. The exchange surfaces broader tensions around office politics, the blurred line between engineering and project management, and whether accepting these dynamics is pragmatic realism or a betrayal of professional ethics.
What “shipping” means in big companies
- Many agree the article correctly frames “shipping” as a social construct: a project is “shipped” when the important people believe it is.
- This definition is seen as accurate but often depressing: shipping can mean leadership is happy even if users hate it or never see it.
- Several note this aligns with performance review reality at large orgs: visibility to leadership often matters more than pure technical success.
Optics, internal marketing, and stakeholder management
- Strong theme: “optics” and internal marketing are unavoidable in big companies.
- Suggestions include demos at all‑hands, internal blog posts, metrics dashboards, and recorded walkthroughs to make work visible.
- Some frame this as honest “internal marketing”; others see it as “keeping up appearances,” but still necessary to have impact or get promoted.
Project/tech lead role and project management
- Broad agreement that successful shipping usually depends on one person with end‑to‑end understanding and obsessive ownership.
- This role is compared to architect, lead developer, project/release manager, or tech lead, often combining technical depth with logistics and people work.
- Commenters note many teams lack real project management discipline (risk planning, dependencies, slack in timelines), which makes shipping harder.
Ethics, users vs leadership, and enshittification
- Heated debate over whether prioritizing leadership happiness over user outcomes is ethical.
- Some argue your “customer” is whoever pays you; others stress a duty to real end‑users and to avoid harmful or deceptive releases.
- Examples like enshittification and large corporate failures are cited as outcomes of optimizing for leadership optics over user value.
Culture, careers, and alternatives
- Split between those who accept “the game” as necessary for salary and advancement, and those who reject it as corrosive and prefer smaller companies or indie work.
- Several note that big‑company dysfunction can persist for years; others argue market forces eventually punish misalignment with customers.
Tactics and practices mentioned
- Favor MVPs, frequent deploys, feature flags, safe rollouts, and clear rollback paths.
- Maintain simple architectures and strong monitoring to keep “path to production” clear.
- Invest early in understanding why the project exists, what success metrics are, and who the real decision‑makers are.