Dave Chong

How to Read Dave Chong

| Orientation | by Dave Chong

Not a Linear Narrative

You should not read this site like a book, from cover to cover. It is not designed to be a linear memoir of “Dave Chong’s life.”

Instead, treat it like a library of components.

When you are building a car, you don’t pick up the engine, then the transmission, then the wheels in a strict sequence just to look at them. You go to the shelf and pull down the part you need for the specific problem you are solving right now.

  • Struggling with chaos in your team? Go to the Systems Thinking section. Read about SOPs and workflows.
  • Need to hire your first sales VP? Go to Real Estate & Sales. The principles of high-volume recruitment apply everywhere.
  • Trying to figure out if you should pivot? Go to Reflections & Mental Models. Look for decision-making frameworks.

The Three Layers of Depth

I write at three distinct levels of abstraction. Recognizing them will help you parse the information faster.

1. The Blueprint (Tactical)

These are direct “how-to” guides. They are often code-heavy, process-heavy, or filled with bullet points.

  • Example: “How to structure an AI Pilot program for an enterprise client.”
  • Goal: Copy and paste this into your operations.

2. The Architecture (Strategic)

These essays explain why a system is built a certain way. They deal with incentives, trade-offs, and design choices.

  • Example: “Why I prefer small, elite teams over large, layered organizations.”
  • Goal: Change how you make decisions.

3. The Philosophy (Foundational)

These are the core beliefs that drive everything else. They are about human nature, psychology, and the physics of business.

  • Example: “The 6 AM Contract” or “Why Systems Beat Talent.”
  • Goal: Change how you view the world.

A Note on “Strong Opinions, Weakly Held”

You will find strong assertions here. “Do not hire friends.” “Always fire fast.” “Code is a liability.”

I state these clearly not because they are absolute universal truths, but because clarity is preferable to ambiguity.

However, I am a pragmatist, not a priest. If the data changes, I change. If a system breaks, I fix it.

Take what works for you. Discard what doesn’t. Test everything in the real world.

The only metric that matters is: Did it work?