I’ve been thinking about Chris Argyris’s distinction between espoused theory and theory-in-use.

Espoused theory is what I say guides the system.
Theory-in-use is what my actual behaviour reveals.

I built LTN Capture with a clear intention. I wanted it to be a simple note-taking app that helped me capture and develop ideas.

Then I started adding more features. I thought if I added enough synthesis and output features, I could shorten the distance from capture to newsletter draft.

The problem was that the app slowly changed jobs.

Instead of helping me capture and think, it started trying to do more of the later-stage work as well.

The app became more complex, but the extra features did not produce enough useful insight to justify that complexity.

In my case:

Espoused theory: I want a simple note-taking app.

Theory-in-use: My repeated feature additions suggested I was really optimising for getting from capture to newsletter output faster.

The issue was not that either goal was wrong.

The problem was that one goal was stated, while another was quietly driving my decisions.

I did not notice the drift until the app had already become more complicated than I wanted.

Once that happens, new features or habits can start reinforcing the direction the system is already moving in.

The actual system becomes what I repeatedly do, not what the design document says.

Here is a simple behaviour audit I use. It is not a heavy system review, just a reminder to check what the system is actually becoming.

Once the hidden rule becomes explicit, I can test whether it is actually useful, then redesign the system around the rule I genuinely want to follow.

Before I go, I’ll leave you with one question:

What does the last thing you added to your system say about what you are really optimising for?

Until next time, keep learning.
Gav.