Most productivity advice assumes you’re optimizing your entire day.

But that’s not reality.

Work takes 8 hours. Sleep takes 8 more. Cooking, family time, basic life maintenance fills most of the rest.

What you’re really optimizing for is maybe 2 hours of discretionary time.

Maybe an hour in the morning before things get hectic. Maybe an hour in the evening after everything settles down.

The consumption vs creation debate isn’t about revolutionizing your whole life. It’s about what you do with those precious few windows.

That’s when you’re actually choosing: do I scroll or do I write? Do I watch or do I build?

Forget the grand life overhaul. Just win those 2 hours.

Getting back to creating after completing something has always been complicated for me.

It’s like the weight of the completed, iterated, polished version becomes the goal post for the next creative thing. The next thing needs to start on the same level as the previous was when it was completed.

This happens almost every time I try to create again. I overconsume on data, reports, articles and research to make a “better” next project.

But really, I’m just avoiding starting at the messy beginning level again.

The solution isn’t better research. It’s permission to suck again.

Your first draft doesn’t need to compete with your last published piece. It just needs to exist.

We’ve trained ourselves to think long-term about everything.

“But what if this needs to scale to millions of users?”

“How will this architecture handle enterprise requirements?”

“What happens when the team grows to 50 developers?”

All reasonable questions. For the wrong projects.

I’ve watched teams spend years discussing between Symfony vs Laravel and then the problem disappeared in two weeks when company moved to java as the golden path. They were so focused on building the “right” foundation that they missed the shifting ground beneath them.

When you’re building a prototype to test an idea, enterprise-grade infrastructure is like bringing a crane to hang a picture frame.

The bias toward long-term thinking creates an invisible tax on every decision. Database schemas become more complex than needed. Code gets abstracted for flexibility that never comes. Simple features become architectural discussions.

Meanwhile, competitors ship working versions and learn what actually matters.

The irony? By the time you’ve built something robust enough to “scale properly,” the market has often moved on. Your bulletproof solution solves yesterday’s problem with tomorrow’s complexity.

I’m not advocating for sloppy work. I’m questioning our default assumption that every project needs to survive nuclear war.

Sometimes the best long-term strategy is admitting you don’t know what the long term looks like.

Build for what you know today. Let tomorrow teach you what it actually needs.

LinkedIn is buzzing about vibe coding’s impact on organizations.

“It’s changing everything!” say the enthusiasts.

“It’s destroying software quality!” counter the traditionalists.

Both camps are missing something fundamental: vibe coding has existed for five months.

Five. Months.

That’s not enough time to change a coffee order habit, let alone organizational foundations. Yet here we are, debating whether it’s revolutionizing or ruining enterprise development.

I’ve watched companies spend longer than five months just deciding which project management tool to use. The idea that a coding approach could fundamentally reshape organizational values in the same timeframe is… well… optimistic.

Real organizational change operates on geological timescales. Culture shifts happen when people retire, not when new tools emerge. The companies celebrating vibe coding victories today are probably the same ones who adopted React faster than everyone else because they were already comfortable with experimentation.

The companies dismissing it as dangerous chaos? They were already risk-averse.

Vibe coding didn’t change these organizations. It reveals them.

Maybe the question isn’t whether vibe coding will transform how we work. Maybe it’s whether we’re ready to see what our organizations actually value when a faster option appears.

Five months is just enough time to show what was already there.

The first time I held an iPod, I understood something that watching Steve Jobs demo never could have taught me.

Weight. Texture. The satisfying click of the scroll wheel.

You can’t experience lag in a prototype. You can’t feel the awkward pause between tapping a button and seeing a response. Screenshots are beautiful liars.

We’ve gotten so good at making static designs look finished that we’ve forgotten they’re just educated guesses.

A perfectly polished Figma prototype sends the wrong signal: “This is ready. Don’t change it.” The more professional it looks, the more people hesitate to suggest improvements. Nobody wants to be the person asking for “small tweaks” to something that looks complete.

But show someone a working prototype where they can type in a text field and watch their words appear instantly? Different story.

“Can this button be bigger?”

“What if the text was clearer?”

“This feels slow - can we make it faster?”

Suddenly everyone becomes a user experience expert. Not because they know more, but because they’re experiencing rather than imagining.

The best feedback comes from touching, not looking.

Paper sketches invite edits because they look unfinished. Working prototypes invite interaction because they feel real. Polished mockups invite approval because they seem done.

Choose your invitation wisely.

Here is a service I desperately need. A book recommendation based on where I stopped reading a book.

”Ohh you stopped reading Lean Startup after 4 chapters. Then you probably should checkout The Every Store instead cause it has less jargon and is more narrative driven”.

Smart recommendations it could make:

“You stopped at the theory-heavy part, try this more practical version”

“Most people who stop here prefer memoirs over how-to books”

“You made it 60% through, here’s something that builds on those concepts”

I remember this piece of code.

Messy doesn’t even begin to describe it. At least once a year, someone would try to kill it. And fail.

On paper? Simple. It picked which market and language a user lived in. Geographic data plus browser settings, with some fallbacks thrown in. Easy, right?

Wrong.

The code was so woven into our system that touching it meant rewriting everything. We kept thinking “IT JUST PICKS MARKET AND LANGUAGE!!!1?” But that abstraction blinded us to the real complexity.

I see the same pattern now with AI-assisted coding.

You dip your toes in. You think everything’s simple. “Just build me an app that does X.” But you’re the complexity. You understand the full flow. You abstract away all the messy details that make starting from scratch so hard.

This is where Gall’s law hits you: “Complex systems that work have invariably evolved from simpler systems that worked.”

Start smaller. Start easier.

Don’t go all-in on “Create an app where everyone can chat with everyone in the world and it should be encrypted.”

Start with two people. Make that work first.

One interesting paradox of productivity social media: the most effective personal systems are deliberately non-scalable. They’re optimized for one person’s mental model.

It’s about what you want to do and how you want to do it.

But we always look at mentors trying to copy their results. We see their hindsight view of how they work and assume that’s the blueprint.

For years companies tried to copy the Spotify Model. Squads, tribes, chapters, guilds. The whole thing.

Just to realize that Spotify wasn’t even using it anymore.

It was a utopian vision of how work could happen at a specific moment in Spotify’s life. Not a universal framework.

By the time a system becomes famous enough to copy, it’s already been abandoned by the people who created it.

So when we look at how others do things, we need to understand their input. Their constraints. Their actual daily reality.

Not just the polished model they present at conferences.

Copy the thinking, not the system.

A few months ago I bought a close to broken old record player and speakers for $25.

Since then I’ve bought used and reissues of old classics on vinyl. There is something special to the feeling of dropping the needle on the LP’s first track and listening through to the end, not skipping a song because I don’t like it, but keeping at it because it’s what the artist aimed at. Delivering a story.

I’d never heard David Bowie’s Heroes album before this, just the hits. But those wonky odd tracks in between? They’re what make the whole story work.

Wouldn’t it be interesting if artists themselves could say: you cannot listen to any specific tune until you’ve listened to this complete album.

Think of the kind of stories that would then be able to be told again.

Like going to the Louvre and only seeing the Mona Lisa before leaving. You miss all the context that makes it truly special.

I keep seeing memes about “AI Agents everywhere!” and people dismissing them as the next metaverse fad or NFT bubble. But I think they’re missing something important.

Look at the behavioral shift happening. Most people I know now go to ChatGPT instead of Google when they need answers, help figuring out strategic decisions or polish their slides.

We’re not just changing how we find information. We’re changing how we interact with services entirely. Instead of building our own AI agents, the smart move might be building for the AI agents people already use.

Then there’s the money. Big tech is pouring billions into AI infrastructure and development. This collective industry pivot is massive. The only comparable shift I can think of is when everything moved to “the cloud”.

The memes about AI agents being everywhere aren’t wrong. They’re just missing the point about what that actually means for how we’ll do business.