The Best Engineers Don't Want a Ticket — They Want the Problem

One belief followed me across every company I have ever worked at. Amazon, Snap, and across advertising, e-commerce, social media, and entertainment.

The best solutions never came from telling engineers what to build. They came from showing them why it needed to be built.

I learned this early. The teams that consistently shipped the strongest work were never the ones with the most detailed specs or the tightest sprint plans.

They were the teams where engineers understood the customer problem deeply enough to challenge the approach before a single line of code was written.

Most companies don’t operate this way

Most companies treat engineers as executors. Here is the roadmap. Here are the requirements. Go build it.

And then leadership wonders why the output feels like it checks every box but solves nothing particularly well.

I spent 17 years pushing back on that model. Not because I had some management philosophy I was trying to prove. Because I kept watching what happened when I brought engineers into the problem early.

• They asked better questions.
• They found simpler solutions.
• They caught assumptions that would have cost us months.
• And they cared more about the outcome because they understood what it meant.

The engineers I most wanted to champion

The engineers I loved working with the most were never the ones who just wanted a ticket to pick up.

They were the ones who wanted to know why this problem mattered, who it affected, and whether we were even solving the right thing.

Those were the people I wanted to champion, to fight for, to make sure the organization recognized.

That belief never changed across five industries and over a decade and a half of leadership. And it is the same belief I bring into coaching now.

What this means for engineers and technical leaders

When I work with senior engineers and technical leaders, the first thing I notice is how many of them have spent years inside environments where nobody asked for their thoughts. Just their output.

Over time, that shapes how they see themselves. They start defining their value by what they shipped instead of how they think.

If you’re an engineer or a technical leader and that last line made you pause, it might be worth reconsidering how you talk about yourself. Your best work was never just the code. It was the judgment behind it.

This is the kind of leadership I spent 17 years practicing, and it is the kind I coach now. If you are a technical leader who wants to be valued and rewarded for how you think — not just what you ship — contact me or book a discovery call.