How I ship projects at big tech companies

Original Article ↗ Hacker News Discussion ↗

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.