Nothing to Ship
All of us — including our parents, their parents, and their grandparents — grew up in a world where products were physically made and shipped.
In the first half of the 20th century, physical goods were the only game in town. They took thousands of hours to research, design, create, and package. Then they were literally put into boxes and shipped.
The product enhancement loop came around every year. The newest radio always had the latest vacuum tube.
By the end of the 20th century, we had digital software products. Their product iteration loop was still roughly annual, but the loop was starting to compress.
As software products became virtualized (cloud products), teams were able to ship updates much faster. Releases and fixes could roll out on a regular basis, compressing the iteration loop even further.
Today’s software ships with some of the fastest feedback loops ever. But even though people shipping physical and digital products are in two different worlds, they both still use the metaphor of “shipping things.”
Engineers “ship code.” Managers “ship product.” And everyone works to shrink the shipping loop.
But the environment that crafted the idea of “shipping things” is dissolving in the digital domain. And trapping ourselves in this ever-compressing loop of shipping things faster seems absurd. So, what we if imagine a new metaphor to replace shipping and loops?
To get beyond our current ideas, let’s consider a question: What if there’s nothing to ship?
Let’s play through today’s loop-shrinking trend and observe what happens as loops shrink away to something infinitely small. If you can, imagine a bunch of these iteration and shipping loops getting smaller.
Then smaller. And smaller yet.
Now, picture them disappearing entirely.
The system no longer looks like a bunch of loops. It looks more like a single flow.
Systems as Flows
When systems are viewed as continuous flows of updates, the shipping metaphor breaks down because a flow and its updates are always in motion (things are continually being shipped). Flows are constantly moving forward. This forward movement is the result of people and systems feeding updates into the flow based on the latest information—and updates are continuous, cheap, and reliable.
This might seem like semantics, but it represents a fundamental shift in our system thinking.
Tools, goals, and operations quickly diverge as we stop thinking in loops and start imagining flows. To get a sense of this shift, let’s compare two worlds.
Loop World
Loop World is dominated by the idea of shipping a thing at punctuated points in time. Improvements are shipped in these punctuated increments, and lots of work goes into shrinking the lapse between shipments. As a result, the “moment of shipping” is a critical juncture due to the large mental overhead associated with it (change is hard once something has shipped).
Loop World tends toward silos and segmentation—primarily because teams focus solely on their actions, and how their actions compress their portion of the shipping loop. The “need to compress” competes directly with the “need to get it right” before the important moment of shipping; trade offs ensue.
Borders abound in this world because team-specific tools focus each team in on itself. As such, an integrated system view is not valued. As long as loops are shrinking, borders don’t seem to be impediments.
Flow World
But in Flow World improvements are frictionless—continuous changes to an ever-evolving stream. The culture and its tools support the ideal of allowing any person to contribute to any flow at any time.
People understand that the idea of “improvement” will change in unpredictable ways, because it is impossible to know who can best improve the flow at some future point in time. As a result, their tools span both disciplines and teams, and interdisciplinary teams are fluid not only in composition, but also in the contributions they can make at any moment.
It is this shift in both how and when people contribute that blurs our ideas around teams, goals, and shipping entirely.
You see, Flow World has removed all Sacred Actions.
Sacred Actions
A Sacred Action is any action that limits any person’s ability to contribute to the flow at any point in time.
Any person. Any point in time.
This is quite a departure from what we’re used to. And therein lies the rub. Sacred Actions are not impediments in Loop World, because until people view borders as an impediment to further shrinking their loop, the system (let alone global, continual contribution to it) will be neglected.
A Better Question
Let’s look at a typical SaaS product (which can be seen as a flow of updates) and how the industry-wide goal of rapid deployment would seem flawed through a continuous flow lens.
In rapid deployment, learnings from task-specific teams are bundled into updates, which are handled by task-specific engineering teams. Sometimes, many updates even occur in a single day! This is the goal today, because it shrinks the engineering portion of the loop.
But through the lens of continuous flow, the idea of a single, task-specific team being the only team capable of updating the flow is more than a detrimental side effect. The inability of any person to update the flow at any point is a critical failure. There should be no “deployment” — no Sacred Action.
It should be as easy to update flows as it is to edit a Google Doc. And the most recent changes to a flow should be changeable with the ease of ⌘+Z.
Sure, today’s engineering teams can roll back the latest product release with some effort. But can someone on the design team? Can someone on the marketing team? And is the roll back as easy, reliable, and stress-free as typing ⌘+Z?
People thinking in loops will protest, “Why should anyone on the marketing team be able to update the live product?” A natural question when change is sacred, expensive, and worrisome. But when change is fluid, low risk, inexpensive, and continuous, a better question becomes, “Why shouldn’t anyone on the marketing team be able to update the live product?”
For years we’ve talked about slaughtering our Sacred Cows. Maybe it’s time to think about slaughtering our Sacred Actions.
Getting to Flow
We’ve been so scared of this “moment of shipping” that we created systems that now stand in our way of attaining flow. The barriers we’ve erected to make the moment a Sacred Action will now prevent the types of real-time, interdisciplinary collaboration that most companies talk about—but quietly wonder how they’ll implement.
It might seem counterintuitive that more people making more changes will result in a higher quality product and improved system. Then again, it would seem counterintuitive to suggest in 1990 that a crowd-moderated encyclopedia would be of greater depth and quality than Encyclopedia Britannica.
The need for new tools and process to support the emerging world of continuous flow is apparent. But in order for organizations to realize the many benefits that will come from working with flows, the guarantee and ease of the tools will have to be matched by an accompanying shift in mindset.
We need a change in both metaphor and modality, because blind reliance on outdated metaphors is becoming increasingly expensive over time.
So, the next time you consider updating a product or process, ask yourself if you’re embracing flow—or running from it.
—
Gavin shapes engineering and research within the IDEO CoLab.
