Automating outcomes, not tasks

Azeem Azhar shared an anecdote in his newsletter: He had tea with a senior exec last month who manages about a thousand engineers, nearly all of whom use Claude Code. Output per person is up, but output for the org is not. Her line: “one plus one plus one plus one equals one-and-a-half.”

Before reading this piece, I wasn’t familiar with the “productivity J curve”, but now having read it, it makes total sense to me.

In the 1890s, factories adopted electric motors but kept the old shaft-and-belt layouts — what’s called “group drive.” They got a cost savings, not a productivity revolution. It wasn’t until 1913, when Ford rebuilt Highland Park around the workflow instead of the geometry of the power shaft, that productivity actually compounded. Then U.S. manufacturing labor productivity grew more than 5% a year for a decade. First productivity went down, then it went up a lot — making a J shape.

What will be the assembly line moment for AI?

I don’t know, but I’ve been thinking about how this applies to my individual use of AI. It has definitely helped me get faster at all kinds of routine work, but I still feel subject to the same 4-equals-one-point-five math as Azeem’s friend.

So I sat down to map out what kinds of things I actually do for work in the hopes that it would help me clarify where I can look for meaningful productivity gains. In making the list, I realized that I’ve been using AI to help me enhance or automate tasks. But maybe I need to change the mindset and look for ways the AI can help me automate outcomes.

Here’s a representative mapping of what I mean:

The reframe has interesting implications. Automating tasks is still useful (especially for things I am tempted to procrastinate about), but some of my tasks are poor targets for automation (meet with entrepreneurs) whereas the associated outcomes (help founders win, make good investment decisions) yield more opportunities to try.

The new /goal feature from OpenAI Codex seems aligned with this idea.