The Real 10x Engineer - Andrew Dryga

Too many times in my career, I’ve been the person hired to clean up a mess someone else left behind.

You walk in, the previous team is gone, everything is on fire, and now somehow you’re holding the extinguisher. After you do this a few times, it changes how you think. You stop being impressed by clever code and start being impressed by code that quietly does its job. You stop caring what shiny stack someone used and start caring whether the thing runs without waking anyone up at 3am.

That experience taught me something important: the biggest multiplier in engineering is rarely raw output. It’s judgment. The real 10x engineer is not the one who produces 10x more code. It’s the one who creates 10x more value.

Value starts with visibility

Software is one of the highest-leverage forms of work in the modern economy. A small number of engineers can influence enormous amounts of revenue, cost, and risk.

The strange part is that most engineers have very little visibility into any of that.

And honestly, most companies aren’t much better. Some don’t measure the right things. Others technically measure them, but hide the numbers in dashboards nobody checks. Then they wonder why teams optimize for nonsense.

If engineers can’t see impact, they start chasing proxies: lines of code, number of PRs, story points, how sophisticated the architecture diagram looks in Miro.

None of that matters if the business isn’t moving.

I’ve seen engineers shipping three PRs a week create more value than entire departments. I’ve also seen teams shipping constantly while retention drops, costs rise, and the business quietly gets worse.

The fix is not complicated. Put the real business metrics where engineers can see them. ARR, MRR, retention, conversion rate, churn, infrastructure cost, whatever genuinely matters in your company.

Once people can see the line move after they ship something, they start making different decisions. Better ones.

The true cost of software is not building it

If there’s one lesson I keep relearning, it’s this:

The real cost of software is maintenance.

Writing code is usually the cheap part. Keeping it alive is where the bill arrives. Slowly, repeatedly, and with interest.

That’s why the best code is often the code you never write.

Every component you add becomes a permanent tax: another thing to patch, monitor, debug, migrate, explain to new hires, and eventually remove.

A lot of engineers still get rewarded for adding things. In reality, the person who removes unnecessary complexity is often doing more valuable work. They’re making the whole company faster, cheaper, and less fragile for years.

The hype tax is real

There’s another tax companies pay, and it’s one of my favorites because it sounds smart right up until the invoice arrives.

I call it the hype tax.

Every few years, the industry gets obsessed with some new tool, architecture, or paradigm that will definitely change everything forever this time. A lot of companies end up making expensive bets because they don’t want to look old-fashioned.

Then five years later, the blog posts are gone, the conference talks moved on, and your team is still maintaining the experiment in production.

I’m not against learning new tools. Quite the opposite. Learning is fun. Trying new things is good. Rewriting your company around your weekend curiosity project is where things get expensive.

There’s a big difference between: “I learned this new language because it seemed interesting” and “I migrated critical production infrastructure to it because I wanted to learn on company time.”

One costs you a Saturday. The other might cost the business six months and a permanent maintenance burden.

And the worst version of hype tax is copying Big Tech.

Google, Netflix, Meta, and friends are solving problems that most companies will never have. Their architecture makes sense for their scale, org size, hiring market, and operational maturity. It often makes no sense at all for a startup with five engineers and one overworked DevOps person who is also somehow doing analytics.

I’ve seen startups run Kubernetes for three services, build internal platforms for five users, and implement event sourcing for what was basically a glorified CRUD app. Every time, the justification sounded familiar: “That’s how the big companies do it.”

Yes. And Formula 1 teams also use carbon fiber steering wheels. That does not mean your family hatchback needs one.

Stop cosplaying as Google. Use first principles. Solve the problem you actually have.

Choosing the right work is the whole game

Even if you understand business value, maintenance cost, and the hype tax, one problem remains:

What should you work on next?

Nobody can fully systematize this for you. There’s no dashboard that flashes the next perfect decision in green. You have to go look.

Talk to customers. Talk to support. Talk to sales. Talk to leadership. Look at the product. Look at the market. Look at competitors (but don’t copy them). Look at your costs. Look at what keeps breaking. Look at what users keep complaining about. Then decide what matters most.

And yes, sometimes you’ll be wrong.

That’s normal. The goal is not to become some oracle who is never wrong. The goal is to make thoughtful bets, learn quickly, and adjust.

A lot of engineers are more comfortable solving clearly defined technical problems than ambiguous business ones. But the highest-leverage work is often hidden inside that ambiguity.

The engineer who chooses the right problem is usually more valuable than the engineer who solves the wrong problem beautifully.

Great engineers care about the business

Once you become one of those high-leverage people, eventually the company asks you to scale yourself. That usually means hiring.

The first mistake is trying to hire clones of yourself. The second is hiring purely for tech stack familiarity. The third is building an interview process like you’re Google even though you absolutely are not Google.

What you actually want are engineers who are curious about the business.

People who ask:

Why are we building this?
How are you going to market this?
Who is the customer for this?
What does success look like?
Is this worth the maintenance cost?
Is there a simpler way?

Those people are rare. But a handful of them can outperform a much larger team of competent-but-disconnected engineers.

That’s why small teams often win. A small sharp team is a speedboat. A large organization is a cruise ship. Cruise ships are impressive, but they do not turn quickly.

More headcount usually adds coordination cost, process, meetings, handoffs, and management layers. Unless you are operating at enormous scale, you probably do not need an army. You need a few people with good judgment and real ownership.

So don’t copy Big Tech hiring either. Most startups do not need seven interview rounds and a live algorithm performance. They need honest job descriptions, a practical process, and people who can make sound decisions in a messy reality.

Hire adults. Give them context. Trust them with outcomes. Reward good judgment.

Final thoughts

Stop thinking about engineering and think how you can be a money-printing machine for your company.

Great engineers are not the people who write the most code or do the most clever engineering. They are the people who consistently help the business move faster by choosing to solve the right problems, keeping systems simple, avoiding avoidable complexity, and reducing long-term cost.

Not 10x more code. 10x better decisions. That’s the real multiplier.