Process vs. Sequence [LC02]

The work we undertake to design and deliver something well begins with a question, an idea, a problem, or an insight: call it point A. Each cycle that starts at A ends with a fix, a tweak, a revision, a decision to drop or defer, an update, a feature, a product sunset, a product line, or perhaps an entirely new product line: call it point B.

One skill that a product team must have, collectively, is moving from A to B successfully and efficiently. (I consider this motion one adaptive cycle in the path toward structural coupling.)

Rather than general processes, it's the sequence of steps we take in moving from A to B — specific steps, in specific order — that shapes the quality of our product outcomes.

Processes are abstract and function-oriented

It's easy to speak about the generic process before we understand the shape of the challenge at hand, and think it means we've got a handle on what's to come.

Design and UX are particularly wont to dip into the design process well. The double diamond and design thinking dominate the conversation, but Hugh Dubberly has a whole book describing different models of the design process (and I love it — it's a wonderful survey.)

Our processes may look something like this:

The problem, I contend, is that these extracted archetypes of work past serve more as totem than tractable direction. They don't offer contextual clues for how to proceed in a specific, individual initiative.

And they don't help us break out of the functional trap: they don't open the door to show us how our work fits into its larger context.

Sequence (decision order) is the key to process

The sequence of steps — decisions, methods, activities — is the ultimate, and concrete, expression of process

A healthy work sequence will evolve good ideas, prevent mistakes, avoid rework, and surface the tension and instability beneath bad ideas before it's too late.

Christopher Alexander describes the importance of sequence with an example in carpentry:

We may understand it best by comparing the work of a fifty-year-old carpenter with the work of a novice. The experienced carpenter keeps going. He doesn’t have to keep stopping, because every action he performs, is calculated in such a way that some later action can put it right to the extent that it is imperfect now. What is critical here, is the sequence of events. The carpenter never takes a step which he cannot correct later; so he can keep working, confidently, steadily.

The novice by comparison, spends a great deal of his time trying to figure out what to do. He does this essentially because he knows that an action he takes now may cause unretractable problems a little further down the line; and if he is not careful, he will find himself with a joint that requires the shortening of some crucial member – at a stage when it is too late to shorten that member. The fear of these kinds of mistakes forces him to spend hours trying to figure ahead: and it forces him to work as far as possible to exact drawings because they will guarantee that he avoids these kinds of mistakes.

The difference between the novice and the master is simply that the novice has not learnt, yet, how to do things in such a way that he can afford to make small mistakes. The master knows that the sequence of his actions will always allow him to cover his mistakes a little further down the line. It is this simple but essential knowledge which gives the work of a master carpenter its wonderful, smooth, relaxed, and almost unconcerned simplicity. — A Pattern Language (1979). Pattern #208 "Gradual Stiffening."

The novice exhibits a slow and uncertain pace: mistakes, rework, and general rigidity in methods and planning. The master exhibits a procedural understanding that allows for a steady pace: known tolerances, just-in-time decisions, a general fluidity in the flow of work. (Where does your team sit on this spectrum?)

The difference between the two carpenters implies that one aspect of expertise is understanding the natural or logical order of events in creating something.

Seeing the sequence in product work

It's easy to project ourselves and our individual expertise onto this spectrum. We can think of moving into mastery as a researcher running studies, a PM defining value propositions and managing stakeholder expectations, a designer creating well-considered prototypes, or an engineer crafting a robust front-end framework.

The larger concern, though — effectively moving A to B — is not solved by any individual, functional perspective. In modern product work, A might originate with an individual; reaching B is a feat of collective vision and orchestration.

For a small and healthy initiative, say scoping and launching a new product pilot, core decision flow may look something like this:

Especially for supporting/amplifying activities like research, the challenge lies in understanding the range of steps that need to be made along the way from A to B, and how to anticipate and support them properly, in proper order.

All the kinds of product work our organizations undertake — driving growth, launching new product lines, identifying ecosystem-level strategic trends, or improving the performance of existing products, for example — carry certain kinds of healthy and repeatable decision sequences.

Learning to orchestrate and operate good sequences is a necessary component of organizational growth.

This craftsman-like sensibility for sequence is also a place of power and individual leadership that anyone inside the organization can inhabit — so long as they are helping the team avoid steps that cannot be corrected later, helping the work move confidently and steadily forward.