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 the outage that never happened, but quiet systems are what let an organization move fast. This is what that sub-1% flake rate across 550 tests actually buys: not bragging rights, but trust. A team that trusts its tests stops second-guessing them, and the hours that would've gone to firefighting go somewhere better.
They make guessing impossible. When something breaks, the temptation is to start poking, restart the service, bump the timeout, add a retry, hope (I like to joke that Faith Driven Development, or FDD, is the new norm). Great engineers resist that and turn detective instead: gather evidence, narrow the possibilities, test assumptions, and stay comfortable saying "I don't know yet," which is far more powerful than pretending you do. But the higher-leverage move is to engineer the guessing out of the process entirely. I've put real effort into making troubleshooting fast by default, readable tests, an optimized pipeline, and observability tuned so that what failed, why, and how is answerable in seconds, not excavated over hours. Then I train AI on those findings so the debugging gets faster still. The goal isn't to be a great debugger. It's to build a system where no one has to be.
They make trade-offs on purpose. Engineering is rarely about finding the perfect solution; it's about choosing the best compromise among performance, cost, security, maintainability, time, and experience. Junior engineers hunt for the right answer. Experienced ones know there usually isn't one, only trade-offs, and they make those trade-offs deliberately and explain why. That explanation is leadership verbalized.
Pillar Three: Multiply Other Engineers
This is where engineering changes. Early on, your impact comes from what you build. Later, it comes increasingly from what other people build because of you. That's why staff engineers often grow more influential while writing less code; their work scales through other people. If thinking is designing the car and systems are building it, this pillar is handing someone a car to drive themselves, instead of a pile of wheels and parts to put together.
Communication is a technical skill. For years I filed communication under "soft skills." I don't anymore. Poor communication creates bugs, technical debt, and failed projects; clear communication prevents all three. Documentation, architecture decision records, design docs, a thoughtful PR comment, a well-run meeting. These aren't distractions from engineering. They are engineering. Every time you make an idea easier to understand, you multiply its impact.
Mentorship is leverage you can measure. One of my favorite questions is: what happens when you're on vacation? Does progress stop? Does everyone wait on your approval? The best engineers don't create dependence on themselves, they create independence in others. They teach, share context, and document decisions. If mentoring one engineer makes them 20% more effective for the next five years, that almost certainly outweighs whatever feature you'd have shipped with the same hours.
They remove friction. Another one of my favorites: engineering is the systematic removal of friction. High-impact engineers are always asking what's slowing everyone down. Maybe it's CI, onboarding, flaky tests, code review, or a meeting that shouldn't exist. This is exactly why I have a job auto-filing tickets every Monday for the flakiest and most-regressed tests: it turns "something feels slow lately" into a concrete, prioritized list, every week, without me having to remember. Spend two days improving onboarding and every engineer hired over the next three years benefits. That's leverage you bank once and withdraw forever.
They build trust. I told you up front this is where I'd land. Teams move faster when they trust their tests, deploy faster when they trust their pipelines, refactor confidently when they trust their architecture. Trust isn't built through speeches, it's built through consistency. The highest compliment an engineer can earn isn't "they're brilliant." It's "if they say it's ready, I trust them."
What Doesn't Make You a 10x Engineer
Before we wrap, a few myths worth retiring.
Working 80-hour weeks doesn't make you high-impact. Neither does memorizing every framework, writing code nobody else can read, being the smartest person in the room, refusing to ask for help, or answering every Slack within ten seconds. Those things can make you look productive. They rarely create anything that lasts. High-impact engineers optimize for sustainability over heroics, ego, and visibility.
And here's the one nobody says out loud: climbing the ladder isn't the goal either. Most companies actually design "terminal levels", rungs you're expected to stay on for an entire career. At Google, plenty of engineers spend ten to twenty years at L5 and have enormous careers, by design. Meta openly says Senior is where most engineers should land. A team of strong senior engineers will out-build a team carrying one staff engineer and a bunch of mediocre ones. The pressure to level up or you're falling behind is mostly self-imposed. Impact and title are not the same axis, and chasing the second is one of the easiest ways to lose sight of the first.
And look, maybe I'm not a 10x engineer at all. I might be a 3.14159x engineer. A Pi engineer. I can live with that while striving to improve.
Final Thoughts
Maybe we've been chasing the wrong definition the whole time. Maybe a "10x engineer" isn't someone who produces ten times the code, but someone who creates ten times the impact: asks better questions, builds better systems, improves the people around them, removes friction, makes good trade-offs, and leaves every team stronger than they found it.
The more I think about it, the less the phrase 10x engineer interests me at all, because it points at the individual. What I actually admire are the engineers who build 10x teams, the ones who quietly improve the systems, tools, and people around them until everyone succeeds a little more because they were there. Build the car, and everyone around you gets to move faster on one heck of a road trip.
That's the kind of engineer I'm still trying to become.
Because in the end, the best engineer on your team probably isn't the one writing the most code. They're the one whose impact you still feel while they're on vacation.
As always, happy coding and happy testing.
