I have been thinking about ways lately, mostly because I seem to be having way-debates/conversations/misunderstandings multiple times a day on Twitter. I’ve also come to realize that using certain way-names like Agile, DevOps, Lean, etc. can lead to terribly unproductive exchanges. Few people share the same mental model, and some people are extremely vested in specific interpretations.
Talking WaysI’m also very passionate about the usability of ways and words (which is highly related to learning and service design). A lot of the “thought leader” chatter and maneuvering has absolutely NO bearing on the user population(s)
and better outcomes. It is theoretical masturbation, one-upspersonship, territorial marking, and thinly veiled marketing.
So, to better understand these dynamics, I brainstormed a bit on ways.
Some Thoughts On Ways
Way(s): Tool, method, methodology, framework, practice, skill, etc.
- Any way can be knowingly/unknowingly abused, misused, and/or misapplied.
- How a way is designed, taught, and introduced can improve/degrade its usability and impact.
- Every instance of applying a way becomes a new (highly local) way.
- Ways are built on many implicit and explicit assumptions and facts. The environment surrounding these assumptions and facts can change.
- Ways are experienced by the humans involved and impacted. Experiences vary. These experiences are an extension of the way.
- Ways are applicable within a partially explored universe of contexts.
- Gauging the applicability of a way to a particular context, often involves ways. Some ways are used (primarily) to select the “right” ways.
- Most ways are retroactively codified. The practice precedes the labeling.
- Most ways emerge from multiple earlier ways.
- Ways are constantly evolving, and spawning/inspiring new ways.
- When is a heavily adapted/modified way a new way? This can be a difficult (and contentious) question to answer.
- As ways evolve, they grow, divide, swallow up other ways, experience entropy, and shift original boundaries. Ways may cease being useful, relevant, or understandable/describable.
- Ways “in practice” may differ from ways “in theory” (for positive and negative effect). There is a constant tension between theory and practice.
- Ways practiced “to letter” may differ from ways practiced “in spirit”. The degree to which modifications are acceptable/encouraged/expected, can be unclear to different actors.
- Learning a way, often starts with learning a simplistic/prescriptive version of the way. There will likely be limits to the introductory version of the way.
- The simplistic/prescriptive version of the way will feel overly simplistic/prescriptive to experienced practitioners. The reductionist version also tends to predominate mainstream perception.
- Improving how we use ways involves adaptation and improvisation.
- We mix, match, and invent ways to solve complex problems.
- To use a way successfully, it isn’t always necessary to understand how/why the way works. But when things don’t go as expected, or we reach a local maximum, this knowledge can help.
- Two ways can achieve the same impact/effect when applied to the same problem.
- Learning, teaching, and adopting ways often involves ways.
- Most ways require some prerequisite knowledge and/or a prerequisite state.
- Ways overlap, contain, belong to, are shared by, reference, and are dependent on other ways.
- It can be hard to capture the “state of the art” of a particular way. Somewhere, the way has been up-leveled (frequently combined with other ways, and sometimes by accident).
- Ecosystems emerge around ways. The actors in these ecosystems have a range of complimentary, adjacent, and competitive needs. Way ecosystems also overlap, compliment, and compete.
- When demand is high, there will be financial incentives to sell, rebrand, repackage, re-invent, oversimplify, over-sell, and control ways. It can also be lucrative to shape the discussion on provenance, lineage, and “credit”.
- Individuals who anchor their careers around specific ways, will be biased to solve problems using those specific ways
- We seek ways that provide certain and “simple” fixes to our challenges. Easily solved problems will rarely provide the buyer/user with a competitive advantage (but may provide an immediate improvement)
- Ways that are widely sold and packaged will require a certain amount of standardization and simplification.
- A perfectly executed way may still result in failure. A poorly executed way may result in wild success. So that’s what I came up with. I am sure I’m missing a ton here. Any help is appreciated….