Why Every Tech Leader Needs a "Wait-What" List

The Power of the "Wait, What?" Moment

You're in a post-mortem. The database crashed at 2am. The team explains: "We ran out of file descriptors because Kubernetes was spawning too many health check connections."

Everyone nods. The junior engineer writes up a ticket to increase ulimit. Meeting adjourned.

But you stop. "Wait, what?"

Why was Kubernetes spawning that many connections? Why didn't we hit this in staging? Why do health checks even need a new connection per request? What if the next bottleneck is network sockets?

That one question changes the entire investigation. What looked like a simple config fix becomes a deep dive into connection pooling, TCP keepalive settings, and ultimately a redesign of how your infrastructure does liveness checks.

The most valuable moments in my career weren't seeing things go right. They were seeing something so weird I had to say "Wait, what?"

The Curiosity Muscle Atrophies Fast

When you're building something new, everything is a "wait, what?" moment. You don't know the codebase. You don't know the architecture. Every line of config is suspicious.

But after a few years, you stop questioning. You assume the system works the way it works because someone smart made that decision. You trust the abstractions. You stop digging.

This is when the system starts to rot.

In 2015, we had a multi-hour outage at Link11. The root cause? A cron job that had been running for six years without anyone knowing what it did. When the server it lived on finally died, nobody could restore it because nobody understood it.

Someone, at some point, had written that cron job to solve a problem. It worked. Everyone moved on. The institutional knowledge walked out the door. And one day, it became a single point of failure.

The curiosity muscle atrophies fast. If you don't exercise it deliberately, you end up with a system held together by magic incantations nobody dares to question.

My "Wait-What" List

I keep a running list. It's low-tech: a text file called wait-what.md in my notes folder. Whenever something surprises me—good or bad—it goes on the list.

Here are a few recent entries:

• Why does our API gateway add 300ms of latency on cold start? (Answer: it was doing a DNS lookup on every request because we misconfigured the connection pool.)
• Why did our bill from AWS spike 40% last month? (Answer: someone enabled detailed CloudWatch metrics on a high-traffic endpoint. Cost: $12k/month.)
• Why do our customers in Asia report slower performance than our customers in Europe, even though we have an edge node in Singapore? (Answer: BGP routing was sending Singapore traffic through Frankfurt due to a misconfigured peering policy.)

None of these were "urgent" problems. They were anomalies. Curiosities. Things that didn't quite make sense.

But each one, when investigated, uncovered a much deeper issue. A misunderstanding of how the system worked. A hidden cost. A reliability risk.

The "Wait-What" list is a forcing function for curiosity. It turns vague unease into concrete investigation.

How to Build Your Own

Start simple. When something surprises you, write it down. Don't try to answer it immediately. Just capture the question.

Once a week (I do mine on Friday afternoons), review the list. Pick one or two items and dig in. Sometimes the answer is simple. Sometimes it opens a rabbit hole.

The goal isn't to solve every mystery. The goal is to stay in the habit of questioning.

Here's my framework:

1. Capture the anomaly. Don't rationalize it away. If something feels weird, it probably is.
2. Timebox the investigation. Give yourself 30 minutes to dig. If you don't find an answer, escalate or defer.
3. Share what you learn. Post-mortems aren't just for outages. Share the "huh, interesting" findings too.
4. Reward curiosity in your team. If someone asks "why does this work this way?" and uncovers a hidden issue, celebrate it. Make it clear that questioning is valuable.

The Questions That Change Everything

Some of the biggest pivots at Link11 started with a "Wait, what?" moment:

• "Why are we using this vendor?" Led to in-sourcing a critical component, saving €200k/year and improving reliability.
• "Why does this API endpoint return 10x more data than we need?" Led to a redesign that cut bandwidth costs by 60%.
• "Why do we have three different monitoring systems?" Led to a consolidation that improved on-call response time and reduced tool sprawl.

None of these were "strategic initiatives." They were just curiosities that someone bothered to chase down.

The best technical leaders I know aren't the ones with all the answers. They're the ones who ask the best questions.

The Danger of "That's Just How It Works"

Every organization has sacred cows. Systems that nobody touches because "that's just how it works."

The deployment pipeline that takes 45 minutes because "builds are slow."

The service that restarts every night at 3am because "it has a memory leak."

The API that returns XML instead of JSON because "legacy clients depend on it."

These aren't facts of nature. They're technical debt dressed up as tradition.

Your "Wait-What" list is a way to surface these assumptions and test whether they're still valid.

Sometimes the answer is: "Yes, this is a known trade-off, and we've decided it's not worth fixing." That's fine. At least now it's a conscious decision, not an inherited mystery.

Curiosity as a Competitive Advantage

In 20 years of building Link11, I've learned this: the companies that stay curious are the ones that survive.

The ones that stop questioning their assumptions get disrupted. The ones that treat their architecture as gospel get outpaced by competitors who rethink from first principles.

Curiosity isn't just a nice-to-have. It's a moat.

When you have a culture where people ask "Wait, what?" and actually get answers, you build institutional knowledge. You avoid the same mistakes twice. You turn every anomaly into a learning opportunity.

Start your list today. Write down one thing that surprised you this week. Then go figure out why.

The best technical decisions you'll ever make will start with those two words: "Wait, what?"

---