Chances to get it right

This has been rolling around in my head for a while, and a conversation with fellow FLUX-ers spurred me to grapple with these ideas some more. Here’s somewhat rambling advice that emerged.

In the world of technology, there is this concept of shipping: the moment when we finally dot all the i’s and cross all the t’, and release the thing we’ve been working on to our intended audience. Shipping is a happy and stressful event for technologists, akin to parents sending their child off to college: we hope it will be okay, and can think of a thousand things why it might not.

At this threshold of shipping, all assumptions we’ve made face reality. Some of them will be right, and some–many!–will be wrong. We likely didn’t get everything right. Depending on how well we’ve guessed, we’ll see a range of outcomes. At one end of the spectrum, the scenario where we’ve gotten everything wrong. Our product flops entirely. At the other extreme is perfect success. Both extremes lead to easy next steps. It’s the middle that is muddy: if our thing only somewhat succeeds and somewhat fails, what are we to do next?

We need more chances to get it right. To navigate this muddiness, we find ourselves needing to engage in a delicate dance with our customers, trying to understand them. We make new guesses, see the customer react, adjust our thinking, and try again. Every guess is a chance to get it right.

This dance can be tentative and exhausting. The customer might be annoyed with us persistently getting it somewhat wrong. We might want to finish it already, wishing to move to other things. It can be exhilarating, surprising us with new opportunities that we couldn’t dream of at the beginning. It is these opportunities that make such a dance worth it.

If anything, we need to learn to anticipate this dance and look forward to it. We are better off maximizing the number of chances to get our thing right. To get there, we need two mindset shifts. 

🚃 Treat shipping as a process

First, we must view shipping as a process, not a single event. Just like with our kid going to college, we’re not even close to being done. If anything, shipping is the beginning of the next phase of our journey: the one where what we’ve built makes contact with the customer and upends our initial guesses. Similar to good parenting, the job changes, but it doesn’t go away.

This may seem obvious in the world of modern software development. Of course shipping is a process! However, our yearning for the sense of completion and predictability keeps getting in the way. Look at any shipping roadmap of the product. It might seem like a perfect depiction of the process, rather than an event: a lineup of milestones, planned out a few quarters ahead. But… Do these milestones look like a neat progression of features? If so, this is just a bunch of shipping events, stringed together.

When “shipping as a process”, milestones rarely line up neatly into a clear sequence of features on a roadmap. Instead, milestones are treated as trains that arrive and leave on schedule, and the contents of these trains are determined at their departure. Shipping as a process accounts for uncertainty. Some releases might have many features in them, and some might be mostly bug fixes. It is okay to hold a feature back a release, or remove it altogether.

 I’ve learned this lesson in the early days of Chrome. I don’t know how the team functions now, but in the early days, the whole “train on schedule” process was amazingly effective. The level of stress among engineers was low, and we actually had time to dig into why things we shipped worked or didn’t work – and crafted better software as a result.

No, we couldn’t show beautiful multi-year roadmaps of features – but I tend to think that was a good thing. Most of those roadmaps are fiction anyway, designed to alleviate collective angst over pervasive uncertainty. Life doesn’t lend itself to nice clear lines, and the less time we spend trying to line up our futures, the more time we have to work toward the future we want.

🔄 Close the gap between hypothesis  and test

Second, we need to actively work to reduce the gap between making a hypothesis and testing it. A useful framing here is the OODA loop: make sure that the speed of our testing of hypotheses matches the speed of the environment. If we plan to ship a product in a year, yet the space into which this product will ship changes every month, we are likely to be disappointed in the outcomes of our hypotheses.

Naturally, different technologies lend themselves to varying degrees of the wiggle room we have here. Hardware traditionally gravitates toward longer gaps between the initial hypothesis and its test. Software tends to offer more flexibility. Some markets are less forgiving in chance-taking than others. Make choices carefully here: sometimes it’s worth moving things to software to speed up to the OODA loop, or play in an adjacent, more chance-rich field to test things out.

Whatever choices we make, we are better off when we make contact with our customers as quickly as possible. Only they can inform us about the future direction of our technology and its potential. Only in cooperation with them can we build a product that actually works.

Instead of fretting to get it right the first time, opt for small, incremental releases whose main purpose is learning. Think about it as a series of tiny, controlled explosions in the combustion engine, rather than one Big Bang. Ship small things that build up to the big thing, not the other way around.

Learn to set user expectations low. Instead of large splashes and announcements, release quietly and improve quickly. View shipping as a marathon, where our customers are surprised by consistent improvements (“you know, I never thought of this, but <product> has grown to be really great”), not by a flash of dramatic discovery. Apply the principle of least astonishment liberally.

This stance will feel counterintuitive and wrong. We technologists love that visage of a single man on stage in a black turtleneck, blowing people’s minds. This is not what we need to optimize for. In fact, if we do, we will likely never get there. Instead, focus on maximizing the number of chances to get it right. Ship early and often, taking the time to observe and orient between each chance.