How to Be a 10x Engineer

How to Be a 10x Engineer

Or maybe: why we've been asking the wrong question all along.

How do you become a 10x engineer? It's one of the oldest questions in software, and the internet has no shortage of answers. Learn another language. Master system design. Contribute to open source. Read more books. Use AI. Write more code, ship more features, become indispensable.

None of it is wrong. Learning new things is valuable, building is how we grow, experience matters. But every time I worked alongside an engineer I genuinely admired, they didn't fit the stereotype. They weren't typing faster than everyone else. They weren't always the smartest person in the room. They definitely weren't measuring themselves by commit count. Yet somehow they were the ones everyone relied on, trusted with the hardest projects, wanted in the room when something broke, with influence that reached far beyond the code they personally wrote.

After a decade across startups and enterprises, building automation frameworks, mentoring, speaking at conferences, and spending more hours debugging than I'd like to admit, I started noticing a pattern. The engineers with the biggest impact rarely wrote ten times more code. They created ten times more impact. And it's exactly what the most respected engineering organizations reward: as you get more senior, the expectations shift away from output and toward things that are much harder to measure. Influence. Judgment. Technical direction. Leverage.

That's a very different definition than "writes code quickly." Honestly, I don't even like the phrase 10x engineer - it makes software sound like an individual sport, and it never has been. Make the ten engineers around you each 20% more effective and you've contributed more than you ever could by writing twice as much yourself.

So maybe the better question isn't "How do I become a 10x engineer?" It's "How do I create 10x more impact?" That's what this article is about.

Why I'm Writing This

Fair question: who am I to write about this? If you've read my writing before, thanks, and welcome back. If you haven't: I work in QA as a Senior SDET, and I believe trust comes first. Tests nobody trusts are worse than no tests at all, and most of what I do is in service of teams being able to believe what their tooling tells them. That belief shapes everything that follows.

Some prior articles on this if interested:

• The Automation Maturity Pyramid
• Test Leadership as Change Management: Why Your Real Job Isn't Testing
• How to Build a QA Team Engineers Actually Want to Work With

To be clear, I don't consider myself a 10x engineer. I still over-engineer things, still catch myself optimizing the wrong problem, and I hope I never reach the point where I think I've got it all figured out. What I do have is an unusual vantage point and enough scar tissue to feel like I've earned the right to write this down.

Right now I'm the only QA engineer at my company. That single fact has taught me more about leverage than any title could - because when you're a team of one, you don't have the option of out-working the problem. You have to out-system it. So I built systems that do the work whether I'm watching them or not: around 550 end-to-end tests that run against every PR in about fifteen minutes, with a flake rate under one percent. Another 300 visual tests on a weekly cadence. An automated job that files tickets every Monday for the flakiest and most-regressed tests, so I always know where to point my attention. Monthly audits, AI-assisted, to find blind spots before they become problems. A focus on maintaining the highest quality, always.

That stability isn't a trophy. It's a budget. Every hour I'm not spending firefighting flaky tests is an hour I spend on full-stack work, code reviews, DevOps, customer support, and the next layer of coverage. The testing mostly runs itself, which is the only reason one person can wear that many hats.

That's the whole idea in miniature, and it's worth saying plainly: my job isn't to write more code. It's to build the systems, frameworks, and patterns that let code get written with ease and increased quality - mine and everyone else's. That perspective is the real reason I wanted to write this. These are things I'm genuinely proud of - but I didn't arrive at any of them alone, and the biggest jumps in my impact came from learning off the people around me.

Most engineers spend their careers building software. I've spent much of mine helping organizations build software better, and that seat lets you see patterns: what slows teams down, what makes software trustworthy, where communication breaks, and most interesting of all, which engineers quietly make everyone around them better. What follows is my attempt to capture those patterns. Not because I've mastered them - because I'm still practicing them and writing this down is as much a reminder to me as it is advice for anyone else.

What We Measure vs. What Actually Matters

Our industry loves measuring output: commits, story points, velocity, tickets closed, the green squares on a contribution graph. They're seductive because they're visible and fit neatly into a dashboard. The trouble is that almost none of them measure impact.

Picture two engineers. One ships 25 features this quarter. The other deletes 10,000 lines of dead code, kills a flaky deploy process, and shaves sixty seconds off every CI build. Who created more value? You can't tell from the output alone - it depends entirely on context. That's the point. Engineering isn't manufacturing, and more doesn't automatically mean better.

The most valuable work is often the work nobody sees: the outage that didn't happen, the doc that prevented thirty Slack messages, the deployment that quietly became boring. None of it gets applause, and all of it compounds - which is where leverage comes from.

The best engineering organizations already know this. Read the senior rungs of almost any career ladder and notice how little they say about writing code. Dropbox publishes its entire framework, and by the Staff level the expectations are things like influencing the roadmaps of other teams and exercising judgment that favors the wider org over locally optimal outcomes, with mentorship listed as a defined "impact lever." Even Netflix's culture memo gets at it from a different angle, naming Judgment and Selflessness as core values and prizing engineers who look beyond short-term fixes, make good calls under ambiguity, and take time to help others succeed. Not one of those describes typing faster.

Typically the pattern is as follows:

• Junior engineers are rewarded for execution
• Senior for ownership
• Staff for influence
• Principal for organizational impact

The higher you climb, the less your value comes from the code only you can write - and the more it comes from the systems, decisions, and people that keep paying off after you've logged off.

So maybe we've been using the wrong word all along. Not productivity. Not output. Leverage - the ability to create results that outlast your own effort. Sometimes that's elegant code; sometimes it's deleting code, mentoring someone who eventually surpasses you, or documenting a system so well the questions stop. Output scales with your hours. Leverage doesn't. And once you see engineering that way, almost every decision reduces to one question: does this make only me better, or does it make everyone better?

In my experience, building that kind of leverage comes down to three things: thinking better, building better systems, and multiplying the engineers around you. Let's take them in order.

Pillar One: Think Better

Leverage starts long before you open an IDE. It starts with how you think - because the quality of your solutions will rarely exceed the quality of your thinking.

There's a metaphor I keep coming back to. A test automation framework is like a car, and the individual tests are the wheels. If you start by building the wheels first, they roll around and fall off inconsistently - you've got motion and no direction. Just a bunch of wheels behaving differently from one another. But if you invest in the car first, adding wheels becomes the fastest, easiest part of the job. Thinking is building the car. It's the upfront work that makes everything downstream cheap.

And in 2026 it matters more than ever, because writing code is getting easier while deciding what to build, why, and whether it should exist at all is only getting more valuable. Here's what that looks like in practice.

They solve the right problem. The most common trap in engineering is confusing activity with progress. A ticket lands and we jump straight to implementation - framework, schema, microservice or whatnot - without stopping on a simpler question: is this actually the problem worth solving?

I learned this the expensive way. At my startup we once spent a month building a genuinely clever feature for a single high-value customer, on the theory that if they adopted it, others would follow. It was well-designed and it worked. In reality, the customer barely used it, nobody else asked for it, and a year later we deleted it from the codebase. The engineering was never the problem - the assumption underneath it was. The fastest way to waste a month is to perfectly solve a problem nobody actually has, which is why the best engineers spend more time understanding the problem than implementing the solution.

They ask better questions. The strongest engineers I know aren't usually first to an answer - they're first to a better question. What happens if we're wrong? How will we know this worked? What's the simplest possible version? What are we assuming? How will this age in two years? Good questions create clarity, and clarity prevents expensive mistakes. It's easy to admire someone with all the answers; although, I'm far more impressed by the person who asks the question that quietly changes the entire project.

They think in systems, not features. Features are temporary; systems last. A feature solves today's problem - a good system solves tomorrow's too. So when an experienced engineer looks at a request, they're thinking about the long tail: Can this be reused? Does it make future work easier or harder? Who eventually depends on it? What's the maintenance cost? Every technical decision is a gift or a burden to whoever inherits it - and that includes you, six months from now, wondering what Past You was thinking. You are building the environment your future self has to live in.

They understand the business. You can become an exceptional programmer without understanding the business. Becoming an exceptional engineer requires it. Engineering isn't about writing software; it's about solving business problems through software. That subtle difference changes everything. The engineers who end up shaping strategy are almost always the ones who can hold both sides at once - who know not just whether the code is good, but whether the thing it does is worth doing, what it costs to maintain, and which customer actually feels the difference. Technical excellence gets you in the room. Business awareness is what makes people listen once you're there.

They stay curious. The best engineers I've worked with rarely assume they're the smartest person in the room. They ask, they admit what they don't know, they change their minds when the facts change. That's harder than it sounds in an industry that rewards confidence - but confidence without curiosity curdles into arrogance. Curiosity is what keeps you from solving today's problems with yesterday's thinking.

AI doesn't replace any of this. I use AI for nearly everything now, but always with my own thinking first. Back to the car idea: your thinking, your context, and your patterns are the car; the AI is the wheels. Skip the car and ask AI to generate from nothing, and you get detached parts delivered in the wrong size for the wrong model. Build the car first - a detailed prompt carrying the context and patterns you actually need - and the wheels go on fast.

When everyone can generate code in seconds, generation stops being the advantage. Judgment becomes the differentiator: knowing what to ask, what to challenge, what to verify, and when the model is confidently wrong. And it is wrong, constantly, which is exactly why I run multiple layers of review - human and AI. The trick is that every correction becomes context. It's like teaching a junior engineer and making sure they don't make the same mistake twice: I feed my findings back in so the model stops repeating them, and my own debugging instincts get encoded into something that scales.

Everything in this section shares a thread: thinking creates leverage. A better question prevents weeks of work. A deeper grasp of the business redirects a roadmap. A month spent building the wrong feature is a month you don't get back. The thinking isn't the warm-up before the engineering - it's the part that decides whether the engineering was worth doing at all.

Pillar Two: Build Better Systems

Thinking well is the design. Eventually the car has to get built. The engineers I admire most don't just build features - they build the systems that make the next hundred features easy. A feature solves one problem once; a good system quietly solves it a hundred times, for people who never have to think about it again. Everything below is about building the kind of work that keeps paying off long after the feature has shipped.

They optimize for reliability, not heroics. Every team has a hero: production goes down, everyone panics, they dive in, and thirty minutes later it's fixed to applause. They're brilliant - and that's the problem. The uncomfortable question is why the system needed rescuing at all. One of the bigger shifts in my career was realizing the goal isn't to be the person who saves the day; it's to build systems that rarely need saving. Reliable deploys, reliable tests, reliable infrastructure - none of it is exciting, and that's the point. Nobody applauds