This newsletter is sponsored by DevStats.

Shipping late? DevStats shows you why.

Still pretending your delivery issues are a mystery? They’re not. You’re just not looking in the right place.

DevStats gives engineering leaders brutal clarity on where delivery breaks down, so you can fix the process instead of pointing fingers.

✅ Track DORA and flow metrics like a grown-up
✅ Spot stuck work, burnout risks, and aging issues
✅ Cut cycle time without cutting corners
✅ Ship faster. With fewer surprises.

More AI tools won’t fix your delivery. More Clarity will.

Try DevStats for free

Thanks to DevStats for sponsoring this newsletter. Let’s get back to this week’s thought.

Intro

Too many engineers are thinking code-first. But engineers who deliver real value think like a product manager.

Not just focusing on the technical solution, but focusing on delighting the customers.

At the end of the day, it’s not about how great a technical solution is, it’s all about what impact it has on the business and the customers.

As an engineering leader, how can you lead the mindset shift within your engineering team and also the overall organization?

Lucky for us, we have Matt Watson with us today, who is sharing his insights on this topic and how to lead the shift in today’s article.

Introducing Matt Watson

Matt Watson has more than 20 years of experience as a founder and CTO, he built and scaled multiple tech companies, including bootstrapping VinSolutions to $35M ARR before its $150M acquisition. Today, he is leading Full Scale, a company with over 300 employees.

I've known Matt for 2+ years now and he’s been one of the people who helped me a lot with advice and insights when I first started with the newsletter!

Matt has recently published a book called Product Driven and he's been kind enough to share one of the sections with us today, adapted as part of this article.

You can get the free kindle version of the book here only today and tomorrow.

Check out the book!

Your Engineering Team is Always Looking Somewhere

The only question is: where are you leading them to look?

Are they paying attention to what’s on the sprint board or what’s happening in the customer’s world? Are they focused on pushing code or solving problems?

This choice has always mattered. But right now, it matters more than ever.

AI is accelerating everything-product cycles, expectations, and decision loops. Leadership is under more pressure to move fast.

But it's not enough to just move quickly. Teams have to deliver value fast. And that requires clarity about what matters to the customer → not just what’s in the sprint backlog.

This is the leadership challenge most engineering leaders miss: You don’t just set the priorities. You set the direction.

As a leader, where your team looks is where your product goes.

The Pull Toward Code is Strong

When I was an engineer, solving hard technical problems was addictive. I could get lost in architecture decisions, database optimizations, elegant abstractions. It felt like progress. And sometimes, it was.

But more often than I care to admit, I spent hours perfecting things that never created value for the customer. That’s the trap. We fall in love with the challenge itself → getting the architecture right, solving edge cases, refining the flow.

It’s satisfying work, but without the user in mind, it often becomes aimless. It’s not wrong. It’s just incomplete.

The system trains us this way. Most engineering performance reviews praise clean commits, not customer impact. Most processes reward sprint completion, not user outcomes. And most cultures treat technical exploration as progress, regardless of whether it solves a real problem.

I once had an engineer tell a customer, "It’s all documented." Technically, he was right. But the customer couldn’t figure it out, and didn’t care how elegant our docs were. They just wanted their problem solved. That engineer wasn’t lazy or unhelpful. He was doing what we’d trained him to do: protect the code, not understand the customer.

Engineers don’t drift inward because they’re misaligned. They’re often deeply motivated, just by the wrong signals. Code gives instant feedback. The logic is clean. But that’s also what makes it easy to lose weeks solving the wrong problem.

We don’t default inward because we’re bad at product thinking. We default inward because it’s safe, measurable, and rewarded. But it’s also how we lose focus.

The Cost of Focusing Too Much on the Code

I’ll never forget the time we launched a big feature at Stackify. Everything went perfectly. No errors. No incidents. Deployed on time. And then… silence. No feedback. No impact. No one even noticed.

That silence should have scared us more than any bug report ever could. We’d built something we thought users needed. But we hadn’t checked. We hadn’t watched them struggle, listened to their problems, or tested our assumptions. We built it because we could.

And when teams operate in that same pattern over time, the symptoms get worse. Output increases. But outcomes stall. Burnout rises. Engineers start to disconnect. It becomes easier to hide inside the system, to retreat into the backlog or cling to completion metrics. But it’s harder to feel proud of the work.

We confused shipping with success. And that’s a pattern I’ve seen at every level of engineering. Fast teams who deliver constantly, but don’t learn. Burned-out engineers asking, "Why are we even building this?" Roadmaps full of features that sound good on paper but solve nothing in the real world.

At some point, your team stops caring about the impact. They go heads down. They focus on the requirements and stop asking questions. This isn’t just burnout from pressure. It’s what happens when teams lose sight of the customer. They start perfecting the system instead.

The Slow Death Spiral of Focusing Too Much on the Code

Not every team burns out from chaos. Some burn out in comfort. You fix the architecture. You improve test coverage. You reduce tech debt. The work feels responsible. Safe. Even strategic.

But over time, the team’s direction narrows. They stop asking what the customer needs and start asking what the system needs. The roadmap becomes a list of improvements to itself. Innovation disappears quietly. Curiosity dims. Teams lose their edge without realizing it.

Eventually, you ship fewer features. Not because the team is lazy. But because they’re busy polishing a system that no longer moves the product forward. You get a more maintainable platform, just not a more valuable one.

That’s the slow death spiral: A product that gets technically better, while becoming less relevant. And if you don’t interrupt it, you wake up one day with a team that’s excellent at maintenance… but unable to build anything new.

I describe this as the sideways drift. You’re not moving forward → you’re moving sideways. It might feel stable, even productive. But while your team is polishing and refining, your competitors are shipping, learning, and evolving.

Over time, sideways becomes backwards. The industry moves ahead, and you’re left maintaining a product that’s no longer leading, just surviving.

What Happens When Teams Look Toward Customers

Now contrast that with a team that looks outward.

I’ve seen this shift happen at Full Scale with the engineers our clients rave about. They’re not just fast or skilled. They ask better questions. "Who’s this really for?" "What are they trying to do?" "Why did they click there?" They challenge vague tickets. They bring context into conversations. They care not just about correctness, but usefulness.

Their code is still good. But their judgment is better. And that’s what makes the difference.

It’s easy to measure output. But product judgment is the multiplier. The ability to know what to build and why it matters is the highest-leverage skill in software.

I’ve also seen what happens when engineers get exposed to even a single user session. It changes how they think. They start noticing friction. They connect their decision-making to real-world behavior. And often, they feel something else too: responsibility. Not just to build something correctly, but to build something that helps.

You still want engineers who care about their craft. But if you want them to build great products, they have to start with the customer, not the code.

Your Job As a Leader Is to Lead the Shift

This isn’t something you fix with a new process. It’s not about running more customer interviews or tweaking your agile board. It’s about what you normalize. What you praise. What you question.

If you start meetings by asking "What’s the status?", your team will optimize for task completion. If you ask "What did we learn about the customer?", they’ll start paying attention to things they never noticed before.

You set the direction of the team.

I learned this the hard way. Years ago, I was leading a product where we poured months into the roadmap. Teams executed flawlessly. But leadership above us changed direction. Suddenly, priorities shifted. The vision died.

And I realized something painful: Even though I was still in the room, the thing we were building was already gone. That’s when I understood that leadership isn’t just about protecting velocity. It’s about protecting meaning.

Your job isn’t just to manage throughput. It’s to hold onto the reason any of this matters and keep that reason visible to the team. Because if you don’t, they’ll follow the spec. Not the problem.

How to Start Shifting the Direction

So, how do you shift your team’s attention? Not with a reorg. Not with a new tool. You shift it with behavior. Tiny leadership moves that create new reflexes.

Here are a few we’ve seen work again and again:

• Ask "What changed for the customer?" in standups and demos. It forces teams to connect the work to real outcomes. Not output. Outcome.

• Show a session replay in planning. Let your engineers see what users are doing, not just what PMs say they’re doing.

• Review a support ticket together. Trace it to a code decision. Make the loop visible. Show how real problems reach the team.

• Celebrate the root cause finder. Don’t just praise the engineer who shipped the fix. Praise the one who uncovered the real problem behind it.

• Share a customer story in the room. Even if it’s painful. Don’t sanitize feedback. Don’t protect egos. Make the cost of bad assumptions real.

At Boddle, an education startup, they didn’t rely on surveys to figure out what kids needed. They watched how students used the product. One observation session surfaced a huge insight-something no user ever said, but their behavior made clear. That moment unlocked product changes that led to millions in revenue.

You could argue that the insight was already there, buried in feedback or hidden in usage logs. But the truth is, they didn’t find it until they started looking differently. That’s the real power of shifting the gaze. You stop waiting for answers to surface. You go seek them out.

They watched instead of guessing. They observed instead of over-engineering. They listened instead of waiting for perfect answers. That’s not a process shift. That’s a reflex. One you can start building now.

How Customer Focus Elevates the Craft

There’s a common fear among engineering leaders that focusing on users will mean lowering the technical bar. That by shifting attention from the elegance of the system to the needs of the customer, teams will start cutting corners or prioritizing speed over quality.

That fear is misplaced. Product context doesn’t dilute technical excellence. It sharpens it.

When engineers understand the real-world problems behind their work, their technical decisions get better. They can see where complexity is necessary and where simplicity will serve the user more. They stop abstracting too early. They stop over-architecting things no one will use. They start solving the right problems with the right level of craft.

I’ve seen engineers write clearer APIs because they imagined someone trying to integrate them under pressure. I’ve seen teams reduce latency not because a benchmark demanded it, but because a user interaction was painfully slow. In every case, the technical move was still strong-it just had a reason to exist.

You don’t have to choose between great engineering and great products. The best teams do both. But it starts by grounding the work in context. When the team sees the user clearly, the craft follows with more care, not less.

How to Build Feedback into the System

The most effective way to keep your team looking outward is to make the customer visible every single week. Not through a quarterly NPS slide or a one-off visit, but by making user needs and behaviors a regular part of how the team thinks.

That starts with leadership. If you don’t prioritize it, no one else will. Your job is to create the expectation that user feedback isn't an interruption-it's part of the work.

You don’t need a heavy process. You need small, repeatable habits:

• Watch a user session together in sprint planning.

• Review a support ticket and trace it to a code decision.

• Ask PMs and designers to share one customer insight every Monday.

When you build that into the weekly rhythm, you’re not just increasing awareness. You’re developing judgment. You’re training your team to connect the dots between what they build and who it’s for. And you’re helping them see feedback not as a distraction, but as a signal worth chasing.

You might even see your team more motivated, because when they can see the impact of their work, they remember why they signed up for this in the first place.

Change the Focus

This is a hard shift to make. Not because people resist it, but because the old patterns are so strong. We think being product driven means hiring a PM. Or adopting a new framework. Or defining more outcomes on the roadmap.

But product thinking doesn’t start in the spec. It starts in the room. It starts with how you run your next meeting. How you respond to the next missed metric. What you ask when someone ships something ahead of schedule.

Do you say, "Nice velocity"? Or do you ask, "Did it solve the problem?"

If that sounds small, remember: most environments aren’t changed by massive transformation. They’re changed by repeated behavior. If you ask the same question every Friday demo, people will start building with that answer in mind.

Because here’s the truth: If you want engineers to care about the customer, you have to make the customer visible. If you want better product judgment, you have to reward curiosity, not just completion. If you want better outcomes, you have to lead your team to look outward.

Your job isn’t just to lead the team. It’s to help them focus. If you point them to the customer, they’ll still write great code, but now, it will drive better outcomes for the customer.

Next time you walk into a team meeting, ask yourself: What are we looking at? And what are we missing?

Last words

Special thanks to Matt for sharing his insights on this very important topic with us! Make sure to check him out on LinkedIn and also check out his book Product Driven.

If you’re looking to dive deeper into how to lead engineering teams who want to build with purpose, not just speed, and if you care about outcomes, this book would be a great read for you!

We are not over yet!

Why Engineers Hate Deadlines (And How to Fix That)

Check out my latest video. Deadlines have gotten quite a negative perception over the years in the engineering industry. But if they are done in the right way, they can be incredibly useful. Learn how to do that in the video below!

New video every Sunday. Subscribe to not miss it here:

Subscribe to the channel!

Cerbos Hub

My friends at Cerbos have launched their new tool called Cerbos Hub.

An authorization solution that scales with your product. Manage unlimited tenants, policies, and roles. Enforce contextual & continuous authorization across apps, APIs, AI agents, MCPs, and workloads. Try it for free here.

Liked this article? Make sure to 💙 click the like button.

Feedback or addition? Make sure to 💬 comment.

Know someone that would find this helpful? Make sure to 🔁 share this post.

Whenever you are ready, here is how I can help you further

• Join the Cohort course Senior Engineer to Lead: Grow and thrive in the role here.

• Interested in sponsoring this newsletter? Check the sponsorship options here.

• Take a look at the cool swag in the Engineering Leadership Store here.

• Want to work with me? You can see all the options here.

Get in touch

You can find me on LinkedIn, X, YouTube, Bluesky, Instagram or Threads.

If you wish to make a request on particular topic you would like to read, you can send me an email to info@gregorojstersek.com.

This newsletter is funded by paid subscriptions from readers like yourself.

If you aren’t already, consider becoming a paid subscriber to receive the full experience!

Check the benefits of the paid plan

You are more than welcome to find whatever interests you here and try it out in your particular case. Let me know how it went! Topics are normally about all things engineering related, leadership, management, developing scalable products, building teams etc.