The Post That Changed How I Write About Tech

I was scrolling LinkedIn last week — mindless thumb flicking between meetings — when a post stopped me cold.

It wasn’t about AI agents, or Claude Code, or the latest framework. It was about why people actually remember anything you write.

The gist: people don’t remember content because it’s comprehensive. They remember it because it changed how they think about something.

That hit harder than I expected. Because for the first year of this blog, I was doing the opposite.

What I Was Doing Wrong

When I started writing for SH, my instinct was to cover everything. Every angle, every caveat, every possible edge case. I’d write a post about setting up Hermes and try to explain the provider system, the skill system, the cron system, the memory system — all in one article.

The result? Technically correct. Completely forgettable.

People would nod along, maybe bookmark it, and never come back. Because I wasn’t giving them a reason to think differently. I was giving them a manual.

The Real Shift

The LinkedIn post that changed my approach said this:

Share observations that help people see familiar challenges in a different way.

That’s the key. Not “explain everything about X.” But “here’s one thing I realized about X that might shift how you see it too.”

The posts I’ve written that actually got responses — the ones where people DM’d me or left comments — all followed that pattern. They weren’t the most thorough. They were the most specific. A single moment where something clicked for me, shared in a way that let the reader experience that click too.

What I’m Doing Now

Three rules I stole from that post and now use for every article:

1. One idea, not one topic. A topic is “Prompting Techniques.” An idea is “Effort levels matter more than your prompt wording.” Go deep on the idea, ignore the rest. This is how structured skills for AI agents work — one focused capability per skill.
2. Start with the moment, not the concept. Not “Prompting is an engineering discipline.” But “I was three hours into debugging when I realized I could fix it by changing one parameter.” The reader follows your process, not your conclusions.
3. Write like you’re telling a coworker. Not like you’re submitting to a journal. The post that changed my approach wasn’t formally structured or SEO-optimized. It was a person sharing something they’d learned, in a voice that felt human.

The Takeaway

I used to think good technical writing meant being exhaustive. Now I think it means being transformative — even if it’s just a small shift in how someone sees one thing.

The best feedback I’ve gotten on any post wasn’t “great tutorial.” It was “I never thought about it that way.”

That’s the bar now. Not volume. Not comprehensiveness. Just: did I move one thought in someone’s head?

This shift in approach directly influenced how I automated my blog writing pipeline — focusing on quality through specificity, not volume. I keep that LinkedIn post bookmarked. Every time I start a new article, I read it first. It’s a five-minute reminder that the goal isn’t to impress with depth — it’s to shift with specificity.