← Insights

Insight: 19

Blindspotting

Why noticing what you are not doing is harder than optimizing what you can see — builder mode, operator mode, and the missing capabilities AI makes easier to ignore.

Stephan Smith
Stephan Smith

7 min read

How I think

Blindspotting

Why the harder problem is noticing what you are not doing

We are surprisingly good at analyzing what we can already see. Give me a process, a product, a calendar, a week of work, and I can find the waste. I can tighten the loop. I can make the known thing faster, cleaner, more efficient.

The reverse question is harder: what am I not doing? What is missing entirely? Which capabilities sit outside the set I keep optimizing?

I call the deliberate search for those missing areas Blindspotting.

My computer-science background keeps reminding me this is a hard problem. We can usually say, “Let’s analyze what’s in this set of data.” Asking the reverse — “What is not in this set?” — is a different kind of work. The same applies to humans. I can describe what I am doing and improve it. I find it far harder to reverse the set and determine what I am not doing at all.

That gap matters more when you work alone.

I spent the last four years as a fractional CTO. Twenty-five years of building software and teams got distilled into a consulting practice that runs as a single unit. I don’t want employees. AI has made that model more workable than it used to be. It compresses the grunt work, the office duties, the background tasks that used to fill a forty-hour week into a smaller nugget. The core value I deliver each week is high enough that I can operate solo.

The cost of that setup is quieter. Working alone means fewer voices to pull, push, test, or bounce ideas off. There is nobody sitting across the table saying, “You keep solving the product problem. Have you noticed you don’t have a distribution problem solved at all?” Blindspotting is how I try to look into the spaces I cannot see from inside my own habits.

When I launched Fractional Tools in January, it was mostly crickets. I couldn’t get anybody to try it beyond maybe my first twenty core testers. They loved it. I couldn’t figure out how to translate that love into a larger message.

My instinct was familiar. If people weren’t adopting, something must be missing from the product. Another feature. A better flow. A bug I hadn’t found yet. Building is the problem I know how to solve, so weak market signals got interpreted as a missing feature.

That is a founder pattern I keep watching in myself and in other technical people. When the market is quiet, the builder brain does not say, “Maybe I need sales, positioning, or distribution.” It says, “The product isn’t finished.” Code feels concrete. Marketing feels accidental. Sales feels like something that happens after the real work.

I believe the only durable skills in the AI age aren’t computer programming. They’re marketing, sales, and positioning — areas I keep returning to because they’re the ones I keep failing to practice. Blindspotting, for me, starts with a blunt question: where do I fail?

I’m consistently good at taking an idea from zero to one. I’m terrible at scaling it over time. I create opportunities and then do not double down on them. I joke that I’d like to build the systems that keep trains running on schedule, yet I’m not great at making the trains actually run on time. I drift back into the day-to-day legwork of building.

So over the past month I forced myself into what I call operator mode, and deliberately left builder mode.

Builder mode is when I develop a new feature assuming it will sell. Operator mode means using the tools I already have and applying a different metric for success each day. I run those tools without changing or rebuilding them. I may fix the occasional bug, but I stay in operator mode.

I needed a metric that would tell me operator mode was working, because I learned this the hard way the first time I tried it in June. When I didn’t receive any signals — not even a small dopamine boost confirming I was on the right track — I reverted to thinking, “I’m missing a feature; there must be a bug.”

This time I watched a different set of numbers: subscribers, active engagement, and whether I was writing articles tailored to the actual messages I was hearing on calls. Not feature velocity. Not polish. Market signal.

The first three weeks were rough. I’ll be honest, I backslid a few times and fixed some bugs. Maybe added a few features. I can tell my builder brain is feeling neglected.

Last week someone mentioned that in dark mode they couldn’t subscribe to the newsletter. My builder brain sprang to life, eager to put that on the stack. It constantly reminds me that sales and positioning feel accidental, but code is what truly matters. That reminder is useful and dangerous at the same time. Useful because sometimes the bug is real. Dangerous because it is also the exact story I tell myself when I want to leave the harder work.

I think I’ll need to keep operator mode active through the end of September. In September I’m flying to Reykjavík for a conference full of solo entrepreneurs and very small teams building real businesses — not venture-backed startups, but companies whose revenue is driven by responding to clear signals. I want to be in a room where the missing capabilities are visible in other people’s calendars, not just in my own excuses.

AI may make Blindspotting more important, not less. It makes it easier to operate alone and compress execution. That is the upside. The downside is that the same compression reduces the number of people around us who might expose our blind spots. Fewer voices means fewer people to pull, push, test, or bounce ideas off — and fewer chances for someone else to name the thing you keep avoiding. Solo operators with powerful tools can move very fast inside a very small set of capabilities, and never notice the set has a hole in it.

Expertise creates the same trap. We retreat toward the capabilities where we are strongest. I can always find another useful thing to build. That is why the blind spot is sticky. The missing skill is not just hard because I lack practice. It is hard because my practiced skills keep offering me a more comfortable problem to solve instead.

I still prefer building. I catch myself measuring progress by how many features I pushed, then having to ask, at the end of the day, whether I heard or realized anything I had not previously recognized as valuable. Mapping the backslide has become part of the work. I am keenly aware that it’s easier for me to notice other people’s blind spots than my own.

This week I’m not asking myself what to improve in the product. I’m asking what I’m treating as a product problem that might be a missing skill.

My final thought is unfinished on purpose. The gap between where I am and where I want to be feels smaller than I think, and harder to bridge, mostly because of Blindspotting: discovering the skills I lack and the abilities I’m not even considering. Those gaps are especially tough to close, because they do not show up as bugs in the thing I already know how to improve.

Improving what is present will always feel like progress. Finding what is absent is slower, quieter, and easier to abandon. That is the work I’m trying to stay inside.

See also

If this landed, subscribe — I write about the operator work that usually loses to the next feature.