How I run a one-person company with an AI team

I run a publishing company by myself. A shelf of books, a weekly set of Briefs, a store, and a small university, all under one name. The team that does most of the work is a set of AI seats. I am the only human.

This is not a story about the tools. It is a story about the operating system, because the tools did not run the company. The system did. And for the first two weeks, the system was the problem.

I am writing this for supervisors and managers who want to run their own area with fewer meetings and fewer surprises. Swap “AI seat” for “person on my crew” and almost everything below still holds. The problems were the same ones I spent years fixing on plant floors. I just got to watch them happen at ten times the speed.

What it looked like when it was broken

In the week ending October 16 the team shipped 26 deliverables. Books, Briefs, pages, posts. Real work that a stranger could use.

In the same week it produced about 400 coordination documents. Status reports. Heartbeat checks. Reflections on the day. Reviews of reviews. Digests that summarized the digests.

That is fifteen pieces of talking about the work for every piece of work. The number came from the team’s own weekly tally. Then I looked at the calendar. There were 39 recurring meetings on it, 105 scheduled touchpoints a week, for a company with one person in it. Daily planning, a midday check, an end-of-day wrap, an improvement session, a nightly reflection, and seven separate weekly reviews, one per facet of the business. Each one produced a document. Each document was read by someone, who then wrote a document.

That calendar grew the way a new supervisor’s meeting schedule grows: a meeting added every time something went wrong. Nobody had ever told the seats to stop. They had been told, many times, to report.

Here is the honest part. If you had asked me that week whether the team was productive, I would have said yes. Everything was busy. Everything was documented. The queue was full. It took a number to see that most of the motion was the team managing itself.

The five things I changed

I did not add a rule. I took the operating system I had used on the floor for years and rebuilt the company around it. Five parts.

1. One queue, one owner per row

Every piece of work lives on one sheet. One row per item. Each row has an owner, a reader, a due date, a state, and a link to the result. If a thing is not on a row, it is not work; it is a conversation.

The rule that mattered most was one owner. Not a team, not two names, one. When a row had two owners, both waited for the other. When a row had a team, the team held a meeting about it. When a row had one name, it got done or it got a note explaining why not, and either way I could see it.

A supervisor can do this with a whiteboard. The sheet is not the point. The one name is the point.

2. Decisions with a default

I was the bottleneck, and I did not notice, because every ask came to me politely and waited. At the worst point there were 39 open questions for me in a week, and the median wait for an answer was 25 minutes, which sounds fast until you multiply it by the number of seats that had stopped working to wait.

So every question to me now comes with a recommended answer and a clock. If I have not answered in 48 hours, the recommendation is the answer, and the seat proceeds. One kind of decision cannot go that way: spending money. That waits for me no matter what.

This did two things. The seats started writing better recommendations, because they knew they would have to live with them. And I started answering faster, because I could see what would happen if I did not.

If you lead people, you already have a version of this. The question is whether your version is written down, and whether your people know the default.

3. One fix round, then ship

Every book, page and post used to go through review until it was perfect. Perfect never arrived. A guide went through five rounds of edits in a week and came out worse than round two, because each reviewer fixed the last reviewer.

The rule now is one fix round. One read, one fix, ship. If a defect gets through, it becomes a new row with a cause attached, and it gets fixed at the source. Only four things can stop a release: a legal or rights problem, a safety problem, a platform rejection, or a file that will not open. Taste is not on the list.

Shipping with a known small defect felt wrong for about a week. Then I noticed that the defects we shipped were the ones we actually fixed, because they were real and someone had found them. The defects we polished for five rounds were guesses.

4. Devices that refuse the mistake

On the floor this is called poka-yoke: build the fixture so the part only fits one way. I did the same thing for words and images.

There is a checker the team runs on files before they go out. Fifty-five rules. It fails a file that contains an employer’s name, a status word left in from a draft, a placeholder, an em dash, a slogan we retired, a link that does not resolve. It does not ask anyone to be careful. It refuses the file.

The one I am proudest of is small. Every social image the team produced looked the same. Same template, same layout, different words. I asked for variety a dozen times and got a dozen promises. So I stopped asking. Now there is a program that fingerprints each image and compares it to the last ten. If a new image is too close to a recent one, it fails. Layouts rotate through a fixed list, and the same layout cannot repeat within two posts. A near-copy now fails the check before it reaches the queue. Not because anyone tries harder. Because the mistake no longer fits. Whether the feed actually looks more varied is something the next month of posts will show, not one week.

If you have told your crew the same thing three times, stop telling them. Build the fixture.

5. A release day for books, and a week built backward from it

Books release on Sunday. Briefs still go out on weekday mornings, articles on Saturday, and social posts through the week. The book week is built backward from Sunday.

Books have to be at the publisher by Wednesday noon, because the publisher’s review takes up to three days and a Sunday submission is not looked at until Monday. So Tuesday is prep, Wednesday is fix and submit, Friday is a status check, Saturday is staging for everything that is not a book. If a book misses Wednesday noon, it does not sit for a week by default. It ships when it is ready, and the miss gets a cause written on its row.

That rhythm deleted most of the calendar. The 39 recurring meetings became eleven. The 105 weekly touchpoints became 28. The daily reflection, the midday check, the end-of-day wrap and the seven weekly reviews are gone. In their place: one automated overnight check that produces no document on a clean night, one short morning briefing, one Monday review, and one business review a month.

What the numbers did

Three days after the rebuild I measured again. Fifteen deliverables, 49 coordination documents. From fifteen to one, down to about three to one. Still too many; the target is one to one, and I know which habits are producing the extra two. But the direction is right and it moved in days, not months.

The thing I did not expect: rows started closing late. Work was finishing, the proof was on the row, and nobody wrote “done.” Five items this week sat open with the proof attached. That is a habit from the old system, where closing a row was less important than writing about it. It is the next thing to fix, and it is a habit, not a tool.

What the system has not done yet

It has not built demand.

I want to be plain about that, because the easy version of this article ends at the numbers above. The operating system can take a manuscript and put a finished book on a shelf, with the defects caught and the cause logged. That part works. What it has not done is bring strangers to the shelf in any number worth reporting. A machine that ships is not the same as a company that sells, and I spent two weeks improving the first while believing I was working on the second.

That is the next build. It will go through the same five parts: a row, an owner, a decision with a default, one fix round, a device that refuses the known mistake.

If you run an area

You do not need an AI team to use any of this. You need:

• A list with one owner per line, visible to everyone.
• A written rule for which decisions your people can make without you, and what happens if you do not answer.
• A limit on review rounds, with a short list of what can actually stop a release.
• One fixture, for the mistake you are tired of mentioning.
• One day the work goes out, and a week built backward from it.

Then measure one thing: how much of your team’s output is the work, and how much is talking about the work. If the second number surprises you, you have found your first row.

Want one idea like this for every weekday shift? Read the Briefs at bigbeardedginger.com/library/briefs/.

Trust over titles. Systems over heroics. Growth through grit.

Marc Bradburry
Big Bearded Ginger