The Looking Glass: The Loudest Way to Lead

The best thing studying computer science gave me, The Three-Body Problem, and am I right?

Hello readers!

This week’s tidbits:

For paid subscribers:

As a reminder, paying for a subscription (ie, buying me a fancy coffee per month) encourages me to publish more and helps me hire someone to properly edit and manage this publication. You’ll also get subscriber-only essays, Q&A, and additional raw tidbits including poorly written middle-of-the-night poetry.

The Looking Glass is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

The loudest way to lead

If you care about putting forth a quality product, then you should be the biggest dogfooder.

If you expect members of your team to be on call on weekends, then you too should be available and responsive at that time.

If want your team to focus on their top priorities, then you shouldn’t schedule a wall of recurring meetings.

If you expect others to care about excellence, then you need to be the first to call out sloppy work.

If you wish for your team to invest in growth, then you should be the first to share what you’ve learned.

The best thing studying computer science gave me

The best thing studying computer science gave me is an engineer’s mind.

A bias toward breaking big problems down into smaller ones.

A predilection for bucketing specific instances into groups.

A yearning for solutions that solve for an entire system of problems rather than just one.

An appreciation for the art of selecting the right inputs and outputs.

A dissatisfaction with repetitive work.

A thrill for scale.

A taste for the incomparable beauty of a well-designed system.

I can only call myself a professional coder for 2 years. For over a decade after, I thought myself an imposter of the discipline. I do not know the latest technologies, tools, techniques. My mind does not think in code. It takes me forever to implement something basic.

But recently, I am discovering that the engineering mindset never left me. I just did not recognize it as such, the gift that the practice of engineering hones.

The Three-Body Problem

The scale of the series Remembrances of Earth’s Past left me in awe.

Looking at the span of eons, my problems are like dust.

But the same patterns persist.

Life has always struggled for survival.

Life has always sown the seeds of its own destruction.

Life has always bloomed, indescribably beautiful, despite all this.

Am I right?

The questions “Am I right?” and “Are you with me?” are almost always proxies for “Am I worthy? Do you think I matter?”

Instead of asking “Am I right?” ask “Does this help <some cause I care about>?”

Observe the difference:

“Do you agree with my product idea?” → “Does my proposal seem likely to reduce user confusion?”

“Are you with me that we should buy this sofa?” → “Does buying this sofa make us enjoy our house more?”

“Are you on my side for doing X instead of Y?” → “Do you think doing X instead of Y gives us a better chance of hitting our revenue goal?”

From the Archives: How to Make Things High Quality

If there is one debate that is the endlessly circling “Star Wars versus Star Trek” of product development, it is what I refer to as “The Tradeoff Between Quality and Time” (TTBQT). Here’s how it typically goes:

Alice: The way we’ve built X is pretty janky/slow/hacky. I have a better solution.

Bob: But we’re on track to finish in 2 weeks. Is it worth pushing back our launch to fix the jank/performance/hackiness of X?

Alice: But we care about quality.

Bob: But we care about shipping.

Alice and Bob then face each other with grim expressions, hands grasping gleaming lightsabers as they prepare to duel it out… oh wait, wrong story.

What happens is that maybe one side convinces the other, maybe the decision gets escalated, but eventually the team accepts either delaying the ship date or okaying a worse-quality output, neither of which feels worthy of celebration.

You might think, But this is how it is. TTBQT is a necessary evil in building anything.

But is it?

Don’t get me wrong, it’s healthy to bring up this tradeoff from time to time to ensure we’re not polishing to diminishing returns or letting the timeline run product development. But I’d like to propose a third option.

When you get into a TTBQT state, the real question to ask is: “If we knew X would take this long to get to high-quality, would we have opted to do it in the first place?”

This is a powerful question because it forces the team to examine what actually went wrong, which is typically:

The second reason I like this question is because it helps to clarify what the TTBQT decision should be. If the answer is “No, X isn’t worth the time it’d take for us to make it high-quality” then cut Feature X altogether. Just stop working on it.

But wait, that’s terrible,” you say. “X is 90% there. We’d be wasting all that work if we don’t ship it.”

Indeed. It hurts to waste time and effort. We get attached to the things we work on. But that’s the Sunk Cost Fallacy talking. If you don’t think a feature is worth the time it takes to make it great, then it is not rational to ship a crappier version simply because you have sunk time into it.

If the answer is, “Yes, we still would have invested in this feature knowing how long it would take to make it great,” then that indicates X is really important and it’s worth the effort to make it not janky/performant/well-constructed.

Over time, asking yourself this question when you get to a TTBQT situation forces you to become more ruthlessly focused up front. You get better at prioritizing the most important things to work on, your estimates become more accurate, and you execute better.

It’s a mistake to conflate success with shipping a large quantity of features.


Photo by JD Hancock

Read more



Building Sundial. Former Product Design VP @ FB. Author of The Making of a Manager Find me @joulee. I love people, nuance, and systems.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Julie Zhuo

Building Sundial. Former Product Design VP @ FB. Author of The Making of a Manager Find me @joulee. I love people, nuance, and systems.