Reasoning boxesthree days beforeThis story begins with the introduction of metacognition to large language models…
Separating cargo from the train
Limits of attachment and capacity are interlinked2021It felt both liberating and somehow odd to make a distinction between…
Continuously Integrated Strategy2022Here’s a possibly useful analogy when talking about strategy work with engineering…
No ship ums2023I’ve been thinking about the path that software dandelions take toward becoming…
Limits2022This story builds on the one I wrote a while ago, and…
I’ve been puzzling over a problem that many engineering teams face and came up with this metaphor. It’s situated in the general space of attachment and could probably apply to things other than engineering teams.
Dandelion/Elephant Strategy Rubric2022On the other hand, dandelions and the r-selected species they represent choose…
Micro and macro jank2021If our team’s OODA loop runs just a tiny bit slower than…
Jankless2021As we Orient, examining our prediction error and updating our model of…
Here’s the setup. Imagine that we’re leading a team whose objective is to rapidly explore some newly opened space. Everyone gets their little area of the space, and armed with enthusiasm and skill, the teams venture off into the unknown. A few months later, a weird thing happens: now we have N teams that build technology or products in basically the same space where they started.
Loops: dead or alive2022There are two important shifts to consider when examining a setting. The…
Instead of exploring, the team just settled into the first interesting thing they found. Exploration collapsed into optimizing for the newly found value niche.
The law of tightening aperture2023What happens to the teams with wide apertures over time? Does the…
Innovation frontier2023First, we need to know what our embodied strategy is. We need…
Questing, Scaling, Keeping2021The second kind of mission is scaling. Here, the team is asked…
This might not necessarily be a bad thing. If the new space is ripe with opportunities or the team is incredibly lucky, they might have struck gold on the first try. Except my experience tells me that most of the time, the full value of the niche is grossly overestimated, and the teams end up organizing themselves into settlers of a tiny “meh” value space.
Nudges, boosts, bumpers, and tilts2023Using these two properties as axes, we can draw a nice –…
Own the tension2021A couple of this week’s conversations about platform/product team interactions led to…
Why will this be hard for us?2021I was working on a strategy and helping review another this week,…
The events that follow are fairly predictable. There is a struggle between us and the individual team leads to “align”, where the word “align” really stands for “what the heck are y’all doing?! we were supposed to be exploring!!” from us and “stop distracting us with your silly ideas! we have customers to serve and things to ship!” from the sub-teams. The team becomes stuck.
Pace layers of predictability2023One thing that stood out to me was this notion of a…
I have seen various ways in which the resolution plays out. There’s one with the uneasy compromise, where the “exploration team” kayfabe is played out at the higher levels (mostly in slide decks), and the sub-teams are just left to do their thing. There’s one with the leader making a “quake”: a swift reorg that leaves the sub-team leads without a path forward. There’s one where a new stealth sub-team is started to actually explore (you can guess what happens next).
Aircraft Carriers and Zodiac Boats2024An insightful conversation with a colleague inspired me to articulate the distinction…
Build a thing to build the thing2023When building new products, there’s always a weird tension between making something…
Something will get optimized2021Complex adaptive systems tend to make it difficult to make guesses about…
The lens that really helps here is “something will get optimized”. When we have engineers, we have people whose literal job description includes organizing code into something that lasts. Like a car with unbalanced wheels, by default, engineers will veer toward elephant-land. Given no other optimization criteria, what will get optimized is the quality of the code base and the robustness of the technical solution that it offers.
The Breadboard developer cycle2024When the stakes in exploration are high, we tend to adopt a…
The problem is, when exploring, we don’t need any of that. We need messy, crappy code that somewhat works to get a good sense of whether there’s a there there. And then we need to throw that code out or leave it as-is and move on to the next part of the space.
Stages of project forking2023When we see a useful bit of source code, we start at…
This is not at all natural and intuitive for engineering teams. There are no tests! Not even a code review process! This dependency was made by a random person in Nebraska! Madness!
The Plumber Age2022This framing jumped out of a conversation with the fellow FLUX-ers and…
By the way, the opposite of this phenomenon is also true. If our engineering team does not have this tendency toward building code that lasts, we probably don’t have an engineering team. We might have some coders or programmers, but no engineering.
Nudging Embodied Strategy2022The whole concept of the cone of embodied strategy is a bit…
To shift an engineering team to be more amenable to exploration, we need to shift the target of the optimization.
Chances to get it right2023First, we must view shipping as a process, not a single event.…
That’s where the cargo-and-train metaphor comes in. Let’s pretend that an engineering team is the train that delivers a cargo: a thing that it makes. The thing about cargo is that once it is delivered, it leaves the train and the train gets new cargo. Train is permanent. Cargo is transient.

Cutting or highlighting?2021Talking with one of my wise colleagues, we arrived at this neat…
To make our train go efficiently, we optimize for moving cargo as quickly as possible, and we optimize for keeping the train in its best condition. Figuring out which part of our work we optimize to keep and which one we optimize to move is what it’s all about.
Forces of the pace layering confusion2021I had a super-insightful conversation this week with a colleague about approaches…
If we follow this metaphor, there are two questions that an engineering team needs to ask itself: “What is our cargo?” and “What is our train?” We need to consciously separate our cargo from our train.
The tension between growth and control2023I alluded to this tension before, but it was somewhat buried in…
Which part of our business do we optimize to let go of as efficiently as possible, and which part of it do we keep and grow?
For a typical engineering team, the cargo is the software release and the code base is the train.
Each release is the snapshot of the code base at a certain state. Once that release cut is made, we mentally let go of it and start on the next release. Releasing well means being able to make a release cut like a Swiss train: always on time, with no hiccups.
The rewrite count2021As a software engineer, I often see a struggle that both teams…
The codebase is the train, since this is where releases come from. Codebase is the place where the product grows and matures. Our codebase is what we keep and improve and strive to make better with time. Terms like technical debt we engineers invent reflect our anxiety about succeeding at this process.
When the engineering team is asked to explore a new space, the answers to the two questions are like different.
Development environment for rapid experimentation2023To set things up. I was looking for a way to enable…
It might very well be that the code we write is cargo. It’s just something we do as a byproduct of our exploration. We write a ton of prototypes, throw them in the wild, and see which ones stick.
Generating ideas and strategy coherence2022Here’s the thing. In software engineering (as likely in many technology fields),…
What is the train then? My intuition is that it’s knowledge. After all, the whole point of exploration is mapping the unknown. If our continuous delivery of cargo – writing of prototypes – doesn’t light up more and more territory, we’re doing something wrong.
Being Strategic2022It all begins with intention. There’s something in our environment – the…
So when an engineering team is asked to explore a new space, we need to contemplate the cargo-and-train questions carefully and decide on our answers to them.
Live as our customer2023This principle is something that feels very intuitive at first blush, but…
Then, we need to invest into making sure that everyone on the team optimizes for the right thing: the thing that we want to be our cargo is optimized to be delivered and let go of quickly, and the thing we want to be our train is carefully and lovingly grown and enriched with each delivery.
Gravity and water2023The first question is “what is our gravity?” This will take a…
Concept minerthree days afterHere’s a concrete example of a reasoning box that I’ve been talking…
This includes everything from mission and vision where the cargo-and-train questions are clearly answered, but also into culture, incentives, and structure of the team. Remember – most of the default engineering practices and processes were designed for default engineering teams. Which means that if we’re setting out to explore, they will be working against us.
Show 1 comment
Dew Drop – April 24, 2023 (#3928) – Morning Dew by Alvin Ashcraft linked here · April 24, 2023
[…] Separating cargo from the train (Dimitri Glazkov) […]