Building something terrible still beats consuming something perfect. I can write broken code or record a garbage track and walk away knowing I made something exist.

I’ve never closed Instagram feeling like I accomplished anything.

Creation leaves you with skills and scars.

Consumption just leaves you wondering where the time went.

When you think of developing a new product it is easy to think that underneath a solid UI there is also solid code.

We gather to watch something together. Everyone pulls out their phone.

The shared screen becomes permission for individual escape.

Nobody calls it out because everyone’s doing it. We all maintain this fiction that we spent time together while actually being alone in parallel.

Some behaviors stick around long after the problems they were designed to solve have disappeared. These create some of the biggest change management challenges we face.

Take the keyboard. This oddly arranged collection of keys exists because of a mechanical limitation from over a century ago. Typewriter keys would jam if you typed too quickly on adjacent letters, so the QWERTY layout deliberately slowed typists down.

Why haven’t we escaped this antiquated design in the nearly 40 years since typewriters became obsolete?

Often it’s because these behaviors become so deeply embedded in our culture that we stop questioning whether better alternatives exist. We train the next generation using the same methods without pausing to ask: is this actually the best way?

Brands cannot survive being faceless. AI will flood the market with generic content. Brands need humans to connect.

You’re not stuck because you can’t create. You’re stuck because you won’t create badly.

Show me your bad work.

There’s a divide among developers right now. Some embrace AI code generation as a powerful tool. Others worry it threatens their relevance, fearing they’ll become obsolete if machines can write code.

The best developers I’ve worked with have been those who understood messy, complex business problems and figured out how to break them down into logical, implementable pieces. The code was just the way we communicated this process to the computer.

We’ve seen this pattern before. As people mastered each layer of abstraction, it enabled others to work at higher levels. AI code generation is just the next step in that evolution.

Yet AI makes domain expertise more valuable, not less. The developers getting the best results aren’t beginners trying to skip the learning curve. They’re experienced engineers who can quickly spot when AI generates something that looks right but will cause performance issues at scale.

Perhaps those who struggle with AI identify as “code writers” rather than “problem solvers”? As long as we position ourselves as just the people who translate requirements into code, we’ll get typecast out of the conversations about what should be built and why.

A few years ago we shipped software with a crucial bug. The kind that makes leadership look for someone to blame and makes you wonder if your judgment is completely broken.

I could have walked into the team meeting asking who screwed up. I’d seen other managers do exactly that. They immediately shift focus to finding the guilty party. But I’d developed a different habit over the years, partly from reading the book “Crucial Conversations” and partly from watching blame shifting destroy teams.

Facts first: “We released version X. It has this specific bug. Here’s what we know about impact.” No interpretation, no context, no excuses. Just what actually happened.

Then feelings: “This makes us look incompetent. Leadership is annoyed. I feel like I’ve lost credibility.” The stuff everyone was feeling but afraid to say out loud.

Finally, the future: “What needs to change so this doesn’t happen again?”

What surprised me was how quickly the conversation shifted from blame to problem solving. Not because I had some master plan, but because facts-feelings-future kept us focused on what we could actually control.

The same pattern works when stakes are higher too. When someone crosses a line, you still start the same way: “This is what you said. This is how it made people feel. This needs to stop.” But whether it ends with boundary setting or process changes depends on what actually happened.

During a run today, my wife made an observation that stuck with me. When we walk, we don’t notice the tiny rises and dips in the path. When we run, the slightest upward piece becomes a struggle.

I realized I experience the complete opposite when building products. Speed makes me lose sight of the minutiae that actually matter. Those edge cases that seem trivial in the moment. The quiet concerns someone has after the meeting ends and the decision is already made.

When we’re moving fast, we barrel through what feels like flat ground. We miss the small friction points that will trip us up later. The user who doesn’t fit our happy path. The integration that works perfectly until it doesn’t. The team member who nods in the room but has doubts they never voice.

Speed doesn’t just change how fast we ship. It changes what we perceive as obstacles. Running teaches you that every slight incline matters. Building products fast teaches you to ignore the inclines entirely.

Your focus is only as good as your inputs. Curate what reaches you: meetings, reading, data. Everything else is noise.