A few years ago we were still debating whether the "10x engineer" was real or just a comforting story senior developers told themselves. Today, building across three products simultaneously, I think the debate was always asking the wrong question.
The 10x wasn't about speed. It was never about typing faster or knowing more syntax. It was about solving the right problem in the first place — and that gap, between engineers who execute tasks and engineers who identify what's actually worth building, is wider now than it's ever been.
I've been lucky to work alongside people who operate at a different altitude. They don't just write code. They change the shape of the problem before touching a keyboard. I've started calling this the 100x mindset — not because they ship 100x more features, but because the things they ship have 100x the impact.
It's not about effort multiplied. It's about writing less code to solve bigger problems.
Missionaries vs. Mercenaries
Marty Cagan's framing has always stuck with me: "We need teams of missionaries, not teams of mercenaries." Mercenaries work through a backlog. Missionaries obsess over why the backlog item exists at all.
In practice, the mercenary pattern looks like this: ticket arrives, requirements read, code written, PR opened, feature shipped. Clean execution. But no one asked whether the feature was solving the user's actual problem, or just the problem the PM thought the user had.
The missionary pattern looks different. Before the first line of code, there are questions: What user pain does this address? What happens if we don't build it? How will we know if it worked? Sometimes the answer to those questions is "we should build something completely different." Sometimes it's "we shouldn't build anything at all."
The 100x engineer is the ultimate missionary. They challenge scope before accepting it. They treat the product roadmap as a starting point for conversation, not a list of instructions.
What Actually Sets Them Apart
I've worked with a handful of these engineers across my time building Positeasy and Payiteasy. They're genuinely rare. But watching them work, the pattern is consistent. It's never one trait — it's a specific combination.
The last trait I'd add isn't on that list: they elevate everyone around them. Junior engineers under their wing ship faster and break production less. Not because they're micromanaged — because the patterns get shared naturally through pairing, code review, and the way they explain their thinking out loud.
What the Impact Actually Looks Like
This isn't abstract. I've seen the difference it makes in a concrete product context. When you're running multiple products with a lean team, the gap between an engineer who asks "what do you want built?" and one who asks "what are you trying to accomplish?" compounds fast.
One example from our POS work: we had a feature request to add a "void bill" button with a confirmation modal. Straightforward execution. One of our engineers instead asked why void rates were high in the first place. Turned out cashiers were accidentally creating bills during demos to merchants. The real fix wasn't a confirmation dialog — it was a demo mode. Solved the actual problem, reduced voids by 80%, and the confirmation dialog never needed to be built.
That's 100x thinking. Not faster code. A fundamentally different problem being solved.
A 100x engineer doesn't just build a login system — they ask "how can we reduce signup friction so first-time users never bounce?" One question reframes the entire scope of work.
Their presence also lifts junior engineers. It's not mentorship in a formal sense — it's proximity to a different way of thinking about problems.
Bet on Leverage, Not Toil
One of the clearest practical differences I've noticed is how 100x engineers spend their time. They treat their working hours like venture capital — every investment should compound, not just pay out once.
| The task | Low-leverage approach | High-leverage approach |
|---|---|---|
| UI inconsistency across screens | Fix each screen individually | Build a shared component used across 20+ screens |
| Repeated manual deployment steps | Document the steps carefully | Automate the pipeline, eliminate the steps |
| Slow API response on one endpoint | Optimise that specific query | Identify and fix the query pattern used across 12 endpoints |
| Staff login UX feedback | Improve the current flow | Redesign auth model — QR + PIN, device pairing, shift sessions |
The low-leverage work isn't bad. It needs doing. But it pays out once. The high-leverage work compounds — it solves the problem across every instance of it, not just the one in front of you today.
How to Actually Get There
This mindset isn't a trait you're born with. It's a practice. I've seen engineers shift toward it deliberately — and the change is real, even if it's gradual.
Start with why, not how
Before writing a line of code, interrogate the problem. What user pain does this solve? What happens if we don't build it? Define success upfront — not "feature is shipped" but "checkout abandonment drops by 15%." The spec is a starting point, not the answer.
Talk to actual users
Shadow a support call. Sit with a merchant during their billing rush. Listen for the frustrations they don't bother reporting because they've learned to work around them. Empathy doesn't come from user stories in Jira — it comes from watching someone use what you built and feeling the friction yourself.
Ship early, learn faster
Share prototypes before they're polished. A rough demo in week two is worth more than a perfect spec in week four. The fastest way to find out if you've solved the right problem is to show it to someone who has the problem.
Progress builds on itself faster than most engineers expect. A shared component built this week saves an hour next week, two hours the week after, and a full sprint two months from now. Start small and stay consistent — the leverage accumulates quietly until suddenly it's obvious.
AI as an Amplifier, Not a Shortcut
The conversation around AI in engineering often frames it as a productivity tool — write code faster, generate boilerplate, autocomplete tests. That framing undersells it and, paradoxically, also misses the risk.
AI amplifies whatever you bring to it. If you bring a shallow understanding of the problem, AI helps you ship a shallow solution faster. If you bring a deep understanding of the user, the constraints, and the systems involved, AI helps you ship something genuinely good — much faster than you could before.
The 100x mindset becomes more important as AI gets better, not less. The engineers who thrive are the ones who know what problem is worth solving before they reach for any tool to solve it.
It's a Practice, Not a Title
The 100x Product Engineer isn't a role you get promoted into. It's a way of showing up — asking one more question before accepting a brief, staying curious about what's happening at the edges of the product, treating outcomes as your responsibility rather than your manager's.
The question isn't whether you are one. It's what you'll change tomorrow.
Impact compounds. The engineers I've seen grow fastest aren't the ones who worked the hardest on individual tasks — they're the ones who kept asking which tasks were worth doing at all.