A customer wrote to Pontiac Division of GM motors. His new car wouldn’t start whenever he bought a vanilla ice cream. Any other flavor, the car started fine. Most people would have dismissed the claim.
Not GM.
They sent an engineer to investigate.
He went with the customer three nights.
Chocolate Ice Cream. Started.
Strawberry Ice Cream. Started.
Vanilla Ice Cream. Wouldn’t start.
The customer’s claim, however strange it seemed, held up. So he collected more data. Time of day. Gas type. Drive time. He noticed a pattern. Vanilla was the store’s most popular flavor, sold at the front for quick pickup. All other flavors were sold at the back. The vanilla trips were shorter.
He reframed the question. Not “why won’t the car start with vanilla ice cream?” but “why won’t the car start with less time between shutdown and restart?” The answer was vapor lock. The engine was still too hot.
That is the engineering mind. A way of seeing. The willingness to sit with a strange claim, collect evidence, and find the real question hidden behind the obvious one.
Last week, I published a roadmap.
After I published last week’s field note, Sumit summarized the post on LinkedIn and posted this:
It’s no longer about whether leaders still write code, but whether they can continue to think like engineers in a world where they may not be the ones producing it.
So the obvious question became: what is the engineering mind?
I didn’t know how to respond. It was like asking a fish to describe water. I’ve been doing this for thirty years. The thinking felt automatic. I couldn’t separate what I knew from what I was.
Then I came across two questions from TamizhVendan S that put words to it. Am I solving the right problem? Am I solving the problem right?
The GM engineer was doing exactly this. He reframed the problem (solving the right one) and then collected data to confirm his hypothesis (solving it right).
Last week I wrote that the builder is becoming a director. A director who has never laid bricks gives bad direction. These two questions are what the director needs.
How does it manifest in software development?
If the requirement is to build a customer dashboard for e-commerce, an engineer will clarify the specifics: is it all customers in the db or only those who bought in the last 30 days? Should it matter if they bought $1 or $1000? In my experience, clients often understand these questions differently. Asking these questions helps solve the right problem.
The second question is about architecture. Monolith or microservice? Which database? Which patterns? The agent can generate code for any of these. But which one fits the team’s capability, the scale requirements, the operational overhead? The engineer asks what’s simplest and what trade-offs are acceptable right now. Not in two years. Right now.
The technology is revealing what the engineering mind always was. When anyone can generate a working application, the scarce resource isn’t more applications. It’s knowing which ones are worth building, what’s elegant, and where they’ll break. That judgment has always been the engineering mind. The agentic era just made it impossible to ignore.