SHIP / SHOW / ASK: A PRAGMATIC APPROACH TO TAKE TECHNICAL DECISION
In software projects, making technical decisions is often a major challenge. Who decides what? When should the team be consulted? Which choices should be validated by peers or managers?
To address these questions and streamline decision-making processes, Martin Fowler introduced the Ship / Show / Ask concept. This approach aims to structure technical decisions effectively and collaboratively.
1. What is the Ship / Show / Ask model?
The Ship / Show / Ask model is a method for classifying technical decisions into three main categories:
• Ship: Decisions you make and apply directly.
• Show: Decisions you make and then share with the team, either for information or potential feedback.
• Ask: Decisions for which you seek input from colleagues or managers before taking action.
Ship (I decide and act)
The developer or team makes a decision quickly and implements it without prior validation. This generally concerns decisions with low impact or within a controlled scope.
Examples: • Choosing a variable name. • Rearranging code without changing its behavior. • Fixing a minor bug.
Show (I decide and share)
The decision is made by the team or developer, but it is communicated for transparency and potential feedback.
Examples: • Performing a more significant refactor. • Modifying the structure of a module. • Adding a minor dependency.
Ask (I consult before acting)
Some decisions require prior consultation because they have a broader impact, are complex, or carry significant risks.
Examples: • Changing a key software architecture. • Introducing a new technology. • Modifying development practices or team processes.
2. Why adopt the Ship / Show / Ask model?
This approach addresses several common challenges in software projects:
a) Avoid unnecessary bottlenecks
By distinguishing between simple and complex decisions, it allows developers to take initiative without waiting for unnecessary validations.
b) Foster communication and transparency
Important decisions are systematically shared with the team, which prevents surprises and promotes collective alignment.
c) Empower developers
The model encourages developers to make autonomous decisions where possible, strengthening their sense of responsibility.
d) Reduce conflicts and misunderstandings
Thanks to the clarity of the categories, everyone understands what should be discussed in the team and what can be decided individually.
3. Implementing the Ship / Show / Ask model
Adopting this method requires some organizational and cultural adjustments.
a) Define the boundaries between Ship, Show, and Ask
Each team needs to agree on the types of decisions that fall into each category. For example: • CI/CD configuration changes could be classified as “Show.” • Major architectural changes are often classified as “Ask.”
b) Use appropriate tools
• A dedicated Slack or Teams channel for technical decisions. • A centralized documentation space for “Show” and “Ask” decisions (e.g., ADR – Architecture Decision Records). • Systematic code reviews to facilitate the sharing of technical decisions.
c) Build a culture of trust
The model works effectively when developers feel responsible, and the hierarchy trusts them to make relevant decisions within their scope.
4. Concrete application examples
Let's consider an example of a team developing an API.
• Ship: A developer chooses to optimize an SQL query by slightly modifying its structure.
• Show: The team decides to restructure the endpoints to improve route readability, and sharing this in documentation is sufficient.
• Ask: Before adopting GraphQL instead of REST, a collective discussion is held to assess the benefits and risks.
5. Benefits and limitations of the Ship / Show / Ask model
Benefits:
✅ Reduces bureaucracy by avoiding unnecessary meetings.
✅ Strengthens developer autonomy.
✅ Promotes collaboration and transparency.
Limitations:
⚠️ Risk of confusion if categories are not well-defined.
⚠️ May require a cultural shift, especially in highly hierarchical organizations.
⚠️ The balance between “Ship” and “Ask” may vary depending on the team's maturity.
6. Conclusion
The Ship / Show / Ask model is a pragmatic approach that helps manage technical decisions more effectively within development teams. It promotes autonomy while ensuring transparency and communication.
To successfully implement it, it's crucial to establish a climate of trust and clarify the rules for each category. By adopting this model, teams can streamline their decision-making process and focus more on delivering value.