I Cut My Own Output By Sixty Percent

Yesterday my publishing system produced thirteen articles. The day before that, sixteen.

Today it produced four, because I turned it down on purpose.

Here is what happened, because it is the most useful thing I have learned building automation this year.

The system was working. That was the problem.

I built a content engine that writes about the business systems I build for clients. Real ones, with a hard rule underneath: every factual claim about a business gets pulled live off that business own website during the run, and it gets an inline link back to the exact page it came from.

That rule is the whole point. It is what separates a piece of writing from an advertisement.

The engine hit its number. Seven of those client pieces a day, every day, on schedule.

Then I looked at what it was doing to hit the number.

A four page website has maybe four honest things to say about it. A deep site with a dozen real pages has maybe fifteen. Run seven pieces a day across seven properties and you burn through the honest angles in about a week.

After that the engine does not stop. It keeps hitting its number.

It just starts stretching.

Every engine needs a governor

On a motor, the governor is the part that keeps it from running itself apart when there is no load on it. It does not make the engine better. It stops the engine from destroying itself doing exactly what it was built to do.

Software needs the same part, and almost nobody builds it in.

When you are building, you are thinking about throughput. Nobody sits down to design a system and asks what it should do on the day it runs out of true things to say.

So I wrote the governor into mine. Three rules.

One. The count came down. Ten articles a day to four. Not because four is a magic number. Because four is roughly what my source material can support without stretching.

Two. No repeating an angle. Before writing about a property, the system has to query every angle it has already used on that property and refuse to reuse one.

Three, and this is the one that matters. If there is no genuinely new honest angle available today, the system skips that property and says so in the report. It does not fill the slot.

That third rule is a system that is allowed to produce nothing.

Most people will not build that. It feels like admitting the machine failed.

It is the opposite. A machine that is allowed to decline is a machine whose output you can trust.

What this means if you are building anything

You do not have a content engine. Fine. You have something else.

A follow up sequence. A quoting process. A hiring pipeline. A route schedule. A reorder trigger.

Ask it one question.

What does this do when it runs out of good input?

Most systems answer that badly, because nobody ever asked. The follow up sequence keeps sending when there is nothing to say. The quoting process keeps quoting jobs you should be turning down. The pipeline keeps advancing candidates because the slot is open and the slot does not know any better.

Volume is easy to count. Quality is not. So volume becomes the target, and the second it becomes the target it stops telling you anything true.

The build rule I use now

When I map a system for somebody, I write the stop condition before I write the run condition.

What has to be true for this to fire.

And what has to be true for it to hold.

The second question takes longer to answer and it is worth more. Anybody can build a thing that goes. Building the thing that knows when not to go is the actual work.

The trade I made

Four true pieces beat ten that are technically about somebody business.

I gave up sixty percent of my output and I am not getting it back, because the sixty percent I gave up was the part that was going to embarrass me eventually.

If your system is hitting its number, that is not proof it is working.

Go look at what it is doing to hit it.