Language offers excellent opportunities to jam square pegs into round holes. But unless you're a poet or a salesman, doing that is probably not the best idea you've had.

1. Linking
Design and Action
How to Say what to Do
An archestra notebook.
© 2014 Malcolm Ryder / archestra research

2. “Do As I Say”
Communicating requirements effectively is, we usually agree, the first step in having execution
predictably generate the desired results.
In fact, the whole idea of “predictable” – literally, to “say beforehand” – presumes that people who
were spoken to understand what was being described.
So, we might say that when execution failures to “meet” requirements, the root problem is that the
understanding held by the speaker was not the understanding held by the listener.
The challenge of communicating requirements exists not only between customer and provider, but
also between manager and worker, or instructor and student, where the issues are about how to
make something correctly, and how to make something work.

3. Connecting the Dots
It’s easy to appreciate what happens when we try to make complex things without a “blueprint” or
some other instrument of design. The risk of failure easily outweighs the likelihood of a satisfactory
lasting result.
Bringing in an architect directly addresses the challenge of translating the idea of the desired result
into a reliable version of the desired result that can be produced.
Because of the effort of architecture and design, we presume that the version will not have missing
parts, wrong parts, or parts that don’t do anything. And because of that same effort, we presume
that the parts included and used are ones that unambiguously work together according to their
purpose.
So… when we are communicating, why is it that, despite the above benefit being common
knowledge, we so often skip that intermediate step of applying precision in selecting and
representing what is involved?
It’s an odd oversight that occurs in casual discussions (even amongst experts) but also in the most
important things that we try to do (even including strategy).

4. Crossing the chasm
Without deep drilling, we can appreciate that Strategy “communicates” through a Design for operations that
gets realized with Processes.
And, we can readily appreciate that not having a strategy can mean not having operational designs, and/or not
having processes that are clearly relevant to high-level goals.
We also find that a workgroup (of whatever size) may say or show what it calls strategies, designs, and
processes – even when these things are not actually getting connected to each other.
In other words, parties generate these things, because they think they are important; but, too frequently, the
connections between them go missing for one reason or another.
A frequent reason is because the things the workgroup shows as strategies, designs, and processes cannot
rationally be connected. They were not derived from each other, and/or not selected for each other, when put
in place.
An equally frequent reason is because the things being shown as strategies are not actually strategies; likewise,
some things are incorrectly being called designs or processes. The inability to correctly distinguish things by
type has led to using the wrong things in given circumstances, preventing proper alignment and co-operations.
When authoritative speakers repetitively call things by the wrong name, it decreases the audience’s
understanding of how things can work. This makes terminology itself a focal point that must not be ignored.

5. Taking a shot at solving it…
In this example as shown, common
terms are in a layout that is
logically hierarchical. In that
configuration, we can see that just
because something has a shape
does not yet mean it is organized;
that because it has a form does
not yet mean there is a pattern;
etc. To get from point A to point C,
you don’t skip point B.
Value Achieved
Guides
Action
Has Logic
Model
Method
Has Function
Template
Technique
Has Arrangement
Pattern
Process
Has Boundaries
Result
Form
Procedure
To Organize
To Shape
To an important degree, these separations are validated by two “normal” recurring
issues. (1) How do we build something? (2) If something stops working, what aspect of
it needs to be fixed? If you either have those responsibilities or teach them, you
cannot afford to confuse the distinctions that correctly answer those questions.
© 2014 Malcolm Ryder / archestra research
A great example of how we should
attack this problem is to examine
ways that we tell people how to do
something, including identifying
what they rely on to do it.

6. Herding the Cats
• With precision restored to the terminology, we can
understand that “strategies” generally refer to the
functional logic being applied against a goal; “designs”
generally represent the guidance that prescribes or
documents the arrangement of the functionality; and
“processes” generally refer to the activity that executes
the functions in an orderly arrangement of effort.
• That is, we can see which of the more specific terms
might reasonably “fall under” the cover of each of those
general ideas.
• The fact remains, however, that such generic references
are inadequate to key efforts such as development,
management, support, and evaluation; and what will
make matters even worse in those efforts is arbitrarily
or poetically using individual terms as synonyms for the
generalizations, instead of as pointers to important
specifications.
When authoritative speakers repetitively call things by the
wrong name, it decreases the audience’s understanding of
how things can work. This makes terminology itself a focal
point that must not be ignored. A limited vocabulary,
carefully distinguished, provides its own best argument for
being used consistently. It’s hard to understand how blurring
the distinctions “adds value” to discussions that ask for
serious attention to the subject. The two most notable
exceptions have reasons for being less precise: (1) starting to
lead an audience from words it already likes to use, to a
correct understanding, and (2) marketing, where the
objective is to appeal to whatever already seems attractive.
© 2014 Malcolm Ryder / archestra research

7. Making complexity safe
Architectural complexity is a great reflection of how we
eventually see the whole problem to solve. It becomes
evident that when we are building a given complex
structure, or a given complex statement, we may use and
cross multiple dimensions of references.
(control)
(operation)
So for example, we can see that “construction”,
“operation” and “control” are different dimensions. It can
be that a technique in control is dependent on a process in
operations, and that the process in operations is
dependent on a method in construction.
What we do not want to see, in execution or in
explanations, is those distinct factors being mistaken for
each other, nor being referenced without context
(dimensionality). In our example, the need for a “method”
in construction is not a specified need for a “method” in
control.
The inability to maintain this kind of clarity is a leading
cause of failures in explanations and execution.
(construction)
A given result may require precision in different dimensions
of its composition. The composition may require that
certain relationships across dimensions be supported, such
as an action in one dimension being a “constraint”,
“prerequisite”, or “cause” of an action in another dimension.
© 2014 Malcolm Ryder / archestra research

8. © 2014 Malcolm Ryder / archestra research
www.archestra.com