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:

1. The loudest way to lead

2. The best thing studying computer science gave me

3. The Three-Body Problem

4. Am I right?

5. From the Archives: How to Make Things High-Quality

For paid subscribers:

1. Subscriber mailbag: What do you think the creative process will look like for designers leveraging AI? 

2. Subscriber mailbag: How to manage someone more experienced than you?

3. Offended by nothing

4. It all comes crashing down

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 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:

• How ruthlessly the team has prioritized.

• How accurate the team’s estimates are around its ability to execute.

• How good the team is at actually executing.

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.

Instead:

1. Make a list of what your team is working on.

2. Ruthlessly prioritize each thing in ranked order based on importance.

3. Cut hard. You can’t do nearly as much as you think you can. (For example, I thought writing this note would take me 1 day. It’s now Day 5.)

4. Execute well. Set weekly milestones. Operate with a sense of urgency. If #1 starts to slide off track, look at cutting #5, #4, #3, etc… until #1, #2, etc. is set up to succeed.

5. Ship high-quality work (and succeed or fail with confident learnings). Your users deserve it.

6. Do fewer things better, but make them the most important things.
   

Photo by JD Hancock