Engineering Feels Lost

You already believe the user matters. You know they deserve empathy. You’ve been told to treat their problems like they’re yours. But how do we continue to show empathy for users when no one shows it to the people building the product?

What about our problems?

You’re told to move faster, even when nothing around us supports success. Your team gets treated like a delivery arm, then blamed when there’s no real strategy. There’s no time to pause, figure out what matters, or create a plan. The chaos becomes the norm. The pressure never stops.

You know how your team really feels?

They feel lost.

Not lost in the code. Lost in the mission. In why their work matters.

When the Work Stops Making Sense

At the time, I was the CTO. My job was to turn vision into reality. We had a bold plan: integrate two businesses and their products. This wasn’t just a roadmap update. It was a defining bet on the company’s future.

I spent months preparing the plan for the board. It finally felt like we were building something that mattered.

And then it got canceled. The budget was gone.

Around the same time, two engineers left. Leadership didn’t replace them. Instead, they cut the budget.

That was when it hit me: The board and leadership weren’t backing me.

And without that support, the role didn’t make sense anymore.

I wasn’t there as a CTO to maintain a legacy system on a life-support budget. I was there to innovate. And if the board didn’t believe in that bet, you have to start asking yourself: What am I still doing here?

Because this is the part no one tells you about leadership: When the vision dies, you're still there, trying to make it all work. You’re not just leading engineers. You’re translating pressure from above and trying to protect the team below.

The board wants results. Sales wants promises delivered. Your team wants clarity. And you’re stuck in the middle, carrying the weight for everyone.

It doesn’t break all at once. It wears you down. Until one day, you realize no one’s backing the vision but you.

In my case, I decided to place my bet somewhere else and resigned.

What Support Should Look Like

You’ve probably lived through something like that. A key project dies. People leave. No one gets replaced, but somehow you're still expected to deliver the same results.

That's when you know support is just words. Real support would've meant replacing those people. Funding that project. Adjusting expectations to match reality.

Real support means following through on what matters. It's backing the vision with actual commitment. But above all, knowing you're not carrying the weight alone.

Support isn’t just about resources. Sometimes it’s when a team says the feature isn’t ready, and leadership ships it anyway.

It's about your team's voice, their ownership, their agency.

No one leads well when they’re just reacting. People do their best work when they help shape it, because the closer you are to the problem, the more clearly you see what others miss.

Empathy isn’t just for users. It’s for the builders, too. When no one listens to you, it’s hard to keep listening to everyone else.

That’s how good engineers get stuck. And smart leaders like you burn out.

If we want better outcomes, we can’t just push harder. We have to lead differently.

Your team needs you to listen. Someone who follows through. Someone who finally asks:

What’s in your way?

What do you need to make this work?

How can we help?

What Product Thinking Really Feels Like

Software engineering feels lost. Everyone’s telling you what to do, but none of it feels connected to real problems.

It didn’t start that way for me. It started with one person, one problem, and the freedom to solve it.

I was 19 when I built my first real piece of software. A simple Microsoft Access database for a local car dealership. It helped them track inventory and customers. Nothing fancy. A simple tool for one person, with one clear purpose.

Nobody told me what to build. It was just him and his problem.

I asked questions. I listened. I watched how he worked. And I could feel where things broke down and why it frustrated him. The vision for what needed to be done was obvious.

Solving a real problem and seeing it help someone.

That feeling was electric.

What was different?

I wasn’t waiting for instructions. I wasn’t buried in process. I had all the context, and I was trusted to figure it out. I could use all of my problem-solving and creative skills.

That’s what product thinking actually feels like.

Not writing tickets. Not pretending to be a PM. I just acted like someone who understood the problem and was trusted to solve it.

Why can’t software engineering always feel this way?

Why can’t we build small, trusted teams with a real connection to the work? Why can’t we give them real autonomy to solve hard problems the way startups do?

The shift to assembly-line software development stripped away ownership. If we want to fix it, we have to stop treating engineers like task runners.

You have to start treating them like what they are: problem solvers.

That’s what product thinking unlocks.

To get there, we can’t just change how teams think. We have to change the system around them.

The System Was Never Built for Product Thinking

Product thinking comes naturally to small teams. When you’re close to the customer, the right decisions feel obvious.

The best companies found ways to protect that mindset as they scaled. They didn’t just hire more engineers. They redesigned how teams worked, so product thinking wouldn’t get crushed by process.

Companies like Amazon, Spotify, and Atlassian proved that product thinking isn’t just a philosophy. It’s operational.

Their teams are small. They own what they build. Engineers don’t just execute the roadmap. They help shape it. They work in squads that own problems, not just features. Product decisions start with users, not backlogs.

They redesigned the culture so product thinking had room to live.

That’s what most organizations are missing. You can’t scale product thinking inside a system that rewards output over outcomes. And you can’t demand ownership while treating teams like a ticket queue.

Now, under the weight of AI, that system is starting to crack.

That’s why I built the Product Driven Model.

Most leaders say they want product thinking. But they haven’t built the culture it requires. They don’t know what it looks like in practice, or how to build the conditions that make it possible.

This model shows them how. It gives leaders a practical way to shift culture. Because product thinking doesn’t survive on intention. It needs structure. And space to grow.

Product Thinking Isn’t Optional Anymore

AI didn’t create this problem, but it’s speeding everything up. Building is faster than ever, and that speed has a cost.

When anyone can build, the bottleneck isn’t engineering, it’s knowing what to build. And when execution gets cheaper, strategy becomes the real differentiator. Not code.

Companies that struggled to innovate before will still struggle now. It wasn’t engineering that was the problem. It was decision making, organizational friction, and company culture.

The companies that invested early in autonomy, alignment, and product thinking? They’re not scrambling to catch up. They’re accelerating with it because their teams had the autonomy and ownership to innovate.

Most teams feel stuck because no one has built a culture where product thinking could survive.

They have the talent. They have the ideas. What they don't have is permission to use them.

It’s not that teams lack product thinking. It’s that the environment keeps crushing it.

That’s what the Product Driven Model is for.

Not just a set of ideas. A new way to lead.