Dimitri Glazkov

Beyond pros and consfive days beforeAmong engineers and product managers, a pros and cons document is a…Chances to get it right

· 5 min read

How to think and what to think2023Suppose you have invested a bunch of time into studying a problem…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.

The rewrite count2021As a software engineer, I often see a struggle that both teams…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.

The gifts of failure2023I may have written about this before. It’s a trick that I’ve…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?

Being Strategic2022It all begins with intention. There’s something in our environment – the…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.

Touching infinity2022As we explore the process of understanding, it may not be immediately…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.

The third option2024The deeper insight here is that we are surrounded by polarities. Behind…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.

No ship ums2023I’ve been thinking about the path that software dandelions take toward becoming…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.

Separating cargo from the train2023For a typical engineering team, the cargo is the software release and…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.

Stages of project forking2023To give you an example of this progression, here’s an abbreviated (and…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.

Generating ideas and strategy coherence2022Here’s the thing. In software engineering (as likely in many technology fields),…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

The ODA and OODA stances2023The OODA stance discards the idea of perceiving the environment directly. Instead,…OO and DA2021Each presents two different configurations for the OODA loop: I’ll call them…The OODA Loop2021One of the lenses for which I tend to reach frequently is…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.

Why AI orchestration2023Getting to that next gate has little resemblance to the maturation process…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.

Live as our customer2023This tension grows stronger if the difference between the environments is large.…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.

Aircraft Carriers and Zodiac Boats2024An insightful conversation with a colleague inspired me to articulate the distinction…Dandelion/Elephant Strategy Rubric2022On the other hand, dandelions and the r-selected species they represent choose…The Layering Principlesix days afterPreference toward layering is probably one of the more fundamental principles of…Development environment for rapid experimentationlinks here, 2023The first question on my mind was that of the developer ecosystem.…Build a thing to build the thinglinks here, 2023There are typically two forces that create this tension. First, therse’s the…Doers, Thinkers, and Magicianslinks here, 2023Let’s suppose that you and I are spinning up a new developer…The Bootstrapping Phaselinks here, 2024I think I have a slightly better way of describing a particular…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.

Show 3 comments
  1. Development environment for rapid experimentation – Dimitri Glazkov linked here · June 5, 2023

    […] was on my mind was the developer ecosystem. To unlock fertile learning through testing the waters, prototypes need to ship. They do not have to ship as polished products with firm SLAs, but they do need to reach some users […]

  2. Build a thing to build the thing – Dimitri Glazkov linked here · August 3, 2023

    […] expeditiously and engage the customers. This might come from the intention to maximize our chances to get it right, but also could just be a business […]

  3. Doers, Thinkers, and Magicians – Dimitri Glazkov linked here · October 12, 2023

    […] We have a fledgling developer surface that we’re rapidly shaping and growing, and trying to to get it right by making contact with its intended […]