I manage two teams. They are structured almost identically — same size, same roles, same tools, same access to leadership, same business domain. They receive the same inputs and operate under the same constraints.
One of those teams has a conversation. The other one waits.
I have watched this contrast play out week after week for long enough to be certain it is not about talent, intelligence, or motivation. The engineers on both teams are capable. The difference is something else entirely — something in how they relate to the work, how they think about their role, and what they believe their job actually is.
I call it the difference between project thinking and product thinking. And it shows up most clearly when something goes wrong.
Imagine a message comes in from a user: the app feels slow.
Two engineers receive the same information at the same time.
The first engineer — the one who waits — reads the message and opens their task manager. There is no ticket. They check Slack to see if anyone is discussing it. There is some noise but no clear direction. They wait for someone to file a ticket, assign it, and tell them where to look. When the ticket arrives, it says “investigate performance issue.” They start there and not a moment before.
The second engineer — the one who hunts — reads the same message and opens a dashboard. They start looking. Where is the slowness? Is it one endpoint or many? Is it consistent or intermittent? When did it start? Is there a deployment in the last 24 hours that correlates with it? Before anyone has filed a ticket, they have a hypothesis. By the time the ticket arrives, they have already narrowed the problem to two possible causes and ruled out four others.
Same message. Same information. Completely different response.
The waiting engineer is not lazy. They are not indifferent. They have simply learned, somewhere along the way, that moving without a ticket is risky. That if you investigate something nobody asked you to investigate, you might spend time on the wrong thing, or surface a problem that creates more work, or step on someone else’s territory. The safest move is to wait for explicit direction and then execute within it.
The hunting engineer has learned something different. They have learned that the ticket is not the starting gun — it is a lagging indicator. By the time a performance problem becomes a ticket, it has already been slow for a while. Users have already been frustrated. The engineer who waited for the ticket is always solving yesterday’s problem. The engineer who started looking is solving today’s.
The difference between these two engineers goes deeper than work style. It is a difference in mental model.
The waiting engineer treats each task as a discrete, isolated unit. A message comes in, a ticket gets created, the ticket gets worked, the ticket gets closed. There is no accumulated context, no growing understanding of the system, no pattern recognition that carries from one problem to the next. Each problem arrives fresh and gets handled in isolation.
The hunting engineer is building something different — a mental model of the product, the users, and the system that grows more accurate with every sprint. When the “app feels slow” message arrives, they are not starting from zero. They know which parts of the system have been under stress lately. They know which recent changes touched performance-sensitive code. They know which users tend to report problems first and what their usage patterns look like. The new problem lands in a context that makes it immediately interpretable.
This is what product thinking actually means in practice. Not enthusiasm. Not initiative as a personality trait. A mental model of the problem space that compounds over time.
The question I get asked most often when I describe this contrast is: can a waiting engineer become a hunting engineer?
The answer is yes. But not through explanation.
You cannot tell an engineer to think differently. Telling someone to “think like an owner” or “take more initiative” lands in the same environment that produced the waiting behavior in the first place. If that environment has not changed, the instruction will not change the behavior. They will nod and wait for the next ticket.
What changes the behavior is changing what the environment rewards.
When an engineer investigates a performance problem before being asked and their investigation turns out to be useful — when that initiative is recognized, attributed to them specifically, and treated as exactly the kind of thing the team does — they learn something. The model updates. Looking is safe here. Looking is valued here. Looking is what this team does.
That learning does not happen from a conversation. It happens from experience. Your job as a manager is to create the conditions where the experience is possible.
There is a moment I have seen happen more than once that I think of as the turning point.
An engineer ships a small change. It is not a big feature — a query optimization, a caching adjustment, something that took a day. The metric moves. Response times drop. User complaints stop. And the engineer who wrote the change watches it happen in real time on a dashboard the team built together.
Something shifts in how they hold themselves after that moment. Not dramatically. But visibly.
They built something small and watched it matter. The connection between what they did and what it caused was immediate and undeniable. And that experience — not a conversation, not a performance review, not a values statement on a wall — is what starts turning a waiting engineer into a hunting one.
The engineer who hunts is not a different kind of person. They are the same engineer, having had a different experience of what their work can produce.
Your job is to create the conditions where that experience is possible. Everything else follows from there.
Getting Engineers to Give a Damn: A Manager’s Guide to Building Ownership Inside Broken Systems goes deeper on how to build those conditions — inside large, constrained organizations where the system is working against you.
Top comments (0)