Build systems, not willpower

If your change depends on having enough willpower or feeling motivated, it’s probably doomed since both run out when you need them most.

Make your change part of a system to make it stick. A great system is attaching something to an already formed habit.

I listen to podcasts in an app where I can save a snippet of the conversation with ease. But that snippet alone might not trigger the same idea when I read it back. So I’ve attached the habit of adding a small note that starts with “This is interesting to me because…” That way I can get back to the state I was in when listening.

Another example: whenever I want to exercise in the morning, I need to put my workout clothes out the evening before. It’s a small mental shift that makes it easier. I’m not relying on morning motivation to overcome the small barrier of finding workout clothes. I’m eliminating that decision point entirely.

When looking to create a new habit, find the micro habit to attach it to. Instead of fighting your human nature, you’re designing around it.

Test timing, not just features

Technology changes and people adapt. Maybe not for version one, but possibly by version two when they see the value.

When testing products, don’t just test the feature. Test the timing. What shifted that makes people more open to this idea today?

Stop saying ”we tried that already.”

Escape the pressure to prove yourself quickly

Starting a new role creates this weird pressure to prove yourself quickly.

As a new engineer you want to commit something. As a project manager you want to ship a feature. As a manager you want to make decisions. The instinct is to move fast and show progress.

But the way to actually learn and succeed is different. You need to understand the problem well enough that you can explain it to others. Then make a plan on how to solve it. Then get feedback on that idea.

This feels counterintuitive when you’re new. It feels like you’re not doing anything. But it’s what actually works.

If you manage or coach people, this is something you have to make explicit. You can’t assume they know this.

Tell them: you’re new here. Your focus right now is to understand this role and these challenges. I want you to be able to explain them back to me.

Then depending on their level, you’ll need different amounts of handholding. Junior people need you to walk them through what understanding actually looks like. Senior people need permission to slow down and think. Experienced people in new domains need help knowing what questions to ask.

The pressure to ship something fast is real. But the people who succeed long-term are the ones who understand deeply first.

Meaning is never one-size-fits-all

For some people any mobile-phone will be the right one. For those people you will never need to build a brand.

But if you want a following or people to get exited, you need something that makes some people not exited.

One destination and guardrails

We needed to migrate our tech stack. Instead of a detailed playbook, we set few guidelines: reduce system complexity, ensure everyone feels ownership, and spread knowledge across the team.

People started making faster decisions. They could push back on overly complex solutions without needing technical expertise. The guidelines created productive conflict about real tradeoffs.

Compare this to projects where every decision needs approval. People stop thinking. Change becomes something that happens to them.

Mastery of use

Mastery of use doesn’t require mastery of understanding.

Don't attend meetings you're not needed in

Meetings have become the place where decisions happen.

When meetings become decision central, everyone feels they need to be everywhere.

You can’t skip the meeting where your project might get discussed.

When everyone thinks that way, every meeting becomes overcrowded with people who don’t need to be there.

Often we come with simple advice “Don’t attend meetings you’re not needed in” which sounds obvious.

Yet people keep showing up.

They sit in meetings where they have nothing to contribute. Where they’re not making decisions. Where they’re just… there.

Authority is the memetic blind spot

I learned something uncomfortable when I became an engineering manager.

My technical opinions suddenly carried weight I didn’t intend them to have.

As a senior engineer, I had strong opinions about solutions and advocated for them. That was my job.

But as a manager, people sometimes stopped pushing back. They saw me as someone whose technical judgment could affect their careers.

This is mimetic desire in action. People copy what they think successful people want.

I lost access to the discussions that lead to better solutions. Junior developers stayed quiet. The collaborative tension that makes teams stronger disappeared.

I learned that being “right” about the technical solution mattered less than having the team bought into whatever we chose.

Your job isn’t to have the best technical opinions anymore. It’s to make sure the best technical opinions get heard.​​​​​​​​​​​​​​​​

A glass shard problem

Fresh developers are like sharp glass shards in an ocean.

They have strong opinions. Clear preferences. Everything is black and white, good patterns and bad patterns, right ways and wrong ways.

But time smooths those edges. Experience teaches you that most technical decisions are about tradeoffs, not absolutes. You become more open to different approaches.

This creates an interesting leadership challenge.

The people with the sharpest questions often lack the confidence to ask them. The people with the confidence have learned to stop asking the uncomfortable questions.

You need both in your decision-making process.

AI hype isn't the same as VR hype was

VR required consumers to buy new hardware, learn new systems, and fundamentally change their behavior. Put on a headset. Dedicate time to an isolated experience.

AI builds on behaviors we already have. People type in text fields hundreds of times daily. OpenAI’s 800+ million users came so quickly because the barrier was minimal. Go to a website, type text, get smarter answers.

Sure, there’s hype around AI. But adoption is driven by technology solving real problems within existing workflows. That’s a completely different starting point than VR’s demand for behavior change.

Maybe the question isn’t whether AI goes the same way as VR, but which AI applications actually stick and which are just hype.