NBD

Like a child with a high time preference who desperately wants a marshmallow, I couldn’t wait. I finished Winslow’s Cartel Trilogy last night (read it!) and gave in. I was going to wait until I’d finished Slate Star Codex Abridged. I didn’t. Couldn’t. I caved and got myself five new Kindle reads. Hence; NBD.

New. Book. Day.

I’m still making my way through the Little Black Classics–most recently, number thirteen, John Keats–but I prefer to read these slowly, on empty mornings. Unfortunately, due to a mixture of internally and externally imposed constraints, these are not particularly regular. So, to supplement the LBCs and SSCA, I have:

At times, it feels like the practice of reading is hard-coded into my DNA. Books–or, more accurately, the people that write them–have given me so much. Changed me in countless, incomprehensible ways. I have faith that the above will continue to catalyse my ongoing, never-ending metamorphosis…

The strange loop of super active omittance

I’m making a deliberate effort to use my notebook as an unconstrained, free-thinking journal. In a recent entry, I riffed on “swell and cut” as a process and started listing synonyms for the process. One was “commit and omit”. This evolved into the following table:

Commit has a positive valence but in two senses. A passive commit means doing something. It’s relatively easy, in basically any scenario, to do something. An active commit means doing the right thing. As we all know, that is much harder.

Omit has a negative valence but in three senses. A passive omit means doing nothing. Again, standard and easy fare. An active omit is slightly more complex; it means avoiding the right thing. I couldn’t decide whether this was easier or harder than doing the right thing, so I allocated them the same difficulty. And yes, I’m aware of the semantic complexities of defining action versus inaction–I’m just opting for selectively applied ignorance. A super active omit means negating the right thing. It’s this last that I find most interesting.

Negating the right thing can mean a few things. Rolling back a hastily deployed software update; a societal wide attempt at degrowth; exiting a less-than-suitable relationship. But what do these examples have to do with strange loops? Straight from the annals of Wikipedia (emphasis mine):

“And yet when I say ‘strange loop’, I have something else in mind — a less concrete, more elusive notion. What I mean by ‘strange loop’ is — here goes a first stab, anyway — not a physical circuit but an abstract loop in which, in the series of stages that constitute the cycling-around, there is a shift from one level of abstraction (or structure) to another, which feels like an upwards movement in an hierarchy, and yet somehow the successive ‘upward’ shifts turn out to give rise to a closed cycle. That is, despite one’s sense of departing ever further from one’s origin, one winds up, to one’s shock, exactly where one had started out. In short, a strange loop is a paradoxical level-crossing feedback loop. (pp. 101-102)”

In the context of the above examples, software is regressed to a previous version, a person exiting a relationship returns to single-status and a society that degrowths executes a weird time hop. In each case, however, the state returned to is different due to the presence of insight and the gathering of now-invisible experience.

(Confession: the above is likely inconsequential. However, it refused to give up its tenancy in my mind so I thought I’d persuade it to take up residency in yours. Let me know if I am successful…)

Fat tails and boring edges

In light of feedback received during my ongoing search for my first product management role, I re-read Taylor Pearson’s article, How to Get Lucky: Focus on the Fat Tails. The following section stuck:

Almost everyone systematically under-allocates resources to the fat tails. We tend to spend most of our time and energy thinking about the middle, because we see the world through a bell curve lens, and most of the area in a bell curve is in the middle. But in reality, we live in an 80/20 world, where the top 1% of fat tails account for 50% of the results. The people who understand this seem to know how to attract luck, but really they’ve just adopted the 80/20 curve model.”

In terms of job/work hunting, that means de-emphasising traditional methods (cover letters and CV submits) in favour of fat-tailed methods (asking people questions, attending meet-ups regularly, joining virtual conferences, working in public). Visually:

I’ve considered the “focus on fat tails” approach in another domain, too: stack entry.

ASSAYING THE INTERNET

For a long while technology has been an interest. But it’s never been more than that. It’s been like an invitation to dinner that I’ve never taken the host up on. Until now. Recently, I decided I wanted to build a simulation model that would allow me to play with the mechanics of trust de- and re-generation. One problem: I don’t know how to code. The agents in hash.ai’s agent-based models are programmed in either Python or Javascript; I decided to start by learning Python. The above wasn’t as whimsical a decision as it sounds.

The internet is an integrated software-hardware stack. For example, the Internet protocol suite is modelled with four layers: link layer, internet layer, transport layer and application layer. Visually:

I’ve spoke with people about learning to code before and my preference has always been to enter the stack at one of two points: the bleeding edge or the boring edge.

BLEEDING, BORING, LUMPY

I recently listened to Dawn Song’s appearance on the Lex Fridman podcast. Dawn Song does all sorts of interesting things and one of those things involves neural program synthesisbuilding a program that can solve a problem by writing its own program. That is bleeding edge.

In the same episode Lex Fridman also mentioned that he was looking for an expert in Fortran. Fortran is a third-generation programming language but one that is older and increasingly hard to find “experts” in. Below third-gen languages there are second-gen languages (assembly languages) and first-gen languages (machine-level languages). That is boring edge.

In contrast to the bleeding and boring edges of the stack is what Taylor Pearson called the body of a bell curve: the lumpy middle. Entering the stack at the lumpy middle is, on most accounts, fine. It’s okay. Reasonable. The most sensible. After all, the lumpy middle is lumpy for a reason; the skills and knowledge contained there are both readily available and relatively valuable. But I think entering at the bleeding or boring edge is a better proposition, both in the short-term and the long-term.

Short-term: I suspect learning about the bleeding or boring edge is just more exciting. Long-term, I suspect it turns out to be much more valuable. Until expertise in the boring edge is needed and until the functionality of the bleeding edge is realised, both are undervalued, but when those times inevitably come a premium can be had. In other words, the fat tail of the technological stack is the bleeding edge and the boring edge.

Another reason not to begin in the lumpy middle: generally, I suspect it is easier to move from one of the B-edges to the lumpy middle (or even straight to the other side) than it is to do the reverse. I don’t have data (even anecdotal) to back this up; it’s just a hunch (feel free to inform me otherwise).

As to choosing between the two edges in the context of stack entry: I think it depends on one’s preference for abstraction. Bleeding edge competencies tend to revolve around system-level problems and solutions–the realm of high abstraction. Think Elon Musk’s dallying with rockets and brain chips or attempts to solve super wicked problems like climate change or wealth inequality. Boring edge competencies tend to revolve around component-level problems and solutions–the realm of minimal abstraction. Think circuit board design.

Personally–as I think my objective to toy with simulation models and the joy I find in writing stories demonstrates–I lean towards abstraction.

Cull and craft

Hurrah! My Elements & Components of Product Management project is past the initial stage. I’ve collated five-hundred-odd ideas from the disciplines of business analysis, UI/UX design, software development, project management and interfacing/integration. Now I have to cull eighty percent of them and create a shortlist, leaving me with roughly twenty per discipline.

The end goal is to have a selection of powerful ideas that can be used as long levers by a product manager. Before I get there, however, I have to figure out the method and criteria for selection.

As well as this, I’ve just begun exploring the hash.ai tool-stack (my profile is here: hash.ai/@matthew). I want to modify one of the existing information/opinion spread models to reflect something like this:

Why? Although I have an interest in tech, I’ve never actually built something before. Fooling around with agent-based modelling not only aligns with my tendency to start hard and ratchet down in difficulty (instead of the more reasonable reverse approach), it is also something I’m actually interested in. The going, of course, will be slow–I’m no coder. But didn’t someone once say, “slow is fast, fast is smooth”?

The root of disagreement

The C4 Model is a paradigm for more effectively diagramming software architecture. The four Cs are context, containers, components and code. This video is a great introduction for the interested. It also provoked a question.

During the presentation, Simon Brown–C4 Model creator–used an analogy. He said that when it comes to understanding software architecture the problem is often notation, not abstraction. He cites two different maps of the same place–they will describe the same things, fundamentally, but do it in a different way. They will disagree.

Consider the abstractions-versus-notation issue in another context. We all agree that inequality is a thing–it’s like the thousand-year-old church on the map of contemporary civilisation. It’s most definitely there. But we all disagree about how to analyse it, where its boundaries end and where they begin, whether to classify it as benign or inevitable or malevolent, and so on. Notation, not abstraction, is the problem.

Now, visualise disagreement as a tree. The trunk diverges into branches and twigs and leaves, all unique but all still birthed by the same arbor. The question is, What is the root of disagreement?

An obvious answer would be “difference.” You and I, we have had different experiences. I grew up in a different place, at a different time, around different people, focused on some things and fearing others. By nature and by nurture, we are not the same. It’s logical for these many differences to eventually manifest as disagreement. Another answer could be “language.” The inadequacy of language is a well-documented phenomenon, after all. If I cannot explain my thoughts–my differences–with sufficient clarity then disagreement is sure to reign. The best answer, in my opinion, encapsulates both the above. I think the root of disagreement is “communication.”

Using language to convey difference is a case of speaking, remember; it makes no mention of listening. An example: imagine two diametrically opposed people are locked in a room. They are compelled by some supernatural entity to listen (and speak only in order to more accurately hear) until they comprehend one another. At the end of the exercise, would they disagree more or less than when they had entered the room? I think “less.”

Unfortunately, even when our notation of reality aligns, even when our abstractions are shared, we have neither the means nor the motive to comprehensively communicate. Good faith and empathy can take us far indeed but never beyond the long reach of disagreement.

The shape of a story

When I finished Barker, I tried to not write. It didn’t work–see Ss. Now, in the midst of a career pivot, I’m still writing. I’m outlining a novella and as I have a little time spare I thought I’d provide some insight into my process. This is where I’m at right now . . .

First Steps

A writing project hasn’t begun in my eyes until I create a place for it within my “Active Projects” folder. After doing that I create a Scrivener document. That document has two primary sections: Elements and Draft. The Draft section stays empty for a while. The Elements sections gets filled with a document for each of the following:

  • Meta: Key questions and other things I need to consider.
  • Authorial Intent: Musings on what I’m trying to accomplish with this project.
  • Characters: The cast of the story.
  • World: Where it takes place.
  • Events: What happens.
  • Narration: How is it shown and told.

For this project I’m corresponding with a subject matter expert. This means there’s an additional doc with all our dialogue.

Here’s how each of the above docs is filled out.

Meta

In this document I record critical information related to the project. Current snapshot:

  • Title: xxxx
  • Length: 20,000 words approx
  • Genre (time): Medium-form; novella
  • Genre (reality): Realism; imagined but possible
  • Genre (style): Drama; solemnity, facing reality as it is.
  • Genre (structure): Mini-plot; inner war of internal antagonism, d(a)emon-facing
  • Genre (content): Status / Worldview / Morality hybrid; see below
  • Controlling idea: Awakening
  • Idea scale: Suffering – Disillusioned – Being – Contented – Awakened
  • Inner conflict: T needs to face reality but he doesn’t want to.
  • Personal conflict: T tells GC his story and is scared of apologising to A
  • Greater conflict: T doesn’t want to be perceived as a bad partner and father.
  • P or C Driven: Character-driven
  • ‘A’ Story: T facing up to his self.
  • ‘B’ Story: T facing up to others.
  • Conventions: ???
  • Obligatory Scenes: ???
  • POV: 1st Person
  • Tense: Present; simple present
  • Soundtrack: Voices, Max Richter
  • Epigram/ph: ???

For a lot of this section, I’ve leaned heavily on the work of Shawn Coyne, Steven Pressfield and Robert McKee.

Authorial Intent

I always have an implicit idea of what I’m trying to accomplish. Often it’s actually a strong sense or deep feeling. However, I tend not to articulate it until I’ve explored the other sections/elements in depth, and even then I prefer to say less than necessary. I’ve found that holding the raison d’être of a project within gives me more energy and power when I attempt to realise it.

Characters

In contrast to Barker, where I went a little OTT with the character profiles, I’m doing very little discovery here. There are four notable characters and all I’m recording are their roles and their status (in the Keith Johnstone sense). The latter is either high, low or variable. In this case, I have two high status characters and two variable status characters.

Events

In Ss, I essentially shirked outlining (aside from notebook scribbles). Here, I am returning to stricter form. As you can see below, the story takes place over five days. For each segment, I’ve allocated an average that the events should equate to.

Beyond a daily overview, each day is broken down into eight separate components, each of which will be its own beat and have its own charge. The cumulative total of the beats (49) divided by the approximate length (20,000 words) gives me a word target for the writing of each beat: 408 words. The aim is to create a detailed outline of the events before beginning to draft.

Narration

In this section, I lay out how I want the final prose to feel. With that objective in mind, I then choose the most appropriate POV (1st, 2nd or 3rd) and the most appropriate tense. In this case, I’ve elected a 1st person POV and the simple present tense.

With this project, I’ve also taken an additional step. In line with the ideas of moodboards, I’m creating sample styles. The prose will remain the same through it, but it will be supplemented with a different tone depending on the story’s events. For example, a beat with a “+ +” notation will have a different feel than a beat with a “- -” notation.

I think of this in terms of apparel. One person can wear many outfits; prose can remain the same in overall construction but have a different tone.

(Un)Necessary?

This seems like a lot of work, and it is. But doing it at the front end of a project means I don’t have to do it at the tail-end. The total amount of work remains the same, and there’s no right or wrong approach. Like most things, the answer to “How do I do X?” begins with “It depends…”

From elements to components

Last week, I compared the elements of stories to the elements of product management. Character, world, events, narration and authorial intent vs business analysis, UI / UX, software engineering / development, project management and interfacing & integrating.

Now, my intention is to further examine the elements and their makeup and document my exploration using a living, breathing artefact. Check it out here.

In other news, I’ve completed the Professional Scrum Master I cert (yay!) and I’ve begun to outline a shiny new novella. The latter will drop at a hopefully-near-but-still-indeterminate point in the future.

Elements of product management

“In this world there are only two tragedies. One is not getting what one wants, and the other is getting it.” I’ve been considering this in the context of product management. Why do I want to be a PM? Am I playing the wrong game, for the wrong reasons? I don’t think so. 

This led me back to writing. I boil stories down to five elements:

Character
World
Events
Narration
Authorial Intent

Product management has similar interacting elements:

Business Analysis
UI / UX
Software Development / Engineering
Project Management

The joy I find in writing fiction comes from combining diverse elements into a cohesive story and releasing it into the world. Product management promises a similar satisfaction and another opportunity to create consistently.

But how do the elements interact? In fiction, authorial intent unifies and empowers the elements of character, world, events and narration. An analogous element is required for product management: 

Interface and Integrate

The “author” would be the PO or PM. Their ability to interface across disciplines and integrate collective effort empowers the other elements of product management. This is what authorial intent accomplishes in fiction. 

Another way of looking at these two sets of elements is using the concept of T-shaped skill sets…

A Tale of Two Ts

In fiction writing, the vertical bar can correspond to any single elements, with the remaining four elements arrayed horizontally. Hard sci-fi author Neal Stephenson’s main expertise is world-building. That’s not to deny his skill crafting characters, plotting events or narrating the story. He’s good overall, but world-building is where he truly excels. 

Many PMs have a strong background in tech, having first been developers or engineers. The vertical bar of their T lies in software. Others come from project management, sales or business analysis. I am none of those.

As a writer, I know that there are people who can craft better characters, build more immersive worlds, plot more engaging stories and pen more penetrating prose. But I stand out in the way I imbue my work with authorial intent and pull the elements together. 

My approach to PMing is the same. I know that there will be people with greater experience in software development, deeper insight into UX and more finely honed project management skills. But there aren’t many who can integrate and interface as well as I can.

Tolerance

Yesterday, I received a surprise in the mail: a pack of Sonya Mann’s zines!

In the aftermath, two things struck me. One: I couldn’t create something like this and I’m glad there are people like Sonya who can. Really glad. Two: I don’t really know how to appreciate something like this.

The first point reminds me of this (and other similar takes):

Preferences–be it for art, food, morality or car colour–are wildly divergent. This is both awe-inspiring and humbling.

The second reminds me of my consistent inability to read poetry. Heck it suggests to me that I have a mental block when it comes to anything above a certain threshold of artiness. Or, more accurately, above a certain threshold of abstraction.

I’m lying, actually. Three things struck me upon reception of the zine pack.

The third: Brandolini’s lawThe amount of energy needed to refute bullshit is an order of magnitude bigger than to produce it–has a cousin concerned with tolerance.

The refutation of bullshit is now a defanged tactic and a misguided strategy. The tolerance of bullshit, however, is a timeless human trait. It’s in our very makeup.

Passively, we can take a surprising amount of BS without too much detriment to our mental or physical health. But if we actively create something that is the opposite of BS–something that has meaning to our selves–we can tolerate BS with even more astuteness.

The average person has a mundane job, likely filled with BS. But the average person also probably has a relationship with someone they care about, a family, friends, and things they like to do.

It’s a trope that good always defeats evil, that truth always conquers lies. I’m not going to claim that meaning is the antidote that can detoxify our society at the largest scales. But I am going to claim that, individually, a single morsel of meaning allows us to tolerate a chunk of BS several orders of magnitude larger.

All-context controls

Way back when, a tweet from Tiago Forte stuck in my mind (alas, I can’t find it right now). It talked of “critical controls”. He definitely listed four:

  • TIME
  • ACTIONS
  • KNOWLEDGE
  • OUTPUT

He may have listed five and included…

  • COMMUNICATION

I added a sixth…

  • SECURITY

Because of my forays into product management, some reading around project management, and a general desire to begin navigating this reality more effectively, I’ve been thinking about these “critical controls” more. First, what makes them “critical”? Second, how exactly do they fail? Third, how can knowledge of these controls be used?

Before I answer, some clarification: Time is self-explanatory, as is Actions. Knowledge can be implicit or explicit, individual or collective. Output I count as an increment of a body of work, as a verifiable piece of evidence, something “done”. Communication is varied: public or private, synchronous or asynchronous, one-to-one or one-to-many. Security is also varied: it can mean access to important assets or storage and backup of important information. Additionally, it cuts across the digital and physical realms.

First Q: what makes these six items critical?

I believe that it is that they cannot be permitted to fail. Regardless of your context, letting control of your time, actions, knowledge, output, communication or security slide ends badly. It doesn’t necessarily end life, but it certainly makes it harder.

Second Q: how do they fail?

Each of the six items can slide one of two ways, with one being more common than the other. Imagine a spectrum of control. Somewhere after its start point is “maintain”. Somewhere before its endpoint is “optimise”. Somewhere between these two points is “measure/manage”. Bad stuff happens when these controls fall below the “maintain” marker and go past “optimise” into the realm of over-optimisation.

Insisting on using an end-to-end encryption communication app like Signal is no use when none of your friends care about encryption and won’t download it. It’s possible to spend so much time engineering your digital garden’s infrastructure that you forgot to plant new things, prune the old and water what you already have. Refusing to manage the increasing spiral of responsibilities that comes with age and experience will harm not only yourself, but others around you too.

Third Q: how can knowledge of these controls be used?

The obvious way to use them is pragmatically. Implemented as part of a weekly review (or monthly, or annual review) these controls can greatly enhance our efficiency and effectiveness. It is this context in which they re-entered my mind recently. Every product and project management framework seems to be concerned with at least one of them, and having them in mind has lowered respective learning curves in several instances.

However, there’s a less obvious way to use them: as generators of questions. The questions could be abstract and generic (“Am I making the most of my time?” or “How is my perception of time as a concept determining my usage of it?”) but they can also be high-resolution and granular. Thinly-sliced, in Agile terms. “Why did it take me four hours to write a memo on Thursday afternoon?” for example.

And while we’re here, talking of questions, I think it’s worth mentioning that the four-point Agile Manifesto…

“Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.”

…can serve as a generator of answers. Of course, there are others but that’s what’s top of my mind right now.