(2024-11-02) Taylor For The Umarell In Your Life

Dorian Taylor: For the Umarell In Your Life. Further elucidation of my plan to run a “cozy private alpha” of my organizational cartography kit, the essay that got me calling it that, and a final installment from last year's Summer of Protocols.

my yet-unnamed organizational cartography toolkit, which will be the first tangible product running on top of the application server I designed called Intertwingler

The point of this tool (the first installment in the kit) is to analyze what the creator of its underlying conceptual framework called wicked problems, for the purpose of ultimately solving them

Catalogue every issue

as well as every position that responds with what, if anything, to do about a given issue,

along with every argument that supports or opposes a given position

I took an interest in this framework (it's called IBIS) all those years ago because I was concerned with the problem of project planning.

Namely, I found that accurate time estimates for software development depended on being able to wring out, as cheaply as possible, all the ways you could be taken by surprise. (pre-mortem)

to me the most exciting part is the ability to show stakeholders the path from concerns they have either personally voiced or are otherwise on record endorsing, to where the work is being done to address those concerns. Literally give them an entry point they can click through to see the accumulation of work product

Next time a grouchy client accuses you of not making any progress on a tough design problem, you can point to this thing and go “here”.
I have personally spent an absurd chunk of my career writing and presenting progress reports, and while I recognize that certain clients will always insist on being spoon-fed, a self-serve option will at the very least help me help them.

construction sites are self-documenting artifacts: hole goes down, building goes up. You can literally watch progress happening right in front of you. The Italians call the old guys who watch construction sites umarells, and a big goal of this tool for me is to create a construction site for the umarells to watch.

A final remark I'll make about this tool is that it was really important to me to make it not behave like “extra work”. Extra work is a surefire way for a tool to not get adopted. At root, this is just a networked, interlinked, collaborative note-taking device with slightly more structure than a more familiar tool like an outliner or PKM. All the value, however, is in that additional bit of structure

Organizational Cartography & You

What the tool currently does really well—and has for over a decade, using a 50-plus-year-old framework—is help with policy analysis (or e.g. requirements analysis, or even forensic analysis of legacy systems), and design rationale (what I just described, though if you squint you'll realize these are the same process), as a precursor to project planning.

Very early on I also found it useful to extend the tool to support the design of concept schemes (think a glossary with additional structure that relates the terms together), because consistent terminology is so important both across teams and even within them, and for communicating with customers and users. (coherence of shared language)

will be adding:

• A receptacle for business intelligence on organizations, people, products, etc.—like a kind of corporate social network analysis,
• proper structured bibliographic records,
• the ability to just stick plain-vanilla notes anywhere
• fleshing out a whole bunch of support for artifacts used in interaction design (personas, scenarios…) and content strategy (inventories, audits…)—this has been sitting, waiting to go for a while,
• eventually, a comprehensive infrastructure for organizational memory and resource planning

and in the near term, this probably means hooking into existing bug/issue tracking and project management systems, whichever ones you're using.

The overarching structure that this information lives in is called a knowledge graph.

What I just listed are examples of “knowledge graph applications”, although really they all connect together as a single informational fabric, using Intertwingler as a substrate. I firmly believe knowledge graphs are an essential technique for both resolving and communicating complex situations.

The long-term goal is to create the kind of information infrastructure I described in my specificity gradient talk (or the shorter, original video if you like, or the article if you don't like video): organizational memory that enables you to “see down”—or really, in both directions—from macro-scale business goals, all the way through layers of product, design, and engineering decisions, to the resulting lines of code. (fractal)

want to underscore that I am actually trying to play the opposite game of platform capture here. The ultimate goal is to ship a modestly-priced SaaS product

Distilled Capability

What I didn't mention, because I'm trying to be cute with the segue here, is that people have already responded to my aforementioned proposal with interest

One of them, which I wasn't expecting, was a consultant by the name of Troy Winfrey, who characterizes his work as “using techniques from psychological research to identify your ideal customer (ICP) so you can make more money”

One thing we talked about is the fact that it has bothered me for years that promotional copy for software, as long as it has existed, has overwhelmingly been fixated on features.

You can define features in terms of behaviour, but you can't define behaviour in terms of features.

Summer of Protocols: Retrofitting the Web....