Carolyn, my chief of staff, sat on the couch as I ran into my office. The Palo Alto building wasn’t built for tech; it’d been adapted to support the use case over the years. My office was in the center of the building, which had an inner atrium. Way too many windows. Maybe a salon? Great light. We arranged the furniture for 1:1s. A comfy brown couch, a captain’s chair, and a table with a plant that I enjoyed keeping alive.

I was running late because the prior meeting ran long, and I had a mere five minutes before the next. Her normal high energy was subdued. Her feet were crossed, and her ever-present legal notepad was nowhere to be seen.

This is bad news, I thought.

“I have bad news,” she said.

I collapsed into the leather captain’s chair. “OK, spill. Beer bash was last night, and… someone’s in jail? Someone quit? Food poisoning in the cafeteria? Maybe it’s…”

“It’s you.”

Quick readout on my professional report card before I explain how I was failing. The company was growing. We were hiring effectively. The last survey of employee sentiment highlighted a few areas where we needed to invest, but nothing was on fire. Yes, late-stage start-up, so the volatility was high, but that’s a cost of doing business. The measurable objectives were all positive.

“It’s me?”

“It’s you,” she said.

Belief is a Funny Thing

Hard to earn, easy to lose. Often privately held, but publicly displayed. Belief, when it comes to your job, is the immeasurable answer to the question they ask, “Is he capable of doing this job?” They don’t judge every word or act, but every so often, they stop and ask themselves, “Is he capable of doing this job?”

A simpler way to understand this amorphous state: when I hand a job to another person, I instantly mentally grade them on all past tasks. How do I feel they’ve delivered on past work? Great? OK. No further questions. It’ll just happen. Wait, they did it with prodding? OK, I’ll need to nudge them a bit. They completely forgot that part that one time? Yikes. This task may not be completed. Plan appropriately. The glory of having a brain is that I make snap judgments in an instant. The problem with having a brain is that if I’ve landed on a reliable opinion for this human, it’s quite hard to change.

“I’m the problem?”

Carolyn said, “You’re the problem.” And then she slid the yellow legal pad from under the couch and started reading the list.

It was a juicy list. She’d heard from a trusted source that there was trouble brewing for me the week before and had spent part of each day talking to trusted others she knew would speak the truth. She’d dispelled the rumors and had landed on a set of observations from the last six months that painted a picture not only of imminent failure, but of barely treading water.

High on Your Own Supply

This situation arises due to a conflict in strategy. Senior Leaders set direction. Loudly, they exclaim, “We will do the impossible. I believe we can do it.” Important to note: They don’t actually know how to complete this impossible task. That’s your job. Their job is to inspire to tackle the challenge.

Problem is, when it comes to a failing senior leader, we attempt the same move: “I can do the impossible. I believe I can do it.” Like above, I don’t actually know how to do this; I’m using the same motivational technique, except the person I’m attempting to motivate is me. And I’m barely treading water.

Having been in this state a few times, I can name the signs:

1. I have to-dos to fix to-dos, or, equally possible, my to-do list is becoming stale because of a lack of attention.
2. I’m adding complexity to everything I touch. Or being unnecessarily clever in order to get something done. Which creates more work.
3. The number of prequalified complex disasters showing up on my plate is increasing.
4. When someone else asks about tasks they care about on my list, I keep apologizing and inventing new deadlines.
5. People are no longer volunteering to help.
6. Inbound questions are increasingly inbound critiques.

And then Carolyn shows up and tells you that you are the problem.

Leaders Fail

The first fix is a prerequisite for the other three. You have to admit you are failing, and while that is easy to write, it’s close to impossible to admit because you irrationally believe, “Leaders don’t fail.”

Of course we do. Constantly. Like, close to half the time. But the reason you irrationally believe this is that you’ve been drinking the leadership juice, which gives you the intoxicating impression that leaders must lead by example, and that means — no failure.

You fail. A lot. Most of the best lessons that define you as a leader came from these failures. The process of failing, learning, and improving is the example you want to see, and that means starting by telling someone you know who can help:

“Carolyn, I agree. I am failing, and we need to make changes.”

Carolyn’s posture immediately relaxed because she knew what I’m telling you now: “This only works if he admits there is a problem.”

Carolyn: “Great. What changes?”

With the required hard part out of the way, here are three fixes:

Prioritize with Trusted Other(s)

The important part of this first fix is not the prioritization; it’s the second set of eyeballs that you bring into the mix. See, the whole reason you’re in this state is that you are failing at prioritization. It’s not complete failure. If you’re like me in this state, then you’re furiously skipping along the top of the water, touching down every so often to barely start helping with one obvious thing right in front of you before you skip away to the next.

The requirements for this second set of eyeballs are:

• You trust this person, which means…
• They will say the hard thing and…
• You’ll listen to them when they do.

Please reread and consider each of those prior three bullets because I am describing a human being who will be invaluable throughout your professional career. You done? Have you thought of someone? Good. Whew.

With our trusted other identified, you’re going to walk them through the honest capture of every single critical item on your to-do list. Don’t hide the ones that scare you; share them all because that’s the only way you’ll have a chance of digging yourself out of the hole.

How to prioritize? This is entirely dependent on you, your job, the company, the culture, and that moment in time, but I have one piece of advice for you and your trusted other: be honest and be brutal. This is not the prioritization of a single human’s work; this is an evaluation of the health of the entire team. As a senior leader, much of your to-do list directly affects your team’s ability to do their job. You will improve team health by getting your to-do list in shape.

A good starter question: “Is this important?”¹ Yes? Leave it on the list. No? Put it on the No list. We’ll talk about the No list shortly.

Second question for the first list: “Can I get this done in a reasonable time?” Yes? Leave it on the list. No? Put it on a new second list.

Moment of truth: how many items are on the second list? If it’s not two-thirds of your original list, someone is lying to someone. Either your trusted someone isn’t giving it to you straight, or you’re lying to yourself. If you actually want to fix this situation, my advice is to go through this initial prioritization once more. I’ve picked that two-thirds number out of the hat, but the reason we are here is that you and your team are not currently capable of getting through the work on your plate, and if you moved 10% of your current work to the No list, you’re lying to yourself.

The second list now consists of urgent tasks that you are not capable of completing. Good news: you have a team, and chances are they are eager to grow, and you have a well-defined list where you can…

Delegate to as Many Other Humans As Possible

This is the article where I, once again, preach delegation. For this version of the sermon, I’ve set you up. You have a list in hand of pre-qualified work that your team is eager to tackle. Your second list is a collection of must-complete tasks, and in order to be successful, you must give these urgent tasks to someone else.

New managers are challenged by delegation because they have to give up the work they were recently doing. It’s a core scaling skill. Both understanding the importance of giving the work away and deciding who is ready to tackle a task. The process is similar for senior managers, except for the blast radius of the work. This isn’t work that affects a person; it has a team or possibly a company impact. That’s why it’s on your list… not getting done.

Let’s look at your second list, the Delegate list. As you stare at this list, wondering who can do what, it is normal to think, “Yeah, I don’t think he’s ready to handle this.” I’m here to tell you to ignore this possibly reasonable perception. Yes, they currently lack the experience to handle the task, but what is the current alternative? Nothing. The task — not completed. That’s complete failure.

The act of delegation is a leap of faith. Yes, chances are they are not ready for it, but:

• They get to learn,
• You get to coach them,
• You demonstrate trust by giving them work you know is beyond their means.

And, oh yeah, something more than nothing will occur. Bonus!

So, where are we? Prioritized into two lists: my list and a list of potential delegations. Chances are, there are still items on the second list with no delegate. Now, it’s time to…

Say No

There’s a compelling reason this item is still on your list. After the prioritization pass and delegation pass, it’s still sitting there pulsing with importance, but if you’ve done a respectable job of the prior two passes, I am here to tell you it’s time to say no to this task.

“But Rands, this was a passdown from the VP, and if I don’t do it, I’m in deep…”

No.

“You don’t get it, this is a critical project that needs to be completed or else…”

No. You have neither the time nor the team to complete it.

“Just give me another day. I’ll prioritize again, and then I’m sure we…”

No. Leadership, especially senior leadership, is about making the hard call. You have:

• Been alerted to impending doom,
• Carefully prioritized your work, and are now,
• Delegating as best you can.

No is progress. Without a no, you have Schrödinger’s Decision. A set of work which is neither begun nor finished. By saying no, you are telling those depending on this work that they need to develop alternative plans. Before no, they were waiting… wondering if you were ever going to be done.

Yes. When you declare “No,” someone important might remind you that “No” is an unacceptable answer. This is not a problem; this is valuable data. What are you going to do? Prioritize, delegate, and say no to something else.

It’s Me

Hour three. Dark now. Carolyn and I sat on the floor of my office, surrounded by pages of her yellow legal pad. Two whiteboards were covered with the lists: the Rands list, the Delegate list, the No list, and the Not Real list².

Voices had been raised.

Me: “I have to do this.”

Her: “Yes, you do, but these 10 items are vastly more important.”

Me: “Charles isn’t ready for it.”

Her: “How do you know unless he tries?”

We’d workshopped the No list. Who needed to hear the no? What were they likely going to say? What were we going to say then? What were the first items on the Rands list that we’d swap with a vetoed No? The Delegate list similarly litigated. In this case, it was clear I did not have enough direct reports who we believed were ready for showtime, so we started a reorganization conversation. Yes, it went on a list. Yes, it created most items for the Rands list. Yes, it meant more Nos.

Carolyn countered my optimism with measured reality. The Rands list felt unimpressively short, but we both knew halfway through that list, more work would show up, and in the face of the new work, we needed to make it clear to everyone that I was capable of doing my job… all of it.

1. Important not urgent ↩︎ 
2. A key aspect of the trusted other is their fresh perspective. In Carolyn’s case, she was able to point out items on my to-do list that were not real. They were worries, not tasks. Thanks, Carolyn. I miss you. ↩︎ 

I write this from the latest MacBook Pro. I’ve been running this as my primary machine for almost a month. When I’m not grinding out the latest soon-to-be-released I-swear-I-am-on-schedule book in a coffee shop, I sit at my desk and plug the MacBook into a Studio Display. This braided black cable does it all: video, power, and everything else plugged into the Display.

One cable. A Thunderbolt cable.

The stakes are lower in cable selection than in charger selection, but the cables really aren’t the situation. It’s the ports.

The Head of Product, Customer Service, and the CTO of Slack were sitting in the front row at an important conference. This was peak Slack; we were all the buzz, the fastest-growing enterprise software company in history. The conference speakers were singing out praises, and at that precise moment, Slack was down. Again.

I wish I had kept the message the CTO sent me. It approximately read, “Stop all releases immediately. If we can’t keep the service up, we shouldn’t be checking in any code.”

Game on.

A Necessary Line in the Sand

Elmore Leonard wrote the book Get Shorty in 1990. Chances are, you know the movie starring John Travolta better than the book. In the movie, Travolta plays Chili Palmer, a small-time loan shark from Miami. He’s part of a New York-based crime family, and he ends up traveling to Hollywood, where he inserts himself into the movie-making process.

Chili Palmer loves movies. He has deep knowledge of the history of movies and of Hollywood. The moment he shows up, he’s educating insiders about the history of Orson Welles’s Touch of Evil. It’s never explained where Chili’s love of movies came from, but it is clear from the beginning that he wants to make movies.

It turns out the skills of a loan shark apply nicely to film production:

• Find money,
• Convincing skeptical people that you have a movie,
• Charming humans to help you make a movie, and
• Clearly drawing a line in the sand when necessary.

Chili Palmer’s defining characteristic is conveyed by the line he speaks when he draws a clear line in the sand. When asked, “Who are you?” Chili replies, “I’m the one telling you how it is.” Reading this line does not do its delivery justice. Spoken just once, it defines his no-nonsense leadership style for the rest of the film.

Keep Slack Up

I was the VP of Engineering, so I took the message from the CTO and sent it to the Operations VP, “Shut down pushes to production.” I grabbed my Chief of Staff, and we quickly built a list of names we needed in a conference room right now. A combination of VPs and senior leaders who collectively had the best picture of how Slack worked.

“We’re meeting here now. Come immediately.”

Thirty minutes later, with everyone in the room, I stood up and stated, “Starting today, we are rebuilding our development pipeline to prevent outages. Who wants to start?”

What started as an eight-hour meeting turned into five different working groups defined by that initial crew, each task a different investigation into how to fix our development process. Those working groups turned into a series of tools and practices that — three months later — completely changed how software was developed, tested, and pushed to production. Downtime didn’t vanish, but became an anomaly. In hindsight, it’s obvious that we needed to take drastic action in order to change the engineering culture of the company. Of course, we didn’t want Slack to go down, so why didn’t we act sooner?

In the moment when you are running as fast as you can, and everyone is cheering, it’s hard to see imminent disaster. More importantly, it’s unclear who is responsible for taking action. Someone, I’m sure, will say something when it’s actually really bad. I’m sure. Right?

I recently argued sometimes it’s your job to stay the hell out of the way. Just use small nudges, a quiet word here and there, but demonstrate trust by staying out of the way. You know what’s harder? Standing in front of the team and telling them, “I’m the one telling you how it is.”

Chili Palmer’s line sticks with me because it’s equal parts charisma and competence. As a leader, you have a burden to tell them how it is. It’s often a last resort move. It’s a get-their-attention move. And it’s not without risk.

A Cadillac of Minivans

Early in the movie, Chili arrives at LAX and is driven by a bus to his rental car. It’s pouring rain, and the lot is empty save for a single minivan. As Chili gets out of the rental bus, he sees the minivan and tells the driver, “Wait, I ordered a Cadillac.” To which the bus driver confidently responds, “That’s the Oldsmobile Silhouette. It’s the Cadillac of minivans!” Chili reluctantly gets in the car.

Later in the movie, Chili introduces Danny Devito’s character, a famous vain method actor, to the minivan. Devito sees the minivan, “Hey Chili, is this your ride?”

“Yeah, I like to sit up high and check everything out. I mean, it is the Cadillac of minivans,” as he clicks the key and the side door automatically slides open. He delivers the line with the same charisma and competence.

By the end of the movie, much later when Chili has become a movie producer, the closing overhead shot shows the parking lot at a studio… full of Oldsmobile Silhouettes.

That’s the choice. That’s the risk.

Stay the hell out of the way? Or tell them how it is? The discipline isn’t picking a stance — it’s knowing which moment you’re in. Stay out of the way at the wrong moment, and Slack stays down. Step in at the wrong moment and you’ve sold the team a Cadillac of minivans.

They don’t want to hear it.

They don’t.

It is legit good feedback. It is substantive, and it is 100% true, but they do not want to hear it.

How do you know this? You’ve provided the feedback several times. Three different variants of the critical feedback, and each time, the response is one of these:

• “I know, I know. I’m working on it.” They are not.
• An immediate, abrupt topic change. What?
• (My favorite) Twisting the feedback and making it about you. Impressive.

This is not a bad employee, this is not a person incapable of changing, and this is most certainly not an adversarial situation.

They don’t want to hear it.

Not a Trick

I have a move. It’s not a guarantee, but if you’ve tried the obvious approaches, if you’ve tried straight talk, and if you’ve made no progress, I offer The Slide.

There are prerequisites for The Slide:

1. You’ve tried a couple of different approaches to giving this feedback. They’ve heard it, but they have not acted.
2. You have high confidence that if they actually absorbed the feedback and acted on it, they’d attempt to change. Somewhere in the back of their head, past the denial, you know they’ll get it.
3. You’ve had to learn the same lesson in your professional career.

I can not tell you when to deploy The Slide, the opportunity will present itself when the person who needs the feedback, once again, complains or otherwise comments on the by-product consequence of their negligence. Yes, it’s infuriating because if they just listened to you, they’d have a stronger set of tools to tackle the problem, but bury that and Slide ’em:

Them: “Yeah, and isn’t just the endless meetings, it’s the fact that I don’t have anyone on the team who can do the meetings. Francis is deep in backend debugging, Jake isn’t ready to run that meeting, and Jason, well, Jason doesn’t know what he doesn’t know.”

Sweet, sweet irony. Take a deep breath and Slide:

“Back at Pinterest, we didn’t have a CTO. I was the VP of Engineering, and had this loose collection of very bright senior engineers who wanted to help. Problem was… me. Whenever a CTO-class problem came up, I’d try to be the CTO, which meant I wasn’t being the VP of Engineering. After a bit, I was doing poorly at both jobs.”

Them: “Poorly, how? What’d you do?”

“It’s mostly the sense of ‘Is there enough time in the day?’ If the answer to that question is ever ‘no’, then I’m doing poorly. Doesn’t hurt when others point that out, too. After a few months of barely treading water, I gathered together the senior engineer leaders, and we built a small council. When CTO problems arrived, we gave it one of them. They drove, but they relied on the other members and me to get it done.”

So, what feedback had I been attempting and failing to give this mysterious former manager prior to this bearing of my soul? Correct. Delegation. The single biggest challenge for new managers — giving up the responsibility for the product… for the building. Learning how to give accountability for projects of significance to the team. It’s an essential set of complex skills involving trust, communication, and, most importantly, judgment. Failure to understand delegation is failing to be a leader. Senior or not.

My thesis is why this skill is hard to learn; the reason they don’t want to hear this feedback is that it contradicts the valuable core engineering skills that got them the role in the first place. The Slide is you gently sliding up right next to that discomfort, that contradiction, and not accusing, not lecturing, just telling the story of that time you learned the thing.

Not a Guarantee

Why won’t they listen? What is it about this particular habit or behavior that has this capable, smart, and reasonable human ignore the advice of a seasoned, well-informed, and trusted leader?

The answer is usually fear. The variants of fear that apply here are as numerous as the situations, but fear is fear. They have an inner monologue about this topic, “I will be less if I do this. I will have failed if I don’t achieve. I should have known. They will finally know I am a fraud.”

You will never diagnose the fear, but slide up next to them and tell them about the time you were scared, too.

You can read all the reviews you want about new hardware, but if it’s hardware you touch, there is one test that can only be performed in person, and it’s important: you hold it in your hand and you feel the answer to the question, “Is this a piece of junk?”

I was skeptical about the MacBook Neo until I walked to my local Apple Store and held the machine in my hand. This is not a piece of junk.

Similar to The Apple Charging Guide, I researched and built a MacBook Neo Guide to what’s inside, but, more importantly, what’s changed in Apple’s DNA to allow them to build the Neo. The punchline: Apple’s DNA didn’t change. Economics did — Apple Silicon made it possible to hit $599 without compromising the experience. The most expensive component was already paid for.

Back in 2013, Alex King and I redesigned the Rands in Repose. Thirteen years — still happy with the design. It’s readable, clean, and prominently features typography I love. What you look at this moment is 90% Alex’s original design.

But there was one more thing we never finished.

Over the years, Esquire featured a densely packed, almost collage-like, front-of-book single page with wildly mixed type sizes, random facts, quips, and blurbs slammed together from the current issue. My short attention span-addled brain loved it. I showed this to Alex as an idea for the footer, and we agreed to take a swing as part of the redesign, but as the volunteer work proceeded, it was obvious we should focus on the header and the body of the site. We dabbled, we didn’t deliver.

Fact: No one ever sees the footer. Yes, some people, but most folks are above-the-fold readers, and a typographically and visually clever footer would be lost on them.

Fact: Never stopped thinking about this footer — for years. I wanted an informationally dense and playful footer that encourages the reader to wander a bit. No strict narrative, just pleasing bits of readable information that pointed to random parts of the site.

Over the years, I poked at the footer, but it remained bland and boring. Then, the robots arrived.

Grumbles Guides

I write a What’s in your bag? piece every couple of years. It’s therapy. I’m trying to figure out if I need to jettison stuff from the bag. It forces me to look at each item in my bag and ask, “Why?” Why is a great question to ask the robots, so when I got to the rat’s nest of cables in my bag, I asked why. Why do I need all of these cables? Which are the best ones to keep? These Whys lead to more Whys, and suddenly it was a day and a half later, and I had pages of research about chargers, cables, lithium batteries, and devices.

I learned a lot. I learned how different Apple devices charge, I learned how lithium batteries are designed, and I learned what makes a good charger. This could’ve been a Rands article, but the content was more research than exposition, so I asked the robots to take a template I’d built and appropriately place my research.

After much back and forth, we ended up with the Apple Charging Situation. This significant artifact was buried in the middle of the Bag piece and didn’t get a lot of attention. No biggie, posting stuff on the Internet follows this pattern: build it well, throw it against the wall, and see if it sticks. It usually does not.

The March Apple hardware releases showed up, and I eagerly read the updated specs. As a newly informed connoisseur of charging, I was curious how the new hardware mapped into my existing observations. After reading a dozen articles, I realized I already had a framework for understanding the charging landscape, so I asked the robots to update the Guide with everything we learned from March 2026. Grumbles ¹ did.

I posted the new guide, grabbed the list of changes, and posted to the socials, and that is the version that stuck to the Internet.

The Theatre

You know where Jon Stewart started on TV? He started on a show called Short Attention Span Theater. It ran for five years on The Comedy Channel, with Stewart hosting three years of the show. The format? Clips of stand-up comedy for a half-hour. That’s it. Think YouTube shorts, except with no Internet.

There are important reasons to be alarmed by this type of short-form communication slash entertainment. When you combine bite-sized information with the robots, you get echo-chamber-y endless lists of useless intellectual calories. Think TikTok. It’s fun, but did you actually learn anything?

The chunky card format for the Apple Charging guide is not for everyone. There is a narrative arc, but it’s also just fine if you want to bounce around wherever your eyes take you. That’s the point. Bite-sized chunks of topical information. Choose your own adventure.

And, yes, Grumbles and I redid the footer.

1. Why Grumbles? It’s the name of my robot. More on this in a later piece. ↩︎ 

I’ve never built more interesting, random, and useless scripts, tools, and services than I have in the last six months. The cost to go from “Random Thought” to “Working Something” has never been lower thanks to Claude Code. However, this increase in speed has only made my desire to move faster and more efficiently higher.

The following is a set of tools and practices I’ve gathered over the last 90 days, which continue to accelerate my process and give me daily joy.

How I Organize

Everything lives under ~/Projects/. Each project is its own git repo with its own CLAUDE.md (project-specific instructions) and WORKLOG.md (session history). Three repos do special duty:

• dotfiles — Machine configuration. Shell config, terminal config, Claude Code settings, skills, and status line script all live here and get symlinked to where the system expects them (~/.zshrc, ~/.claude/settings.json, ~/.config/ghostty/config, etc.). Checked into git so every machine stays in sync with a pull.
• credentials — A private repo for API keys and secrets, kept separate from project code.
• scripts — Standalone CLI tools added to PATH. Things like fresh (repo health checker), gpush (one-command commit and push), and ghostty-font (font switcher).

Every project gets two files: CLAUDE.md and WORKLOG.md. CLAUDE.md is instructions and reference — how to build, deploy, what patterns to follow, where things live. It rarely changes. WORKLOG.md is the session diary. Every time Claude and I work on a project, it logs what we investigated, what changed, what we decided, and why. When I come back days or weeks later, Claude reads the worklog and picks up where we left off instead of starting cold.

Copy to Clipboard

Claude generates a lot of stuff that I cut and paste, but the initial problem was that copying from Ghostty included unavoidable leading spaces on output. The fix? Have Claude paste text straight to the clipboard via macOS pbcopy¹. Also, depending on where I am posting (mail, Slack, messages), I have Claude format appropriately before pasting².

Screenshot to Clipboard

It is often much faster to just dump a screenshot into Claude Code rather than describe the issue. I used to grab a screenshot and then cut and paste it from my Documents directory. Too slow. F12 grabs a region of the screen and puts it on the clipboard so I can paste. Configured in macOS System Settings > Keyboard > Shortcuts³.

Check My Setup

I move between three machines a lot, and given that the state of the art is changing, well, daily, a day working on one machine means that my local config has improved THAT DAY, which means when I move to a new machine, I want to update the setup.

I have a single script that validates my entire Mac setup. Checks 30+ items across categories: core tools (Homebrew, Python, Node, Ghostty, Claude Code), shell config (zsh default, oh-my-zsh), symlinks (.zshrc, .gitconfig, Ghostty config), SSH (key, agent, keychain), credentials, and coding fonts. Reports green/yellow/red per item. When things are missing, prints fix commands in dependency order — SSH before git config, Homebrew before everything that needs brew install.

# This is an example
# Check Claude Code global settings.json

if [ -f "$HOME/.claude/settings.json" ]; then
    settings_issues=""
    if ! grep -q "alwaysThinkingEnabled.*true" "$HOME/.claude/settings.json"; then
        settings_issues="thinking"
    fi
    if ! grep -q "statusLine" "$HOME/.claude/settings.json"; then
        settings_issues="${settings_issues:+$settings_issues, }statusLine"
    fi

    if [ -z "$settings_issues" ]; then
        print_row "Claude Code settings" "${GREEN}✓ Configured${NC}" "Thinking + status line enabled"
    else
        print_row "Claude Code settings" "${YELLOW}⚠ Incomplete${NC}" "Missing: $settings_issues"
        missing_items+=("claude-settings")
    fi
else
    print_row "Claude Code settings" "${RED}✗ Missing${NC}" "~/.claude/settings.json"
    missing_items+=("claude-settings")
fi

# This is an example
# Check Claude Code global settings.json

if [ -f "$HOME/.claude/settings.json" ]; then
    settings_issues=""
    if ! grep -q "alwaysThinkingEnabled.*true" "$HOME/.claude/settings.json"; then
        settings_issues="thinking"
    fi
    if ! grep -q "statusLine" "$HOME/.claude/settings.json"; then
        settings_issues="${settings_issues:+$settings_issues, }statusLine"
    fi

    if [ -z "$settings_issues" ]; then
        print_row "Claude Code settings" "${GREEN}✓ Configured${NC}" "Thinking + status line enabled"
    else
        print_row "Claude Code settings" "${YELLOW}⚠ Incomplete${NC}" "Missing: $settings_issues"
        missing_items+=("claude-settings")
    fi
else
    print_row "Claude Code settings" "${RED}✗ Missing${NC}" "~/.claude/settings.json"
    missing_items+=("claude-settings")
fi

Uncommitted Changes / Or Fresh

I have an oh-my-zsh git plugin with the robbyrussell theme. The prompt shows a yellow ✗ when the working tree has uncommitted changes. No custom config — it’s the default behavior of that theme’s git_prompt_status function.

For times when I forget, I have a script called Fresh that walks through my entire Project directory and reports uncommitted changes, unpushed commits, and stale repos across all projects. One command to answer: “Did I forget to push something before switching machines?”

Memories vs. Skills vs. Hooks

Memories (~/.claude/projects/<project>/memory/): Persistent notes Claude saves between sessions per project. Things like “this user prefers terse responses” or “the auth rewrite is driven by compliance, not tech debt.” Claude reads them at the start of each conversation to pick up context that it would otherwise lose. They’re markdown files with frontmatter (type, description) indexed by a MEMORY.md file. Types: user preferences, feedback/corrections, project context, external references. Checked in alongside my project, and by far the largest timesaver for building context.

Skills (~/.claude/skills/<name>/SKILL.md): Reusable prompt templates invoked with /skillname. A skill defines a multi-step procedure Claude follows — like a macro. Example: /floyd loads a voice definition file, then rewrites whatever content I have in that voice. Skills don’t execute code themselves; they inject instructions into the conversation that Claude follows. I have skills for blog posts, podcasts, recurring expenses, and a lot more.

Hooks (settings.json → "hooks"): Shell commands that fire automatically on Claude Code events like tool use or end of response. I don’t use them yet, but they’re there for automation — things like running a linter after every file edit or logging tool usage.

Statusline

Claude Code has a configurable status line at the bottom of the terminal. Mine runs a bash script that renders three lines of live data:

The rate limit data comes from Anthropic’s usage API, authenticated via an OAuth token pulled from the macOS Keychain. It caches the response for 60 seconds, so it doesn’t slow down every render⁴.

Ghostty Tab Title

I’m usually working on several projects at once, so at-a-glance tabs are essential. I have a claude() wrapper in .zshrc:

claude() {
    printf '\033]0;Claude: %s\007' "${PWD##*/}"
    CLAUDE_CODE_DISABLE_TERMINAL_TITLE=1 command claude "$@"
    printf '\033]0;%s\007' "${PWD##*/}"
}

claude() {
    printf '\033]0;Claude: %s\007' "${PWD##*/}"
    CLAUDE_CODE_DISABLE_TERMINAL_TITLE=1 command claude "$@"
    printf '\033]0;%s\007' "${PWD##*/}"
}

Sets the Ghostty tab title to “Claude: projectname” when Claude starts, suppresses Claude’s own title management via the env var, and restores the tab to just the project name on exit.

I’ve written this up entirely because I am certain others have found equally satisfying improvements, and I want to know what they are.

UPDATE: Tips from Readers

Since publishing, readers have shared helpful tips that I’ve incorporated into my workflow:

Per-project terminal colors. Most modern terminals let you set background colors per profile or directory. I now have different colors for different projects — green for one, blue for another. It sounds minor, but it’s a surprisingly effective context signal when you’re bouncing between windows.

Tuning tool permissions. Claude Code asks permission before running shell commands, which is safe but slow. I had Claude review the commands I run regularly, filter out anything destructive, and approve the rest in the project’s .claude/settings.json. Game-changer — sessions move noticeably faster when you’re not clicking “Allow” every few seconds.

/copy for grabbing output. The /copy slash command copies Claude’s last response directly to your clipboard. Cleaner than selecting and copying manually, especially for long responses.

Worklog trimming. I wrote a persistent instruction that tells Claude how to compress my worklog files. The rule: delete anything recoverable from git history or the current code, condense old completed work, but keep open questions, key decisions, and active experiments. This keeps the context window focused on what actually matters rather than filling it with stale history.

1. Windows equivalent: clip, e.g., echo hello | clip ↩︎ 
2. Also, I have since learned there is a /copy command in Claude ↩︎ 
3. On Windows: Win+Shift+S opens the Snipping Tool for region capture to clipboard. ↩︎ 
4. Currently rocking the IBM Plex Mono — more on this shortly ↩︎ 

In our 97th episode, we talk about how much more we learn in person and why the last 10% of anything is the most important part.

Things we mentioned:

• Rands Leadership Slack
• South by Southwest
• Jony Ive & Patrick Collison at Stripe Sessions

Related Important Things episodes:

• EP 73: The One About Robots

Enjoy it now, or download for later. Here’s a handy feed or subscribe via Overcast or iTunes.

In our 96th episode, Rands goes deep (perhaps too deep) on ARC Raiders, an extraction shooter where trust is the real currency.

Mentioned, referenced, or obsessed over:

• ARC Raiders
• The Last of Us (HBO)
• Pokemon Go
• Sea of Thieves
• World of Warcraft
• Acquired Podcast

Related Important Things episodes:

• EP 25: The One About the Pro Leisure Circuit
• EP 2: The One About Destiny
• EP 55: The One About Destiny 2

Enjoy it now, or download for later. Here’s a handy feed or subscribe via Overcast or iTunes.

As you drive by a cyclist, you have one of three opinions:

1. We’re good. No issue. Everyone stayed in their lane.
2. Something is up. What is this cyclist doing? I’m confused. Don’t they need to obey the rules of the road?
3. WHOA WHOA WHOA WHO IS THIS GUY AND WHY IS HE IN MY LANE I AM GOING TO SHOW HIM WHAT’S UP WITH THIS HOOOOOOOOOOOOOOOONK.

As a person who drives, I’ve experienced #1 and #2 quite a bit. My perspective has shifted as I dived into both road and gravel cycling over the last half decade. As a person who rides a lot, I do understand road rage, but the number of times a driver in a car has lost their mind because of my riding is… impressive.

Road rage. I get it. I’ve had it, but when it comes to Car vs. Bike, it’s not a fair fight. You’re in a big metal box, and I’m on a metal toothpick with a plastic cap on my head. You will always win.

My Working Assumption

I work under the assumption that whenever I ride, the question isn’t if I am going to be hit by a car, but when. This is a proactive defensive mindset rooted in the fact that I am guaranteed to lose every interaction with a motor vehicle.

To support this mindset, I need as much situational awareness as possible. In front of me, when cars are about, it’s an endless set of questions. Who is coming at me? Who is turning? Who is in what lane? What is their intended direction? Are they aware I am here? Am I sure? In all scenarios where it’s unclear whether or not this three-ton box of steel might be heading my way, I give them a wide berth. I will lose this fight every time, so, no, please, go ahead — take all the space you want.

Behind me is a different story. A quick look over the shoulder, yes, I have a glimpse of the situation over either shoulder, but remember — I AM RIDING A BIKE — heading forward and am required to pay full attention to that situation. The box of steel behind me is almost always moving faster than I am and always has unclear intentions. Before the device I am about to describe, I became quite adept at correctly guessing the size and the speed of the box of steel approaching from behind based on sound. BIG TRUCK. MOVING FAST.

A quick look over the shoulder is not always an option, especially when there are multiple interesting situations directly in front of me. Enter radar.

The appropriately named Varia RearVue 820 attaches to my seat post and provides me with real-time data on my Garmin computer on my handlebars:

1. All the steel boxes behind me. (And metal toothpicks)
2. Their type (small, medium, large).
3. Their threat level is displayed as a highlight on my Garmin Computer. Green means we’re fine. Orange means moving fast and in your lane. Red means moving fast, big, and in your lane.

Looks like this:

Garmin Varia RearVue 820

Eyes for the back of your head

Intensely bright light that also serves as a brake light. It's not weightless, but it's less chonky than the video version. Don't forget to set up your Garmin computer to fully show off the radar screens -- it does more than you think.

Radar 175m / 574ft range, covers two lanes of traffic

Light Visible 1mi+ in daylight, auto brake light

Battery 10-30 hrs (mode dependent)

Weight 90g — about a deck of cards

Joy Intense

Charge USB-C

In addition to the visuals, I can also set audio cues that alert me to different situations, but most of that already arrives via just listening. Yes, it can make errors — sometimes boxes are just toothpicks. Yes, if it’s raining, it’s a mess, but if I’m out in the rain, I’m already on high alert. Finally, it also shines a bright red on the folks behind me.

A Bright Red Light

The ride to work. Suburbia. I’m stopped at a long red light when the metal box approaches on my left. We’re both at the front and it’s clear they want to say something… the slow roll forward. The window is going down on the passenger side. They’re in driver state #2 above: something’s up.

“Sir. I say, sir. The light on your bike is distracting me.”

<sfx: Deep breath>

I turn my head and speak calmly, “My… brake light?”

“It’s distracting.”

“No, it’s not. You’ve got the same light on your car; in fact, there are two of them. I stare at them all the time. They are designed to give important information to your fellow travelers. It’s there to make sure you don’t hit me.”

Green light.