When It Feels Like the Work Doesn’t Matter

We were all standing in my office, unsure of what to say. We looked at each other with the same question on our faces: Are we really doing this?

The sprint had been messy, full of last-minute bugs and barely tested changes. We were nervous, but we were shipping it anyway.

After weeks of effort, it was time.

So we pushed it to production and crossed our fingers, holding our breath as the application restarted. After a few minutes of silent success, we closed our laptops and went to bed.

It felt like a win.

The next morning, there were no urgent emails, no calls from support, no panicked messages from sales. The release went perfectly. Technically, at least. We busted our butts for weeks, and nobody even noticed. No questions. No feedback. Just silence.

Back then, I thought success meant no errors, no noise, and a quiet release. If no one complained, we were doing something right.

Looking back, that silence should have scared us more than any bug report ever could. We didn’t know if anyone even saw the changes. We didn’t know if it helped. We didn’t know if it mattered.

But it’s not supposed to feel that way.

Your team should be excited to tell your customers about the work they did. They should feel confident that it made a real difference. But when engineers ship into silence, it's hard to feel connected to the work.

It feels like progress, but not success. It feels more like deploying code to literal clouds, disappearing into the air without anyone noticing.

The truth? Most of what we all ship doesn’t matter to customers.

AI makes that problem worse. When software is easier to build, it’s easier to waste time on the wrong thing. And engineers still don’t get the feedback they need to know what truly matters.

The teams that win won’t be the ones that build the most. They’ll be the ones who understand the big picture and stay connected to real user feedback.

How Disconnection Shows Up

The work should matter to the people it’s for. But when the connection to real outcomes gets lost, everything else starts to slip.

According to Stack Overflow’s 2023 Developer Survey, only 32% of developers said they were very satisfied with their jobs. Industry research shows that when developers lose sight of the real impact of their work, satisfaction drops sharply.

Even good teams fall into patterns like these:

Your engineers wait for product managers to make every decision.

Your roadmap fills up with output instead of outcomes.

Your engineers find out what they’re building only after the tickets are written.

When no one knows if the work matters, apathy sets in. Burnout shows up when the work feels pointless. When you’re building things you don’t believe in or understand, over and over.

Over time, no one trusts you to think, as if your job is just to code and stay in your lane. This happens not because people stopped caring, but because the system taught them not to.

And engineers aren’t the only ones drifting. Your PMs start chasing priorities they no longer believe in. Everyone feels the disconnection. Over time, the work feels meaningless.

And when the work feels that way, the team starts to feel invisible.

That’s what product thinking is meant to prevent.

Product thinking isn’t a title. It’s a way of building that starts with the outcome in mind. Without it, teams ship in a vacuum and hope it worked.

Motivation doesn’t die loudly. It fades quietly, one ignored release at a time, until even your best engineers start going through the motions.

I didn’t see it all at once, but I remember the moment it hit me.

How Good Teams Drift

At VinSolutions, the company I co-founded, I was the lead developer. In the beginning, I talked directly to car dealers to understand what they needed. I was writing code, handling support tickets, and fixing bugs myself. Their feedback gave me the insights to know what worked and what didn’t.

There were no layers of bureaucracy. No handoffs. Just problems to solve and people solving them.

Being close to the customer shaped everything we built. It wasn’t perfect, but we solved real problems because we understood why they mattered.

But as we grew, that connection faded. We hired a support person, and everything started to filter through them. Later, it filtered through two layers of support, then through other engineers on the team.

I went from hearing directly from customers to having four people in between. Most of the time, I only talked to customers at occasional trade shows.

The work kept moving. But something felt distant.

It wasn’t just about speed or clarity. We'd lost the reason behind the work, and that's when I realized we were losing the connection.

Even teams at companies like Atlassian and Basecamp have talked publicly about how feedback loops vanished as they scaled. How even great cultures get strained by layers, handoffs, and distance from users.

Drift doesn’t show up all at once. It builds, slowly but surely. A few more meetings, a few more features shipped, and then one day you zoom out and realize: you're shipping fast but not helping anyone.

It’s the question your team quietly avoids, the one no one wants to ask out loud: Did anything we shipped make a real difference?

This isn’t just a leadership problem. It’s a system problem that affects everyone inside it.

The longer people build without clarity or feedback, the harder it becomes to care. You don’t have to manage a team to feel that. You just have to be in one.

When Shipping Isn’t Enough

I didn’t fully understand this problem until I became a founder.

The stakes changed. It wasn’t just my code. It was my money and my future on the line. I was hiring people without a safety net. Spending money we couldn’t afford to waste.

As a founder, you learn very quickly that shipping code alone doesn’t pay the bills. What matters is whether someone will actually pay for it.

That’s when everything changed.

We couldn’t afford to guess. We had to get it right. Because every wrong guess burned time, money, and trust we didn’t have.

That’s when the focus shifted. Not just shipping clean code. Not just hitting deadlines. You stop caring about how fast you shipped or how clean the code was. You start caring more about what happened after you shipped it.

What did the customer do?

What did they say?

Did anything actually get better?

Once you see it through that lens, you don’t go back. You don’t want to just ship code. You want to make a difference for the users. Because their success is your success.

How do you get your team members to care about user success as much as you do?

The Question That Changes Everything

In most companies, engineers don’t see the outcome. Just the task in front of them that is due this week.

Your engineers aren't in the room when the customer explains the problem. They miss the frustration behind the words. They don’t feel the urgency. They just see the ticket.

Buried in all that work is the one question that unlocks everything:

Why are we doing this?

That question is the dividing line where execution shifts toward ownership, and task completion turns into real product thinking.

It opens the door to better questions:

What problem are we really trying to solve?

What happens if we don’t build this at all?

Is there a simpler way to solve it?

It’s not questioning the work. It’s caring about doing the right work.

How People Start to Care Again

I saw this from a different perspective at Full Scale, where we help companies build engineering teams.

The engineers that clients loved most had something else going for them.

They were the ones who would speak up, ask questions, and collaborate on the work. They took ownership, even when it wasn't their job to.

The engineers who struggled? They followed the requirements without questioning them. They did exactly what they were told, and not much more.

That's when we realized we needed to change how our teams operated.

Inside our own teams, we pushed engineers to own more, ask better questions, and speak up when something felt off. The goal is to take more ownership of their work and build products with a purpose.

The shift doesn’t come from tools or new processes. It comes from reconnecting the work to what mattered. From caring about outcomes, not just output.

The solution was simpler than we thought. It started with one question that cut through all the noise: “Why?”

When that question shows up, especially from someone who didn’t “need” to ask it, things start to shift.

People begin to care again. Not just about what they’re building, but why it matters.

That's what Product Driven Leadership is about.

AI is accelerating everything. Speed isn’t enough anymore. You need clarity, judgment, and a team that can think.

But that kind of team culture takes something most struggle with: courage.

That’s what we’ll tackle next.