Loading post…
IntercomDarragh CurranExplainer
Shipping is your company's heartbeat
Summary
Software becomes valuable only when it reaches customers, because deployment starts the feedback loop that tests assumptions and enables the next improvement. The post argues that although software deployment can now take seconds or minutes, teams often retain habits from an era of infrequent, costly releases, making shipping itself a source of risk and delay. It uses time to production (TTP) as a technical and organizational lens: a one-minute fix can be tested, reviewed, merged, deployed, and communicated immediately, while hours, days, or weeks encourage waiting, batching, deploy windows, larger releases, and growing bug backlogs. Continuous shipping is presented as a company-wide practice that improves feedback, decision-making, customer responsiveness, momentum, motivation, and hiring, while requiring ongoing effort to reduce TTP and treat shipability as a design concern.
Context
The post connects deployment cadence with company behavior. Infrequent shipping increases risk, delays customer responses, encourages batching and larger releases, and turns small fixes into backlog items; frequent shipping creates faster feedback and more direct customer impact.
Approach / What changed
The proposed approach is continuous shipping: make deployment fast and automated, use tests and code review for confidence, merge and deploy small changes quickly, monitor for problems, and continually reduce time to production. The post also recommends treating the ability to ship as an important system-design concern alongside scalability.
Takeaways
Time to production changes behavior: a one-minute deployment supports immediate fixes, while delays of hours or more encourage waiting, batching, deploy windows, and postponed customer communication.
Infrequent, larger releases increase risk because unrelated changes can require rollback after a fix has been reported as complete.
Continuous shipping extends beyond engineering by strengthening feedback, customer responsiveness, team momentum, motivation, and the ability to see work affect users quickly.
FAQ
How does time to production affect the way teams handle customer-reported bugs?
With very short TTP, a team can adjust a test and regex, review and merge the change, deploy it, and reply to the customer quickly. Longer TTP encourages waiting, batching, restricted deploy windows, postponed replies, and eventually bundling the issue into a sprint or backlog.
Why can infrequent shipping make software releases riskier?
Infrequent shipping bundles more changes into larger releases, increasing the risk that a separate change will cause a rollback. It also encourages teams to anticipate many needs up front instead of focusing and iterating on important ones.
What does continuous shipping require beyond automated deployment?
The post describes continuous shipping as an ongoing practice rather than a one-time achievement. Teams should keep shrinking time to production and consider the ability to ship alongside scalability when building systems.
Source and freshness
- Source
- intercom.com
- Published
- Added to Yomu
Summaries are generated from the original by a language model. Check the original before relying on it.
Keep reading
Related reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
The best engineering reads, once a week
One useful email. Unsubscribe anytime.