Most companies push for the quickest solution. But 9 times out of 10, those aren't the best solutions. The question we should be asking isn't 'what's fastest?' — it's 'what's smartest?'
I've had a coworker who took the easy way out. Someone who would try to get others to do the work they were responsible for. I never found out whether it was a lack of knowledge, experience, or confidence — but watching it happen got me thinking.
If you had to choose between the quickest route and the more time-intensive, detailed one, which would you pick?
Most people choose the former. My answer wouldn't be so straightforward.
My response would be a question: which one is actually needed, and why?
Also shared on LinkedIn.
Most companies — especially with AI in the mix — are pushing for the quickest solutions. Ship faster. Move faster. Decide faster.
But 9 times out of 10, the fastest solution isn't the best one. It's often the one that creates the most downstream problems — problems that better research, better design, or a slightly longer conversation upfront could have prevented entirely.
I've seen this pattern consistently across healthcare, aerospace, and enterprise software:
Instead of asking "what's the fastest way to do this?" we should be asking "what's the smartest and most efficient way?"
Efficiency doesn't always mean immediate speed. Sometimes it means investing weeks — or even months — into building something right, so you never have to do it again.
In billiards, this maps directly. You don't just take the next shot. You play position for the ones after it. The angle you leave yourself on determines whether you run the rack or hand it to your opponent.
Software isn't different. The decision you make today shapes the problem you're solving six months from now.
When you ask for that time — to do it right, to design it properly, to think it through — the response is often: "we can't afford it."
What's rarely acknowledged is that "we can't afford it" is itself a decision. A decision to accept the risk of downstream problems, rework, and technical debt in exchange for speed today.
That's sometimes the right call. Constraints are real. Deadlines matter. But it should be an explicit decision, made with full awareness of the tradeoff — not a default.
The engineers I've respected most aren't the ones who move fastest. They're the ones who ask the best questions before they start moving.
Those questions slow you down at the start. They save you enormous amounts of time everywhere else.
That's not the easy route. But it's usually the right one.