The best way to learn how to ship software effectively is to study companies that do it well. Let’s pull back the curtain on how real engineering organizations get products out the door.
Stripe: The API-First Approach
Stripe treats every internal system as if it were a public API. This isn’t just about documentation-it’s a fundamental way of thinking about dependencies.
What This Looks Like in Practice:
When Stripe’s Billing team needs fraud detection, they can’t just reach into the Risk Engine’s database. They must use the same API that external partners would use. This forces:
- Clear contracts: Every endpoint has a spec
- Thoughtful evolution: Breaking changes require migration paths
- Actual reliability: If your API is down, everyone notices
The result? When they launched Stripe Terminal (physical card readers), the hardware team could integrate without negotiating with every backend team. The APIs were already production-grade.
Spotify: Squads, Tribes, and Autonomy
Spotify’s famous model gets misunderstood. It’s not about the org chart-it’s about decision-making speed.
The Real Innovation:
Each squad owns their entire stack-from database schema to frontend. When the Discover Weekly team wanted to try a new recommendation algorithm, they didn’t need approval from:
- A “machine learning committee”
- A “database team”
- A “frontend architecture board”
They just shipped it. To 1% of users. Then 5%. Then everyone.
The catch? Each squad must also:
- Run their own on-call rotation
- Monitor their own metrics
- Fix their own bugs at 3 AM
Autonomy isn’t free. It costs ownership.
GitLab: The Handbook-First Culture
GitLab has a 2,000+ page handbook that governs everything from code reviews to expense reports. This sounds bureaucratic until you realize what it enables.
Before a Feature Ships:
When a GitLab engineer starts a project, they don’t schedule meetings to understand the requirements. They read the handbook merge request that proposed the feature. All the discussion is right there:
- Why we’re building this
- What we rejected and why
- What the success metrics are
The Power Move:
When disagreements arise, the default isn’t “let’s have a meeting.” It’s “make an MR to the handbook.” The best argument wins, and it’s documented forever.
This is particularly powerful for remote teams. Someone in New Zealand can influence a decision without being awake during “working hours.”
Netflix: Context, Not Control
Netflix managers don’t approve vacation requests. They don’t sign off on deployments. They don’t “greenlight” technical decisions.
How This Actually Works:
When Netflix was migrating to AWS, there was no “Cloud Migration Committee.” Instead:
- Leadership set context: “We need to scale globally, our data centers can’t keep up”
- Teams made decisions: Each service team chose their own migration path
- Outcomes mattered: If your service was slow or expensive, you fixed it
One team might choose containers, another serverless, another straight EC2. The freedom was terrifying and energizing.
The trade-off? Netflix only hires senior people. This model collapses if you need hand-holding.
Amazon: The Six-Pager and Working Backwards
Amazon banned PowerPoint. Instead, every significant decision starts with a six-page memo, written in full sentences, read in silence at the start of meetings.
The Working Backwards Process:
Before AWS Lambda existed, someone wrote this imaginary press release:
“AWS today announced Lambda, a compute service that runs your code in response to events and automatically manages the compute resources for you…”
Then they wrote FAQs:
- Q: What if my code takes 10 minutes to run?
- Q: What languages are supported?
- Q: How is this different from EC2?
Only after this “working backwards” document was solid did any engineer write code.
Why This Works:
It forces you to think about the customer before thinking about the implementation. Most failed products fail because they solve the wrong problem, not because of bad code.
Linear: The High-Velocity Mindset
Linear (the project management tool) ships multiple times per day. Their entire company-design, engineering, marketing-operates on a 6-week cycle.
The Cycle Structure:
What makes this work:
- No mid-cycle pivots: Once the cycle starts, scope is locked
- Cooldown week: Week 6 is for bugs, tech debt, exploration
- Shipping daily: Features go out incrementally, not in a “big bang” at cycle end
The founder’s rule: “If we can’t ship it in 6 weeks, we’re building the wrong thing.”
What We Can Learn
These companies are radically different, but notice the patterns:
- Clear decision rights - Everyone knows who decides what
- Written communication - Decisions are documented, not trapped in meetings
- Small feedback loops - Ship small, learn fast, adjust
- Accountability - The team that builds it runs it
- Context over process - Give people the “why,” let them figure out the “how”
The mistake is copying their structure. The wisdom is understanding their principles.
You don’t need squads and tribes. You need clear ownership. You don’t need a 2,000-page handbook. You need written decision records. You don’t need six-pagers. You need to think about customers before code.
How you ship matters more than what you ship. These companies prove it.