The tech sector of social media is currently locked in a spectacular, brain-melting civil war.

On one side, you have the "Strategy Visionaries." They write 40-page slide decks, speak entirely in buzzwords like leveraging synergies, and haven't touched a terminal since the Obama administration. Perhaps surprisingly, these days even "coding legends" like Redis creator antirez is swinging towards the Strategic end of the spectrum. Strategy visionaries say looking at code makes you a bottleneck and that your time is better invested in design and high-level ideas.

Even Redis creator antirez has increasingly emphasized strategy and higher-level thinking.

On the other side, you have the "Code Purists." They believe reading a PRD is a personal insult, and if a system isn't written in bare-metal Rust with zero dependencies, it's basically garbage.

If you ask the internet who is right, the collective brain trust of X will tell you to pick a camp. This is a massive, highly expensive false dichotomy. It's like asking: "Should a Formula 1 driver understand how to turn the steering wheel, or should they know which direction the track goes?"

The answer is: Yes, obviously both.

POV: Deciding whether to spend 100% of your time on slides or 100% of your time in Vim.

The Two Flavors of Software Disasters

To understand why this "either/or" thinking is killing your engineering velocity, let's look at what happens when you isolate yourself at one extreme.

1. The Strategy-Only "Black Box" Leader

This leader treats the codebase like a magic vending machine. You insert a Jira ticket (or an AI prompt), and a feature pops out. Because they never look at the code, they don't see the structural shortcuts being taken to meet their arbitrary deadlines. They don't know that a hasty data structure choice made today will silently tank database latency next quarter.

Eventually, their "visionary" product slows to a crawl, and the engineering team tells them that shipping a simple button change will now take six months. They are left totally blindside-baffled.

The classic communication gap when strategy has zero connection to the code.

2. The Code-Only "Cave Dweller"

This is the engineer who builds a custom, globally distributed, highly concurrent caching layer from scratch—complete with custom memory allocators. It is a masterpiece of technical execution.

The only problem? The business actually needed a simple CRUD app to validate a landing page, and they just burned six months of runway on infrastructure that supports exactly zero active users.

The Bezos "Dive Deep" Secret

When Jeff Bezos was running Amazon, he didn't sit in a lukewarm middle ground trying to balance both. He practiced aggressive vertical mobility.

"I don't care if the slide deck looks pretty—let's look at the metrics and customer feedback."

Bezos famously established the "Dive Deep" leadership principle. He knew that high-level metrics lie to you. They smooth out the rough edges. When your dashboards say your API latency is perfectly fine, but you get a single customer email saying the app feels slow, a great leader doesn't ignore the anecdote. They dive straight down the elevator shaft, past the managers, past the product specs, and look at the actual execution.

How to Operate at All Levels (Without Going Insane)

Operating at all levels does not mean you spend your entire day micromanaging pull requests while trying to write a 3-year strategic roadmap. That is how you burn out.

Instead, think of yourself like a high-speed elevator: Fully inhabit one floor at a time.

Floor 3: The Vision ] ────► 100% focused on simplicity, UX, and customer value.
          │
          ▼  (No dilution. Clean context shift.)
[ Floor 1: The Code ] ────► 100% focused on data structures, truth, and performance.

• When you are on Floor 3: Shut the door on implementation constraints. Do not compromise a beautiful, intuitive user flow just because the database schema makes it "annoying" to build. Focus entirely on the user.
• When you are on Floor 1: Shut the door on hand-waving strategy. Dig into the pull requests. Read the code. Audit the data structures. Verify that the system being built is actually capable of supporting the strategic promises you made on Floor 3.

Expanding your perspective beyond writing code to understanding how every layer fits together.

Stop Asking the Wrong Question

The debate shouldn't be: "Should we read code or not?"

The only question that matters for an engineering organization is:

"How do we build better mechanisms to transition between these layers faster, deeper, and with the absolute minimum amount of friction?"

When you build a culture that can seamlessly travel from high-level product design to low-level code execution, you eliminate blind spots. You can't be fooled by an engineer telling you a basic feature is "impossible," and you won't be blinded by a product manager sketching designs that violate the laws of physics.

You hold the entire map in your head--from the customer's smile down to the raw bytes moving across the wire.