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.

About 10 years ago an agile coach introduced me to this concept: meeting theater.

He was talking about scrum ceremonies. Teams going through daily standups, sprint reviews, and retrospectives because the framework said so. Not because it moved anything forward. A fake display of productivity with no progress.

Throughout my career I’ve been watching organizations that struggle to ship.

Management teams spend 8 hours a day in meetings. The calendar looks impressive, packed with important-sounding work.

But nothing gets built.

Meeting theater feels productive. That’s the trap. But those decisions need execution, and execution needs uninterrupted time.

The busy schedule becomes proof of importance. The full calendar signals commitment.

Someone has to write the code, ship the product. That someone isn’t in meetings all day.

The real work happens when people can focus. When they can solve problems instead of talking about solving problems.

But talking about work feels like work.

So the theater continues.