A thought starter
Consider your current project, or one your team is taking on. Whichever is the most recent, in its most active phase. For that project:
- How clear is what you're trying to achieve, and how well-drawn are the boundaries around it?
- When you speak about outcomes and success conditions, how well does everyone (and do you) understand what you're working toward?
Fuzzy? Clear? Muddy? Just a bit blurry?
More from Alexander
Back to our favorite architect, builder, designer, and carpet collector: near the end of The Timeless Way of Building, Alexander describes his ideal process for turning ideas into reality.
Once they agree about the language, the actual emergence of the form is simple and fluid. When a group of people try to do something together, they usually fail because their assumptions are different at every stage. But with a language, the assumptions are almost completely explicit from the start.
— The Timeless Way of Building, p.449
The language here is of a particular class, it's a pattern language. Pattern languages, implicit or explicit, are systems for encoding and generating architectural form, much like DNA encodes and generates biological form.
The hardest part of design in The Timeless Way is deciding on the major patterns to be used and the sequence in which they will be applied. When a team agrees on a language, then the form can spring forth naturally — like a sunflower from seed.
When Alexander says, “once they agree about the language,” he’s addressing both of the questions we opened with, through the same medium (and summarizing the prior ~400 pages on what that looks like.) The hard work of this agreeing is driven by features of a project's pattern language that concretize architectural assumptions and make them challengeable from the start.
To reach that explicit state, languages that guide design must encapsulate the scope of the structure to be created as well as the guiding feeling and behavioral events that dictate success. In each pattern, structure and events are bound together as two facets of the same unit. Through the act of selecting and adapting patterns — "agreeing about the language" — the group sets scope and achieves clarity.
Crossing the digital divide
That's all well and good, but we’re not building our products with pattern languages. Our understanding of the digital/behavioral structure we work with has not yet evolved into well-formed or shared patterns.
However, many small teams with good communication come to work as Alexander describes quite naturally, with an implicit and shared understanding of patterns in use. These evolve through critical discussion and shared attention, rather than any formal process or documentation.
I'm starting to re-examine one notable attempt at encoding a Timeless-like perspective for building products: Basecamp's Shape Up. It defines, selects, and adapts patterns ("shaped work") into projects. It also entails a product operating model at odds with the currently accepted norm in cadence, structure, and flow.
Seeing pieces of systems
Zoom out a bit further, and we see in Shape Up a new mode of framing, of working with portions of our internal/external product ecosystem, in an attempt to build more clarity and a more productive view of what we're trying to achieve. Getting this framing right is core to working well together.
Donella Meadows lays out the larger idea:
”There are no separate systems. The world is a continuum. Where to draw a boundary around a system depends on the purpose of the discussion—the questions we want to ask."
— Thinking in Systems, pg. 97
Alexander presses further. It's not just about bounding discussions; it's also crucial to identify the critical behaviors and interactions (patterns of events) at play.:
A system is an abstraction. It is not a special kind of thing, but a special way of looking at a thing. It is a way of focusing attention on some particular holistic behavior in a thing, which can only be understood as a product of interaction among the parts. Everything under the sun may be viewed as a system: a man smoking a cigarette may be viewed as a system; so may a leaf drifting in the wind; so may a brick; so may mankind on earth. But it only becomes a system if we abstract from it some special holistic property, which we cannot explain except in terms of interactions within the whole. Without a specific statement of what holistic behavior we have in mind, what interactions among what parts cause this behavior, and how they do so, calling a thing a system is no more than saying: “This is a pretty complicated thing, and I don’t understand it very well.”
— Systems Generating Systems (emphasis mine)
Potential for shaping
Everything works better when the people share a useful understanding of what they're trying to deal with. And most teams building products struggle with clarity in scope and success conditions.
I love a good method — it appears that parts of Shape Up really are good — and have to remind myself that method never does heavy lifting: the team does. It may give us tools for better boundaries and clarity of outcomes, and perhaps even point to a better way of building. But the team needs to be interested in doing that; and they need organizational support to get there.
Written documents, Figma files, OKRs, and metrics are only proxies for what we're trying to create. High signal communication and active navigation of interdependencies are required regardless of our method of choice.
I'm optimistic about Shape Up's pattern-like encapsulation to give better structure to our work. It offers the building blocks of a more natural, "agile" (in the lower-case sense), and sequential delivery like Alexander describes in The Timeless Way of Building.
I also have practical questions about shaping product cycles, division of work, org size/structure, and strategic coherence. I expect we'll explore these in upcoming editions.
Until next time—
This is Loops and Cycles, a mailing list exploring how we work together and make good things. Thanks for joining me here.
