One thing I’ve been thinking about, related to yesterday’s Commoncog essay, is that effective people tend to be perfectly ok doing things that work, without immediate care for theory.

Theory can catch up later. Contrast that to folk who want models for everything they do, and will eagerly tell you their latest pet model / framework / theory for sales or whatever, and it all sounds very sophisticated, and you check their track records and indeed they’re not very … good?

Friend sent me the Ribbonfarm is Retiring piece and it contains some neat observations (blogging was a ZIRP phenomenon … except I was active in blogging in 2005? And Technorati was ascendant in 2006?) Ultimately it was classic Ribbonfarm, right up to the end.

And by that I mean there are folks who make up models to be useful, and there are folks who make up models for the sake of making up models, accuracy or usefulness be damned, and Ribbonfarm belonged to the latter.

I am legitimately surprised so many people are citing Paul Graham’s “Founder Mode”
so uncritically.

Yes, we know founder-led companies are run better + differently. There are decades of evidence for that. But ‘founder mode’ is so vague that it’s untestable. “Founder mode good. Founder mode do thing different from manager mode. Founder mode is run company different from manager.”

The information content of the essay is nearly zero, if you’re practically minded.

Because how are you going to test this to your own context?!

Every Wednesday morning, Amazon’s leaders look up 400-500 metrics in a single hour.

Here’s why they do this, why it works, and how it helps them win: commoncog.com/the-amazon-wee… Wait, a metrics review meeting can help them win?

Well … yes, because it really isn’t a metrics review meeting, is it?

The WBR is really a mechanism to identify, operationalise and distribute a causal model of the business into the heads of entire company leadership.

I seem to have been sleeping on the whole ‘be a serious person’ / ‘you are not serious people’ meme.

It’s a good line! Specifically, this banger of an essay:

(h/t @DRMacIver)

Wow!experimental-history.com/p/surely-you-c…

When @sjataylor and I started working on Xmrit together, one of the big questions we had was: why haven’t these methods spread outside of manufacturing?

In a previous life, Sam worked IN manufacturing. He was highly skeptical that it could be applied more generally. “Except for healthcare” he joked, “in Six Sigma healthcare was always the pet example they rolled out when they wanted to say ‘Look! It’s used outside factories!’”

I'm actually starting to suspect that the best manufacturers have more to teach software folk than vice versa.

This is not a strong opinion, and I want to retain the ability to revise it.

But manufacturing is harder, older, and lower margin.

https://twitter.com/Meaningness/status/1771539928670675254

This is, incidentally, the premise of an entire book: amazon.sg/Lessons-Titans…

I think some operator folk shy away from writing publicly because they think “ugh, I don’t want to be an internet intellectual.”

But there’s actually a writing-related advantage from being a doer not a writer. This is a tension that I’ve come up against a lot. @KrisAbdelmessih likes to say that I’m a ‘scientist trapped in an operator’s body’ — I take that as a compliment! — but there have also been folk who go “I think you’re a scholar not an operator” when they first find my writing.

About four years ago, I started a series on tacit knowledge.

The latest entry was earlier this week: an interview with @stephen_zerfas. Stephen used some of the ideas in the series to accelerate his own software engineering expertise. If you ask experts how they're able to do what they do, they'll often say something like "it just feels right."

So it's often not useful to ask 'why'.

Stephen used a model of expert intuition called Recognition Primed Decision Making, which gave him better questions.

I hope one of the implications of my Becoming Data Driven essay is clear: that you need to be able to act in order to establish causality.

e.g. you THINK X is a causal factor for Y, but the quickest way to verify is to go do X. Then stop. Then start again. But I realise this is so easy to say but so hard to do for most org contexts.

Say for instance in order to do X you need sign off from multiple departments: product needs to know, engineering needs to do some work, marketing, etc on down — and this can be hard to get.

A huge part of why I feel very strongly about ‘Becoming Data Driven’ is that I feel that data analysts aren’t well served by existing writing on the topic.

(The other part is that I’m a business nerd and want to get better at operating, but I think that’s obvious). It strikes me that the bulk of online writing about data focuses on second order topics.

- modern data modeling
- the modern data stack
- should your data team be organised as a product or a service org?
- how to build data products

These are important, don’t get me wrong …

In order to be data driven, you need lots of data, which is why when Deming addressed Japan’s post war companies, with their food shortages, starving workers, and bombed out factories, he told them “I’m so sorry, process control will not work for you, you’re on your own.” (This, to be clear, is a joke. You don’t need a lot of data when you’re using data to check for change):

https://x.com/ejames_c/status/1741311151181598749?s=20

Am idly plotting how to get all the major business intelligence tool vendors to adopt Process Behaviour Charts as one of the default visualisation types. Yes it’s a dumb chart but it’s shocking how badly distributed it is.

For those who have been looking into Understanding Variation and had your mind blown and your view of data completely transformed, you will naturally ask why process behaviour charts aren’t more popular outside of lean or manufacturing circles.

Good question! A short thread.

https://twitter.com/benedictfritz/status/1745648844203831728

Part of it is branding, for sure.

PBCs been stuck in manufacturing and medical contexts, usually under the banner of lean or ‘quality engineering’. As a result, the vast majority of people think it only applies to production.

Ironic that the highest impact book I read in 2023 was also the shortest. (That’s Donald Wheeler’s Understanding Variation, by the way, which has fundamentally changed how I work as an operator).

The biggest thing I’ve learnt over the past 5 years is that often, the most useful pieces of knowledge are hidden in plain sight, just labelled with terrible names.

This is very encouraging! It means it’s very likely that someone has figured out something you want to know. Example: if you’re looking for practically useful expertise acceleration techniques, digging into expertise research will just yield Deliberate Practice research.

Which has problems.

https://x.com/ejames_c/status/1426857201159872515?s=20

I’m currently working my way through Damn Right!, Janet Lowe’s biography of Charlie Munger, and I have to say, the following bit just made me laugh out loud.

What a character!

Finished the book. Recommended.

The most interesting bits to me were Munger’s formative business experiences. He burned an entire decade on a shitty business, age 26-37, WHILST going through a divorce and watching his first son die

I wrote a months-long series of posts on becoming data driven in business.

At first, the ideas were from Amazon (and W. Edwards Deming). But then I started putting them to practice.

Most of these posts are for Commoncog members.

Here’s a thread of the big ideas. 1. “Management is prediction.”

In order to run a business well, you need to be able to predict the outcomes of your business actions.

Not being able to do so means that you are running your business on superstition.

Here’s a fun pattern that you can’t unsee once you know it.

How do you know if someone is speaking from proper experience of a data-driven culture?

The answer: they’re not too concerned with “difficulty of asking questions”.

https://twitter.com/ejames_c/status/1732230582816628784

“Difficulty of asking questions” is the fan fiction du jour of data people stuck in non-data-driven operational cultures.

Companies that don’t use data ask lots of questions and then don’t act on them.

For companies that actually use data, the bottleneck is never the questions.

I’m becoming somewhat convinced that folks who quibble over the phrase ‘data driven’ and want to use ‘data informed’ are those who haven’t actually worked in a data mature org.

The ones who do, who I’ve talked to, don’t think about such things. They discuss more granular details.

Such as: how do you spot someone gaming a controllable input metric? (Usually in the context of an output metric).

What is an adequate time scale to measure at?

How, exactly, is this measured?

How do you know this isn’t routine variation?

Something that I've been thinking about, which I got from @visakanv: people who do things are able to point out tradeoffs you will encounter when you attempt to put things to practice.

Whereas non-believable people will go "blah blah this thing is good." This implies that a possible test is to ask for tradeoffs, when you're not sure about the believability of the person in question.

And preferably with examples from personal experience.