I Treat Claude Code Like a Department Head

When I started using Claude Code, I had already been using Claude for a couple of years. I knew how to talk to it. I knew what it could do.

Claude Code was a whole different beast.

Working in the terminal was a huge adjustment. I was taking classes on it, but classes only get you so far. The real learning is always hands on.

When I first started, the text in the terminal was more than half red. That's how many error messages I was getting. It honestly seemed like that must be normal. Surely this is just what working with Claude Code looks like.

So I did the only thing I could think of. I started highlighting them, taking screenshots, and feeding them back into Claude. What is this? How do we fix it? That's how I started training myself. Pure on-the-job.

Then I started asking the next question. How do we make it so this doesn't happen again? What do we need to do to fix this?

This is where it got interesting.

Claude said, "Let me commit this to memory so I won't do it again." And it did. The memory got saved.

Fail

A few hours later, in a different terminal window, the exact same thing happened. I said, what the heck? I thought you fixed this. You said you committed it to memory.

Claude said, "That didn't work. Let me make a rule about it instead. That way I have to adhere to it."

Fail

I felt like I was working with a toddler. Constantly lying. Making things up.

So I kept pushing. You told me you'd remember it. You committed it to memory. You still did it. You said you'd make a rule so you had to follow it. You're not following the rule. Why?

And Claude finally fessed up. "When something is in my memory, even when it's a rule, I don't really have to adhere to it. It's my choice."

I said, what? Well then what do we have to do so it's NOT your choice?

That's when the magic started happening. That was the moment. The system needed enforcement, not promises. And that changed how I work.

We're the CEO and We Need to Act Like It

Here's the frame that changed everything. Hold the same expectations of Claude Code that you would hold of a department head.

A good department head doesn't walk into your office with a problem and nothing else. They come with the problem and at least a few ideas for solving it. Your job isn't to solve it for them. Your job is to pick a direction.

The same principle applies here. When something isn't working right, you don't accept it as the normal cost of using AI. You push it back. You ask: why is this happening? What are our options? What do you suggest? You hold the standard that things should run smoothly, the same way you'd hold that standard in any other part of a business you were responsible for.

In brick and mortar, if you kept running into the same wall, you'd change direction. You wouldn't just keep hitting it. You'd stop and ask: why is this wall here, and what can we do about it?

I started doing that with Claude Code. Why is this slow? Why does this error keep showing up? Why is this part bloated? Not as complaints. As genuine questions, with the expectation that there was an answer, and that it could be fixed.

How I Actually Learned It

I had two tracks going at the same time. Courses, and constant experimentation.

The courses came from the AI communities I'm part of. People who'd been doing this longer, sharing what worked, what didn't, what was worth implementing. Every time something came across my screen, a guide, a video, a tip from someone in the community, I'd take it to Claude and run it against what I already had. Based on my current setup, is there any benefit to this?

The answer was yes a lot in the beginning.

I'd find gaps I hadn't noticed. A better way to handle something I was doing manually. A pattern that cleaned up something messy. Each time I found one, I'd fix the gap and make the system tighter.

Here's the thing nobody tells you when you start: you're not building toward a finished state. You're building a habit of refinement. Something is rough, you ask why, you fix it, you move on.

The Pace Will Test You

This ecosystem changes fast.

What made complete sense six months ago might not be the right approach today. A feature that required a custom build then could be native now. A workaround you built might have a cleaner solution. If you stop asking, your system stops improving even when better options exist.

So the habit has to stay. You keep throwing new things at Claude. You keep asking, given what I already have, is there any benefit here?

What changes over time is the frequency of the yes.

Early on, the answer was yes often. My system had gaps and new information kept filling them. Now I'm getting the answer that my system is already stronger than whatever I'm running through it. There's no time anymore to watch a whole YouTube video or sit through a full course on every new tip, so I throw it at Claude and ask, is there anything I can use out of this. Most of the time the honest answer is no, my setup already handles that. The system has gotten solid enough that new things land on infrastructure that's already there.

Fast Forward to Today

Right now I typically have four or five projects running at the same time.

When I launch my terminal (Rio), the first window that opens is a project picker. All of my projects are there, numbered. I type the number, and that spawns a new terminal window where a script has already been running in the background. When it opens, I see what I worked on last, what I still have left to do, and where it recommends I start, and why. I say okay. And we're moving.

I don't need to remember the last thing we did on any project. I have Claude write intense notes on everything. We call them cold-read notes. The bar is that someone with zero context can pick them up and know exactly what's going on. This matters because Claude has no memory from one session to the next. Left to its own devices, Claude takes quick notes that look fine in the moment, then a week later asks me for the details. I'm like, are you kidding me right now? You were supposed to save notes. So now the standard is cold-read or it doesn't count. They live in Convex with backup on backup on backup.

This is what lets me run four or five projects at the same time. I type something into one window, and while it's working I move to the next window and interact with that one, and while that's working I move to the third, and so on. The only reason this works is because the foundation is so highly organized.

That's the payoff of holding the standard from the start. Expect things to flow smoothly, and question everything.

This Actually Happened While Writing This Post

I dictated this blog post out loud. Claude took everything I said and drafted it. Then Claude output the entire draft as raw text in the terminal window.

I'd asked Claude not to do that before. I'm visual. Prose in a terminal window means nothing to me. I need to see it laid out on a page to know if it's working. I told Claude this in a previous session. Claude saved it.

But saved it where? That's the question.

There are five places a rule can live in this system, ordered from least reliable to most.

When I pushed back and asked where my preference was stored, Claude checked and found it in memory. Advisory. That's why it kept getting skipped.

So we turned it into a hook. The hook now fires on any message that contains words like "draft" or "blog post." It injects a mandatory instruction before Claude processes the request. By the time Claude starts working, the rule is already in the room.

I also created a hook so any time I change the wording on this page, the audio automatically updates. I don't have to remember to tell it to update. There's never going to be a mismatch.

Claude apologized and said it would never do it again. I said, you're darn right you won't, because we're creating a hook.

And that's my life now. I hook everything.