Engineers Optimize Everything Except Their Careers

Engineers Optimize Everything Except Their Careers

You’ll spend a week benchmarking database options for a 2% latency improvement. You’ll A/B test button colors for a 0.3% conversion lift. You’ll write a six-page design doc for a refactor that affects two services and twelve people.

But your career strategy? That’s a Reddit thread you read once and some vague plan to “keep doing good work and see what happens.”

I did this too. For years. And I was surrounded by brilliant engineers doing exactly the same thing.

We are, as a profession, remarkably good at applying rigorous thinking to technical problems and remarkably bad at applying any of it to ourselves.

The Anti-Patterns

Every career mistake I’ve seen engineers make maps cleanly onto a known engineering anti-pattern. That’s not a coincidence.

“Works on my machine”

You’re doing great work. You know it. Your immediate team knows it. You assume the signal is propagating outward, that the VP of Engineering has somehow absorbed your contributions through osmosis.

They haven’t. Your work is largely invisible outside your immediate blast radius. In most organizations, a Senior Engineer doing excellent quiet work and a Senior Engineer doing mediocre visible work look identical from three levels up. One of them is going to get promoted.

This isn’t cynical. It’s just how organizations work. Signal doesn’t travel on its own.

Premature optimization

You’ve decided the bottleneck is your LeetCode score. You’re grinding Blind 75 on weekends, optimizing for the interview you don’t have yet, for the job you haven’t applied for, while the actual reason you haven’t been promoted is that your manager doesn’t know how to make the case for you to their skip.

Fix the actual bottleneck. Not the one that feels technical and therefore tractable.

No monitoring

When did you last get meaningful feedback on how you’re perceived outside your team? Not annual review boilerplate. Real signal about your reputation, your communication, how you’re seen by people who work adjacent to you.

Most engineers have zero feedback loops running between review cycles. They’re operating blind, then surprised when the review says something they didn’t see coming. You’d never run a production system with no alerting. You’re running your career that way.

Ignoring tech debt

The comfortable role that stopped growing two years ago. The team where you know everyone, understand all the systems, could do the job in your sleep. It feels stable. It is stable. That’s the problem.

Career debt accumulates the same way technical debt does: invisibly, until it isn’t. Then you’re five years deep into a specialty that’s narrowing, with a skill set that hasn’t stretched in years, and the market has moved.

Not reading the docs

The promotion criteria exists. The leveling rubric exists. Someone, somewhere, wrote down what Staff Engineer actually requires at your company. Have you read it? Have you asked someone who recently got promoted at that level what it actually took, specifically, not the official version?

Most engineers haven’t. They’re guessing at requirements while complaining the system is opaque.

Cargo culting

Your colleague led a major infrastructure migration and got promoted six months later. So you volunteer to lead the next migration.

But that migration worked for them because they already had visibility with the VP, because the timing was right, because they had a sponsor who was ready to push. The migration was the last 10% of the case, not the whole case. You copied the artifact, not the conditions.

What an Engineering Approach Actually Looks Like

You know this process. You do it at work.

Gather requirements. What does the next level actually require, specifically, at your company? Not the job description. The real requirements - which projects, which relationships, which behaviors. Talk to people who’ve been through it. Read the rubric. Ask your manager to be specific, not encouraging.

Instrument. Set up feedback loops that run continuously, not once a year. Ask a peer for real feedback on a recent decision you made. Find out how you’re perceived by teams you work with. Make this a habit, not an annual event.

Measure. How do you know if you’re growing? What does progress look like, concretely? If you can’t answer that, you don’t have a career plan - you have a career intention. Those aren’t the same thing.

Get code review. Get an external perspective on your career decisions before you make them, not after. A manager who knows the organization. A coach. Someone who’s been at the level above you. Fresh eyes catch things you can’t see from inside.

Ship iteratively. Stop waiting for the one big move that changes everything. Take on a small piece of cross-team work. Give a talk at the internal all-hands. Write the design doc that explains a system nobody else bothered to document. Small experiments, fast feedback, course-correct.

The Obvious Point

You wouldn’t ship a system with no requirements, no monitoring, no feedback loops, and no code review. You’d call that reckless. You’d push back in the design review. You’d ask how anyone would know if it was working.

Your career is a system you’ve been running that way for years.

The market right now is brutal. The engineers who are navigating it well aren’t necessarily the most technically skilled - they’re the ones who actually know where they stand, what the next step requires, and have enough external signal to course-correct when they’re off track.

That’s not luck. It’s methodology.

If you want someone to run a code review on your career strategy, that’s what I do. Book a consultation and we’ll look at where you’re actually stuck.