Features feel like Fashion. Some come and go. Some stick around. Regardless, they are small. They move quickly.
Features are useful because of how they enable rapid exploration, trend setting, and quick adaptation to meet people’s very real needs. However, they’re not all there is.
Capabilities feel more like Commerce. You have to zoom the timeline further out to see them come and go. They are much larger, and they move much more slowly.
From a feature level perspective, capabilities feel fixed, just assumptions to be factored in. They’re also often ignored, since feature-level work might never travel beyond the bounds of a single capability.
(The above image is from Pace Layering, a concept by Steward Brand.)
Thinking in Timespans
Features and capabilities move at different paces. Features are faster, with shorter feedback loops, and that means cause and effect is more obvious. Meanwhile, capabilities are slower, with longer feedback loops. That means there’s more opportunity for an otherwise clear connection between cause and effect to get muddied by noise.
This idea is something Jabe Bloom calls “temporal complexity.”
(The above video is from Jabe’s talk, Whole Work: Sociotechnicity & DevOps.)
Temporal complexity is a quick way to get introduced to another idea Jabe discusses, timespans. I have to skip over some of the detail here, but in conversation with Jabe, he describes it more or less thusly:
Everyone gets about 10 minutes to explain what they do. When people who work at short timespans (little temporal complexity) explain what they do, they tell stories about work and accomplishments where the feedback loop closes quickly. “I answer phone calls, write software, attend sprint planning meetings, etc.”
When people who work at longer timespans (with greater temporal complexity) explain what they do, their stories are different. They talk about work and accomplishments where the feedback loop closes over a longer period of time. “I make sure we meet our quarterly goals, make sure we hire the right folks, and keep our initiatives on track.”
When I’ve pressed Jabe a little more on the subject, he also shares that you can find a similar kind of difference in the “size” of the things people talk about.
As he puts it, if you imagine every person can only hold 5 things in their mind at a time, and you ask someone who works in features to explain what they’re doing, then their 5 things will be small and fast. Ask someone who works in capabilities the same thing, and their 5 things will be bigger and slower.
He applies this to Wardley Mapping, in the sense that if you can only fit so many parts in a Wardley Map (say, 15), then the parts in a feature-level map will be smaller parts, while the parts in a capability-level map will be, well, bigger. Because they have to be, to fully describe the “bigger” timespan!
When two people with different-size things in their maps try to talk to each other, the timespans collide, and when they collide, they create all kinds of friction! As Jabe describes it, each person looks at the other and thinks, “They don’t make any sense at all. They must have no clue what they’re talking about.”
Here’s an example.
On the left is an example of a feature-level view. On the right, a capability-level view. The left-side map is entirely contained within the “intake form” component in the right-side map. (I haven’t said this yet, but I will now: You may assume that feature-level and capability-level are relative terms, not absolute. Imagine that I said “shorter timespan” or “longer timespan” instead, and you’ll start to get the picture. But that’s probably too confusing. So I use the f and c words instead.)
If your POV is entirely immersed in features (pens, questions, clipboards), it’s gonna be disorienting when someone comes along and talks about capabilities (intervention, diagnosis, interview), and vice versa.
The friction between timespans can quickly become a big problem because of what gets missed.
A feature-level view can easily miss slow-moving changes in capabilities that could bulldoze everything (no sense feature-ing inside a capability that has become obsolete, for instance).
Meanwhile, a capability-level view can easily miss fast-moving changes in features that could compromise the capability or signal a new direction for the future.
Translation Across Timespans
Jabe argues that what you need is translation… a “clutch” of sorts between timespans, to connect them together without so much friction that you start a fire.
In conversation with Jabe, we’ve discussed how the power grid offers us an analogy, where electricity is “stepped up” to a higher voltage after generation so it can be transmitted efficiently across great distances, and then it’s “stepped down” to translate it into lower voltages that the appliances in our homes can handle.
We think something similar can happen with Wardley Maps.
You can work upwards in timespans from the feature level, or you can work downwards in timespans from e.g., the capability level. (Again, these terms are relative, so… just substitute in whatever makes sense. Recently I’ve said “from the market level,” for example.)
Either way, the “up” or “down” is directional, towards “longer” or “smaller” timespans, and the goal is to create an intermediate layers of understanding that bridge the gap between the weird things the capability people over there say and the equally weird things the feature people say over here. Those layers form the clutch.
Mechanically, there are a couple ways to do this.
To move to a shorter timespan from the top down, all you have to do is increase the detail. Using the right-side map above, you can pick a component (like, “Diagnosis”) and just ask, “What’s inside here?” Name the 5 moving parts inside that component. That’s a layer. And if you need to go deeper, you can. Pick another part, and ask the same question. That’s another layer, translating downward into shorter timespans.
To move to a longer timespan from the bottom up is a little trickier, but it’s absolutely doable. Start by asking, “What are all these moving parts a part of?” In other words, sum up and simplify all the detail into just one or two components. For example, the left-hand side bottom-up move is to sum up all the parts as “Intake”, which appears on the right-hand map as a single component. Then you search for the peers of the one or two sum-up parts. You can find them by asking about dependency. “What does this big component depend on?” to go down the value chain. Or, looking upward, “What does it enable?”
I’m hand-waving a lot of the details in order to share this concept. Just remember that it’s relative, and that developing the clutch is a matter of moving in a direction: top-down (from big / lots of temporal complexity to small / little temporal complexity) or bottom-up (from small / little temporal complexity to big / lots of temporal complexity). There can be any number of layers in between to help translate in between. This seems abstract, but use the map above as a sort of guide. Left map to right map is bottom up, while right map to left map is top down.
If any of this is confusing, drop a comment and let me know. I decided to post something imperfect instead of letting it marinate in a google doc somewhere forever, to never see the light of day.
I love Pace Layering. The “zooming in” bit, of moving to shorter timespans, is something I see often enough: Product to Features to Tasks. But consciously zooming out, in the way you describe … seems like something I could do more often (and seems delightfully Long Now).