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.

About two years ago I wrote a series of essays on Lia DiBello's research into business expertise.

Her work has been hugely influential to me — it's changed the way I view business, and affected the way I think about my growth as an operator.

That series WAS paywalled ... But as of yesterday, I've made it available to everyone: commoncog.com/setting-busine…

This week’s Commoncog essay is a deep dive into the cursed question: “what do you do in business when you can’t predict the outcomes of your actions?”

But let’s set this up … I’ve spent the last couple of months digging into ‘how to become data driven in business’. And the heart of the idea is that ‘management is prediction’ — you can’t be a good operator if you don’t know the business outcomes of your actions.

The job of data is to help you do that.

The field of Statistical Process Control has this interesting idea that ‘management is prediction’ — i.e., in order to be a good operator, you need to be able to predict (within limits) the business outcomes of your actions.

The implications that flow from this are quite useful. First, most business operators run their businesses according to ‘superstition’ — meaning they believe some set of things will happen due to their actions, and then they take those actions, but they don’t really KNOW if there’s a causal relationship.

This describes me too, btw.

My article on Goodhart’s Law was on the Hacker News front page last night.

I thought this was a good comment (just about every other comment was bad). The Goodhart’s Law piece may be found here (and the comment refers to the lengthy case study of the Amazon Weekly Business Review in action): commoncog.com/goodharts-law-…

I’ve been thinking about Amazon’s “Are Right, A Lot” Leadership Principle again. It’s probably the most controversial of the Leadership Principles, and one I’ve spent the most time thinking about (and asking ex-Amazonians about). The first thing that usually gets pointed out is that it sits between two other principles that intentionally balance it out: