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.

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.

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 doesn’t require mastery of understanding.

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.

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.​​​​​​​​​​​​​​​​

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.

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.

When you create things, your consumption gets better.

A few years ago I tried to teach my kids how to play chess. Trying to learn them all the moves and how to think ahead. The concept of “where do you want to be in a few moves?” was somewhat complicated to grasp.

But once you understand it, everything changes. The better you are at predicting where you want your opponent in the future, the better you are at moving towards it. But you can’t just jump straight to checkmate. You need to plan the moves in between.

The same applies to developing using AI.

You need to think iteratively. Where do you want to move your pieces? In which direction?

The difference with chess is that your opponent really wants you to win. It can eagerly move its pawns to where it thinks would benefit you.

But it might not.

Just like chess, the more experience you have and the better your skills, the better player you are. The same applies to developing using AI. The more skills you have in development and thinking in systems, the better you’ll be at guiding it.

We invented chess computers that can think ahead. Building AI that can do iterative thinking is just the next step. So expect improvements but maybe not exact results.