I had a conversation with a peer last week that stuck with me. They were describing how much they hated their job—the daily grind, the politics, the meaningless meetings. When I asked why they stayed, their answer was simple: “I like the title and it’s a stepping stone to the next level.”

I was recently reviewing a product flow when something clicked. The process had seventeen distinct steps, each asking users to make decisions about features or services they hadn’t experienced yet. Our completion rate was dismal.

Year-end review season. That special time when many leaders pretend a once-a-year conversation can meaningfully capture twelve months of growth, struggle, and achievement. As I prep for my own team’s reviews, I’m struck by how traditional performance management is exactly what we’d never tolerate in product development: a waterfall process with annual releases and little to no user feedback loops.

Picture this: a five-year strategic plan lands on your desk with a satisfying thud. 247 pages of projections, market analysis, and implementation roadmaps. By the time you finish reading it, three of your key assumptions are already invalidated by market shifts.

I’ve been watching the return-to-office drama unfold with a mix of fascination and frustration. Amazon’s 5-day mandate triggered 2,000-employee walkouts. SAP faced over 5,000 employees signing protest letters. The rhetoric from both sides grows more heated by the day.

I recently sat in a strategy session where a team spent hours debating whether to rebuild their underlying backend engine using the “latest and greatest” framework. The discussion covered algorithms, infrastructure costs, and competitive benchmarks.

In a recent video, Simon Sinek brilliantly captured a sentiment many leaders intuitively feel but often struggle to express clearly: our metrics aren’t necessarily wrong, they’re just incomplete. His analogy of choosing a life partner highlights this perfectly—physical attraction is important, but what about character, support during stress, and fundamental goodness?

A few years ago, I helped a friend update their resume. As we listed their experience, they joked: “Should I include the five years I spent managing a 40-person raid team across ten time zones?”

When software behaves unexpectedly, developers don’t throw up their hands and declare the code “just difficult.” They debug—systematically identifying and fixing the problem. Yet when our leadership runs into similar issues—team conflicts, missed deliverables, communication breakdowns—we often attribute these to personalities or circumstances beyond our control.

The gap between what’s possible and what’s actually achieved often comes down to one critical factor: mindset.