profile picture

Ship, Show, Ask

Culture-Driven Collaboration at the speed of code

April 12, 2025 - 848 words - 5 mins Found a typo? Edit me
software team-work

cover

In fast-moving teams, one of the biggest tensions we face is this: How do we keep shipping without compromising quality or collaboration?

The traditional approach to pull requests often slows things down. We wait hours—or days—for approvals, even for trivial changes. But the alternative—just merging directly—can feel reckless or invisible to the rest of the team. That’s where the Ship-Show-Ask strategy comes in.

Originally described by Rouan Wilsenach, this model offers a more flexible and thoughtful way to handle code changes. It’s not just a branching strategy—it’s a shift in how teams collaborate, trust, and take ownership.


🧭 Content

  1. What is Ship, Show, Ask?
  2. Why I prefer to Ask and Show
  3. Why this approach works for me
  4. What makes a good "Show"
  5. Tips for making it work
  6. Final thought

❓ What is Ship, Show, Ask?

It’s a model that classifies changes based on how much review they require:

The key idea is to use Ask as the default for most work, fall back to Show when the context makes it safe, and avoid Ship (or reserve it for extremely trivial cases, if used at all).


🤝 Why I prefer to Ask and Show

In my experience, it helps to treat every change—even the small ones—as something worth sharing. I always create a branch and open a PR. It provides visibility, builds a shared history, and creates a space for optional or asynchronous feedback.

But not all PRs need to follow the same review process.

📝 I like to default to Ask

I prefer to wait for a peer review when:

That said, “Ask” doesn’t mean over-engineering the process. Often, one thoughtful reviewer is enough—especially if they’re familiar with the domain. If the change touches a specific area, I’ll ask for feedback from the person who owns (or best understands) that part of the code. It doesn’t need to involve everyone.

In small teams, requiring two approvals on every PR can quickly become a bottleneck and slow down the delivery of value. The goal is alignment and quality, not ceremony for its own sake.

⚡ I use Show for safe, low-impact changes

I might merge immediately when:


🔑 The Key Principle


🚀 Why this approach works for me

This model helps me:

It shifts the goal from simply getting approval to sharing intent and owning the outcome.


✅ What makes a good “Show”?

A Show PR might be the right choice when:


🛠️ Tips for making it work


💬 Final thought

Ship, Show, Ask is more than just branching hygiene.

To me, it’s about building a culture of clarity, accountability, and trust—where developers are empowered to move fast while staying thoughtful.

If you’re tired of slow PR queues and over-engineered approvals, this might be worth a try.

Curious to dive deeper? Check out Rouan Wilsenach’s post.

footer