Paul Welty, PhD AI, WORK, AND STAYING HUMAN

· business

Busy is not a state

We've built work cultures that reward activity, even when nothing actually changes. In technical systems, activity doesn't count—only state change does. This essay explores why "busy" has become the most misleading signal we have, and how focusing on state instead of motion makes work more honest, less draining, and actually productive.

Duration: 4:16 | Size: 3.92 MB

This essay first appeared in my weekly newsletter, The Work of Being, where I write once a week about work, learning, and judgment.

I’ve spent a lot of time around people who are genuinely good at their jobs, and also completely worn out.

  • They’re in meetings all day.
  • They respond quickly.
  • They stay on top of things.
  • They’re clearly trying.

And yet, if you stop and ask a simple question (what’s actually different because of all this effort?) the answer is often… unclear.

That used to bother me in a vague way. I thought maybe I just didn’t like how modern work feels. Eventually I realized it’s more specific than that.

We’ve built entire work cultures that reward activity, even when nothing actually changes. And “busy” has become the most misleading signal we have.

Here’s the thing I learned from working with technology: in technical systems, activity doesn’t count. Only state change does.

  • A document either exists or it doesn’t.
  • A record is either updated or it isn’t.
  • Code is either committed, or it’s still just an idea someone has.

There’s no real concept of “kind of done.” No one says, “Trust me, the system is mostly updated.” But in human work, we live in that gray zone all the time.

We say things like:

  • “I’m working on it.”
  • “We talked about it.”
  • “It’s in progress.”
  • “We made some progress.”

Those sound responsible. They sound collaborative. They just don’t tell you what changed. They describe motion, not arrival.

This is where a lot of quiet stress comes from. When states are unclear, people start compensating on their own. They carry the uncertainty.

They wonder:

  • Did that meeting actually do anything?
  • Is someone else handling this, or should I be?
  • If I stop pushing, does this just stall out?

That constant interpretation is exhausting. In software, undefined state is treated as a bug. In organizations, we mostly just live with it, and then wonder why people burn out.

One of the most destructive phrases in modern work is “in progress.” It sounds harmless. Even virtuous. But it’s often a way of avoiding the only question that matters: What will exist when this is done?

If no one can answer that, work doesn’t move forward. It just stretches. Meetings repeat. Emails pile up. Everyone stays busy and slightly uneasy.

In technical systems, a process that never resolves is considered broken. In human systems, we often reward the people who are best at sustaining it.

There’s a very small shift that changes this immediately. Instead of asking, “What are you working on?” ask: “What will be different when this is done?”

That’s it.

That question forces clarity without being aggressive. It doesn’t demand heroics. It just asks for precision. And precision, it turns out, is kind.

This matters even more now, because of AI. AI is very good at generating activity: drafts, options, variations. All of it looks like progress. But if no one defines the target state, AI just accelerates the confusion.

That’s not an AI failure. It’s a human one we’ve been getting away with for years. AI didn’t create the problem. It just made it obvious.

When state is clear, something interesting happens: trust gets easier. You don’t need reassurance when a thing exists. You don’t need optimism when there’s an artifact. You don’t need to argue about progress when you can point to it.

Shared reality replaces interpretation. That’s how good systems feel calm: not because people care less, but because they don’t have to keep everything in their heads.

We resist this, I think, because state clarity feels risky. It forces commitment. It makes failure visible. It removes the cover of effort.

Activity is socially safe. State is honest. But honesty, in a well-designed system, isn’t punitive. It’s stabilizing. It lets people stop performing busyness and start doing work that actually resolves.

This isn’t about turning people into machines. It’s about acknowledging human limits.

Humans are not great at:

  • tracking invisible progress
  • remembering verbal agreements
  • operating indefinitely in ambiguity

Good systems don’t demand that we get better at those things. They take the burden off. That’s not cold or technical. It’s humane.

Once you start paying attention to state, a few things change quickly:

  • Meetings either produce something, or they don’t happen.
  • Work either completes, or stops cleanly.
  • Failure becomes survivable.
  • Progress becomes visible.

And “busy” stops being impressive. Work starts to feel more solid. More honest. Less draining.

This essay first appeared in The work of being, a weekly newsletter on work, learning, and judgment.

Why customer tools are organized wrong

This article reveals a fundamental flaw in how customer support tools are designed—organizing by interaction type instead of by customer—and explains why this fragmentation wastes time and obscures the full picture you need to help users effectively.

Infrastructure shapes thought

The tools you build determine what kinds of thinking become possible. On infrastructure, friction, and building deliberately for thought rather than just throughput.

Server-side dashboard architecture: Why moving data fetching off the browser changes everything

How choosing server-side rendering solved security, CORS, and credential management problems I didn't know I had.

The work of being available now

A book on AI, judgment, and staying human at work.

The practice of work in progress

Practical essays on how work actually gets done.

The first real user breaks everything

Your product works until someone actually uses it. The gap between 'works in dev' and 'works for a person' is where most systems fail — and most organizations avoid looking.

The loop nobody bothers to close

Most systems observe. Almost none learn. The difference is a feedback loop — and the boring cleanup work that makes it possible.

Your process was built for a different speed

When work changes velocity, governance systems don't just fall behind. They become theater. And theater is worse than nothing—it gives you the feeling of control without any of the substance.

The first real user breaks everything

Your product works until someone actually uses it. The gap between 'works in dev' and 'works for a person' is where most systems fail — and most organizations avoid looking.

The loop nobody bothers to close

Most systems observe. Almost none learn. The difference is a feedback loop — and the boring cleanup work that makes it possible.

The difference between shipping and finishing

Shipping is mechanical. Finishing is a judgment call. And most organizations have quietly made it impossible to tell the difference.